Opened 9 years ago

Closed 7 years ago

#3162 closed defect (outdated)

sigsegv when calling wxEntry twice

Reported by: therp Owned by:
Priority: normal Milestone:
Component: base Version:
Keywords: Cc: therp
Blocked By: Blocking:
Patch: yes

Description

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
explained here
http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?5:mss:72099:200603:maiilapjooblcajiljch
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
by wxEntry.

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.

Attachments (1)

wx-noPrematureCleanup.diff download (733 bytes) - added by therp 9 years ago.
wx no premature cleanup of sm_tableClass in wxEntry

Download all attachments as: .zip

Change History (3)

Changed 9 years ago by therp

wx no premature cleanup of sm_tableClass in wxEntry

comment:1 Changed 7 years ago by wojdyr

  • Component set to base
  • Patch set

Is the ticket still relevant?
If it is, could you update the patch?

comment:2 Changed 7 years ago by vadz

  • Resolution set to outdated
  • Status changed from new to closed

Unfortunately we didn't notice this patch back when it was submitted because it was filed as a bug and not a patch and so didn't benefit from the priority treatment for the patches.

Anyhow, the code seems to have changed significantly since then and the classes table is now recreated on demand so at least the crash as described here shouldn't happen any longer. There might be other problems remaining as calling wxEntry() repeatedly is not something we often test but we'd need to know more details about them if they do indeed happen.

Note: See TracTickets for help on using tickets.