wxString::Format uint64_t problem Topic is solved

If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
chris
I live to help wx-kind
I live to help wx-kind
Posts: 150
Joined: Fri Oct 08, 2004 2:05 pm
Location: Europe

Post by chris »

Hi Bahman,

Such irritating program behaviour always gets me interested :wink:

I don't have time today to look into this more, so I'll continue tomorrow.
Short roundup of my investigations:

- In wxDevCpp's devpak wx's internal vsnprintf substitute (wxVsnprintf_) seems to be called. That one doesn't know %I64 and just passes it literally.
This is shown by

Code: Select all

cout << wxString::Format( "%"wxLongLongFmtSpec"u", wxULL(2));
It prints out "%I64u" with the devpak and "2" with my own build.
Maybe the crash is provoked by the missing va_arg comsumption ("%I64u" not recognized) and interpretation of the unsigned long long pointer as char pointer. This is fairly easy to test, I'll do this tomorrow.

- The question remains why wxVsnprintf_ is called, more specific: why is it only called with the devpaks, but not my own build?

- Also I'm not sure if the missing interpretation of "%I64" is a bug in wx, because it's a Microsoft extension. However, this should be fairly easy to patch in wx. But prior to patching we need to know why the Visual C++ 6's _vsnprintf isn't called. And anyway wx shouldn't crash if it's avoidable.

- Regarding making a devpak: I just followed the instructions in the wiki. I think it's more important to find out what's wrong with the other devpaks (if anything is wrong at all), but if you really need a devpak I guess I could create one.

Chris
this->signature=NULL;
aval57
Knows some wx things
Knows some wx things
Posts: 35
Joined: Thu Aug 25, 2005 5:38 am

Post by aval57 »

There are plenty of devpaks around, Chris. The only reason to make another would be if it actually solves a problem which the others don't, so as you say determining the root cause comes first.

Bahman
chris
I live to help wx-kind
I live to help wx-kind
Posts: 150
Joined: Fri Oct 08, 2004 2:05 pm
Location: Europe

Post by chris »

Hi Bahman,

just wanted to report back with my findings so far:

The crashes are indeed caused by a bad pointer coming from va_args in wxVsnprintf_. I was able to patch this function to support %I64 modifiers. This would make the problems go away, but there is still the outstanding question why wxVsnprintf_ is called in the first way. I've got a suspicion which I'll check tomorrow.

Chris
this->signature=NULL;
chris
I live to help wx-kind
I live to help wx-kind
Posts: 150
Joined: Fri Oct 08, 2004 2:05 pm
Location: Europe

Post by chris »

Hi,

I couldn't find out why the host's vsnprintf isn't called. I suspected if to have to do something with using the Makefile.gcc instead of the one generated by configure and then running into some wierd #ifdef troubles, but there are far too many preprocessor directives used for me to understand what's going on.
What still surprises me is the fact that you get the "2" to be printed. From what I gather it should either work as intended or crash. Does it even crash for you sometimes?
And what does cout << "wxLongLongFmtSpec" << endl; print out for you?
this->signature=NULL;
aval57
Knows some wx things
Knows some wx things
Posts: 35
Joined: Thu Aug 25, 2005 5:38 am

Post by aval57 »

Hi Chris,

Cout << "wxLongLongFmtSpec" just prints 'wxLongLongFmtSpec' literally with either NinjaNL or Simon devpaks (I had to uninstall upCase, so I can't say for sure there); Whether Format crashes or just misformats varies by devpak,

NinjaNL's 2.7 devpak : crash
Andre Simon's 2.6.2 devpak, upCase's 2.6.0 devpak : 2 (null)

so you're right, I guess, that it's a build issue. For all practical purposes patching wxVsnprintf_ (you've added a case -I I take it?) solves the problem, though, and makes the code more robust to boot. So my hat's off to you in any case. Just for clarity, is '../configure --disable-shared --enable-debug' the full command you pre-built with?

Bahman
chris
I live to help wx-kind
I live to help wx-kind
Posts: 150
Joined: Fri Oct 08, 2004 2:05 pm
Location: Europe

Post by chris »

Hi Bahman,

Ooops, there shouldn't be qoutes around it of course:
cout << wxLongLongFmtSpec << endl; :oops:

And yes, I added "%I64" to wxVsnprintf_. I also noticed that "%ll" isn't properly supported, too, should may be I should add that, too.
I asked in the wxDevCpp subforum for a debug build of a devpak that crashes to further investigate, but in I think you are right that the patch I wrote should be added anyway to make wx more robust. I'll contact the devs as soon as I got some more insight in what's going on.
And yes, I built with '../configure --disable-shared --enable-debug'.

Chris
this->signature=NULL;
aval57
Knows some wx things
Knows some wx things
Posts: 35
Joined: Thu Aug 25, 2005 5:38 am

Post by aval57 »

doh now I get it! 'I64' prints out with either devpak.
chris
I live to help wx-kind
I live to help wx-kind
Posts: 150
Joined: Fri Oct 08, 2004 2:05 pm
Location: Europe

Post by chris »

Hi,

I identified the problem and filed a bug, but still got no feedback on it, so I guess that it won't be fixed with 2.6.3.
The problem is that certain preprocessor defines are not set when compiling via the makefiles (like the devpak creators do). Running configure sets those and therefore a "configure && make" build doesn't show the bug.
The missing defines are

Code: Select all

/* Define if you have vsnprintf() */
#define HAVE_VSNPRINTF 1

/* Define if you have vsnprintf() declaration in the header */
#define HAVE_VSNPRINTF_DECL 1
I'll pm NinjaNL; perhaps he could try to set those in his setup.h when compiling his next devpak.

Chris
this->signature=NULL;
aval57
Knows some wx things
Knows some wx things
Posts: 35
Joined: Thu Aug 25, 2005 5:38 am

Post by aval57 »

Took me a while to check back here, but better late than never. Thanks Chris, I'll keep my eye out for a NinjaNL update.
Post Reply