[bug #26958] debugapp crashes on base svn head

[Richard Frith-Macdonald]

Follow-up Comment #1, bug #26958 (project gnustep):

There's no detail of the release version and/or operating system but the main
text of the report is almost certainly wrong.

If GSCompatibility was involved, then we would be talking about the Apple
foundation, and the stacktrace shows we aren't. 

So, the giveaway in the stacktrace really is:

#2 0xb77f0fe5 in NSMapGet (table=0x0, key=0xb72be160) 
at NSConcreteMapTable.m:554

This shows that we have a null map table ... and that can't happen since the
map table is created when NSProcessInfo is initialized, and NSProcessInfo must
have been initialised before this point in the code.

So ... how can we have a situation where the map table has been initialized,
but we get here and its nul?
There are only two ways I know ... one is if something has overwritten the
memory between initialisation and the point when it's used.

The other (by far most likely) is if two versions of the library are linked
into the application and the order in which things have happened means that
one version of the NSProcessInfo class initialized the table, but another
version of the class (with a different version of the table) is being used.

The solution, if this is the case, is to ensure that only one version of the
library exists on the system, and ensure that all bundles etc are linked with
it.

Q. is it possible for us to somehow detect when an application loads in
bundles which use conflicting libraries or classes?  Dynamic loading generally
permits separate copies of libraries, but this is a problem if they contain
ObjC classes which all get connected to the runtime library.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?26958>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/