> Am 15.12.2016 um 12:08 schrieb Wolfgang Lux <[email protected]>: > >> >> 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.
Excellent detection work Wolfgang! Thank you very much. That removes he biggest issue that has been blocking a new GUI release. I hope to find time to look into the others over the weekend. Fred _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
