sigsegv when calling wxEntry twice
|Reported by:||therp||Owned by:|
wxEntry is the entry point for all wxWidgets
applications. Calling it twice during
library-loaded-time sigsegv-s. This bug seems to appear
in CVS head and thus 2.6.3-rc2 as there are no visible
changes to the responsible code sections.
The reason why one might want to call wxEntry twice is
I'm a contributor to the wxcl project (wxWidgets
bindings for Common Lisp).
The cause for this segfault can be cured quickly.
wxEntry prematurely cleans up a resource that is IMHO
intended to be cleaned up when the library is unloaded.
The resource is allocated at library-load, so
unallocating it at library-unload is coherent
behaviour. The resource is the Hashtable of class
information, namely sm_classTable in src/common/object.cpp.
I have the impression from reading the comments in
object.cpp that the hash table of sm_tableClass should
live for the whole library-loaded lifetime. This would
make the CleanUp call made by wxEntry premature. As
wxEntry does not reallocate this resource, but presumes
it exists when called, it will segfault when called for
the second time. I therefore suggest to relay on the
::Register ::Unregister code in object.cpp solely (that
is already in object.cpp) and remove the clean up step
The other option would be to put an sm_tableClass
allocation in wxEntry before the methods called by
wxEntry start to use sm_classTable. But then we would
have two alloc/free pairs for sm_tableClass which
violates the principal that a resource should be
managed only by one code piece. On the other hand
removing ::Unregister/::Register thus putting the
responsiblity solely with wxEntry seems wrong to me.
Hence, I vote for the first option: remove the
premature sm_tableClass cleanup. The following patch
does that and also changes wxClassInfo::CleanUp into an
empty method. The latter might not be strictly
necessary to solve this bug, but still any call to it
seems premature too as ::Unregister and not ::CleanUp
is responsible for cleaning sm_tableClass. Remove
CleanUp completely if you're sure there are no external
deps on this.