> Am 15.12.2016 um 00:05 schrieb Riccardo Mottola <[email protected]>: > > Hi, > > Fred Kiefer wrote: >> In your specific case the initialisation of the NSDocumentController happens >> because NSApplication cannot find a suitable responder for an action it is >> trying to send. This looks like your UI is using an undefined message. >> >> Sorry, I know that this isn’t much help. But it is the best I can do right >> now. >> Fred > > I did not yet try valgrind, I am not very good at getting usable information > from it, but I tried going back in gnustep GUI code and check if we "broke" > something and indeed. > > Oct 1st -> works! > Oct 9th -> works > Oct 23rd -> works > Oct 24th -> works > Oct 25th -> broken > > thus the problems appears to be the lock change by Gregory! > The fact that we get a crash in [NSLock new] doesn't look so unreasonble now.
Actually, we don't get a crash in NSLock new, but we get a crash when the result of NSLock new is assigned to the mlock variable. This looks a bit weird at first, but then turns out to be a name conflict that is not resolved properly by the linker. The mlock variable is not declared static and libc exports a function mlock. Because of the incorrect declaration, the linker resolves the name mlock in the assignment mlock = [NSLock new] to the libc function rather than the global variable and the crash happens when the code attempts to write the address of the new lock to the text section (read the code) of the program. Changing the declaration to use static (as it should always have been!) fixes the issue. Wolfgang _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
