Page 2 of 2

Posted: Fri Feb 03, 2006 4:34 pm
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

Posted: Fri Feb 03, 2006 5:23 pm
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

Posted: Sat Feb 04, 2006 5:07 pm
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

Posted: Sun Feb 05, 2006 12:44 pm
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?

Posted: Sun Feb 05, 2006 3:11 pm
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

Posted: Sun Feb 05, 2006 3:30 pm
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

Posted: Sun Feb 05, 2006 4:54 pm
by aval57
doh now I get it! 'I64' prints out with either devpak.

Posted: Sat Feb 18, 2006 12:44 pm
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

Posted: Sun Mar 19, 2006 4:03 am
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.