Re: #11094: Crash when using wxConvLibc from global object dtor

[wxTrac]

#11094: Crash when using wxConvLibc from global object dtor
--------------------------+---------------------------------------------
Reporter: nitram_cero | Owner:
Type: defect | Status: confirmed
Priority: normal | Milestone:
Component: base | Version: stable-latest
Resolution: | Keywords: wxMBConv stack overflow ToWChar
Blocked By: | Blocking:
Patch: 0 |
--------------------------+---------------------------------------------

Comment (by pete_b):

I ran into this today upgrading a project from wx2.8 to wx3.0. It was due
to having some wxBitmap objects held by a singleton.. The destructor of
wxBitmap calls wxLogLastError. This was bad and I've fixed it in my code,
so in a way, the stack overflow was useful! But perhaps it should assert
/ throw an exception if it starts infinitely recursing as it would be
considerably less tedious to debug...

Even though I have disabled logging in my application, there is
considerable use of these string conversion functions as a result of
logging statements.. from an efficiency standpoint, it would be nice if
the that did not occur when logging is off (probably by making the logging
functions accept raw character strings instead of wxString -- but I did
not investigate how feasible that is).


To resolve the issue with the destructor ordering, one possibility on MSVC
might be to use:

#pragma init_seg(lib)
or even
#pragma init_seg(compiler)

in a translation unit containing the wxConvLibcPtr to control
initialization / destruction ordering. Have not tried it but it might
work..

https://msdn.microsoft.com/en-us/library/7977wcck.aspx

Not sure what other compilers offer in this regard.

And you could also use a POD type to say that the wxConvLibcPtr object
(or a wrapper of) was destroyed already and don't create another one. I
expect it's still technically UB but would probably work on any compiler
out there, provided a dll build is not being used.

--
Ticket URL: <http://trac.wxwidgets.org/ticket/11094#comment:8>