Stacktrace doesn't work with non-ASCII or Unicode identifiers #15138
Issue migrated from trac ticket # 15138
component: wxMSW | priority: normal | resolution: fixed | keywords: Unicode call stack trace non-ASCII work-needed
2013-04-06 13:35:36: suzumizaki (Suzumizaki-Kimitaka) created the issue
Current stack-tracing code always fails if some functions have non-ASCII identifiers with wxMSW.
When the assertion-stop is made while calling the function with non-ASCII named, nonsense another stop will also be made. "Nonsense" one throws away the information we really need, which the first one has.
This invalid behavior depends on calling wxString::FromAscii(char*) with non-ASCII string in short. But with accuracy to say, we should use wide char (PCWSTR/PWSTR) versions of debugging API on Windows, not ANSI(MBCS) ones.
As you know, C++ specification allows non-ASCII identifiers. This means the names can be exists outside of wxWidgets and the outside one can be included into our stack traces.
I tried to fix and post the patch, but I don't know which environment we should check especially outdated operating systems/SDKs/develop environments. Anyone Help? Or what should I do anything else?
I checked by attached .cpp code (simply replace with "minimal.cpp") with:
The text was updated successfully, but these errors were encountered:
2013-04-06 15:29:16: @vadz commented
Thanks for working on this. I hoped to apply it quickly but got mired in the differences between debug help API versions and also realized that we're doing some needlessly complicated things with 64 bit support so after spending almost an hour on this I'm still not done :-( Will try to finish at some later time.
In the meanwhile, it would be nice to have a patch to the except sample adding a function with non-ASCII name to be able to check how it works directly here.
2013-04-06 15:29:16: @vadz changed status from new to accepted
2013-04-08 16:15:23: @vadz changed status from accepted to new
2013-04-08 16:15:23: @vadz commented
Sorry, after looking at this one again I have to give up. There are 2 big problems here:
I hoped to fix the former but it doesn't make much sense without fixing the latter and I won't have time to do it. So I've just checked in the 2 small changes that are uncontroversial and will leaving the rest to you...
2013-04-11 14:00:01: suzumizaki (Suzumizaki-Kimitaka) commented
I made new patch here now:
...HAHAHA, I have learned a bit how great daily maintainers do their works!
But some light issues remain:
2013-04-18 15:04:40: suzumizaki (Suzumizaki-Kimitaka) commented
I make new patch to make sure building library without errors with another toolkits.
With this patch, I can build library and samples/except with:
Notes, Toolkits I can't build with external reasons:
The linker shows a lot of FOLDERID_*** multi defined issues.
n2) Also I can't with Windows Server 2003 SP1 SDK and R2 one.
Because the toolkit can't compile variadic macros, used in include/wx/cpp.h.
Visual C++ 2005 (cl.exe 14.00.5xxxx.yy, vc80) looks have the capability but I can't install my Windows 8 Pro 64bit.
n3) Also not with more old SDK, like "Microsoft Platform SDK 2002 July"
I can't install my Windows 8 Pro 64bit. The sdk detects 64bit Windows and try to run 64bit installer, but the installer supports itanium only.
I think I did all what I can, please anyone help!
2013-04-20 14:15:23: @vadz changed status from new to accepted
2013-04-20 14:15:23: @vadz commented
Thank you for all your work, I'll try to look at the new patch a.s.a.p.
I probably won't apply the changes to the sample but I'll test with your original test case (
2013-09-15 02:16:35: @vadz changed status from accepted to closed
2013-09-15 02:16:35: @vadz set resolution to fixed
2013-09-15 02:16:35: @vadz commented
(In ) Make wxMSW stack walking methods work with Unicode identifiers.
This allows to show the stack properly for e.g. Japanese programs.
2013-09-15 14:00:16: @vadz changed status from closed to reopened
2013-09-15 14:00:16: @vadz changed resolution from fixed to **
2013-09-15 14:00:16: @vadz commented
Unfortunately less than one day of testing in the trunk was enough to find a big problem with this patch: it breaks compilation with VC8 (and certainly VC7 too), see #15000. It would be fine if the Unicode functionality was not available with the older SDKs used by these compilers but it is wrong to completely break compilation with them.
The patch will either have to be reapplied once support for them is officially dropped (not in 3.0 and probably not in 3.2 for VC8) or updated to avoid using
2015-06-16 13:37:14: suzumizaki (Suzumizaki-Kimitaka) commented
Hello, I'm back!
I make the new patch and pull-request on GitHub!
Please accept this one!
2015-06-19 00:15:40: @vadz changed status from reopened to accepted
2015-06-19 00:15:40: @vadz commented
I'm looking at this but there is still some work to do, if only to undo the incorrect merge of
I wonder how did you test this exactly with MinGW, do you mean that you could solve #2807 and make this stuff work with it?
2015-06-19 06:16:51: suzumizaki (Suzumizaki-Kimitaka) commented
(About 'exact' MinGW)
(About current 'master' on GitHub)
In fact, current 'master' on GitHub cannot be built with UNICODE=0 due to another reason. I will report on wxTrac(as another issue) later.
Now I will trying build with my patch. It may take several hours or days...
2015-06-24 02:36:43: @vadz commented
I've pushed my version of your patch (with a few other simple fixes) to https://github.com/vadz/wxWidgets/tree/unicode-debughlp, could you please test it and let me know if it still actually works correctly with the non-ASCII symbols?
2015-06-25 00:51:52: suzumizaki (Suzumizaki-Kimitaka) commented
Wow... Please tell me why your fix is required against my patch...
2015-06-25 04:15:28: @vadz commented
Replying to [comment:24 suzumizaki]:
Thanks, this was broken by an unrelated change, fixed now.
Oops, sorry, last minute change broke this, fixed too now.
I don't have this compiler any more, but I guess it's due to the first argument non const-ness, right? If so, this should be fixed too now.
As I said, I couldn't apply the patch without changes because of the bad merge of
Could you please retest the new version in the same branch as in the commment:22? Not necessarily all the compilation cases (although testing with VC8 would be welcome), but whether the code actually works with Japanese (or other non ASCII) identifiers? I don't have any test code for this and this is what worries me the most.
2015-06-27 01:41:43: suzumizaki (Suzumizaki-Kimitaka) commented
Ok I know, thank you to take your time to explain.
If you have a time, please check new attachment zip posted just now.
In fact, encoding of source codes are optional even in C++11(also even with UTF-8),
I'm testing now... Currently, all of below seems fine.
2015-06-28 00:24:39: suzumizaki (Suzumizaki-Kimitaka) commented
And following configures succeeded to build with no errors:
2015-07-27 04:01:10: @vadz changed status from accepted to closed
2015-07-27 04:01:10: @vadz changed resolution from ** to fixed
2015-07-27 04:01:10: @vadz commented
Use wide-char versions of debug help functions if available, falling back to
Also improve 64 bit support by using 64 bit versions of the functions if