Hi, as promised, I wanted to keep you updated on the progress porting sope/SOGo/OGo to gnustep-make 2. The switch to gnustep-make 2 seemed to work fine, for all of the three. Wolfgang also announced the possibility to compile SOGo against GNUstep make 2 some days ago on the sogo list.
The current state of affair can be found here: http://svn.opengroupware.org/SOPE/branches/gsmake2 http://svn.opengroupware.org/SOGo/inverse/branches/1.0-gsmake2 http://svn.opengroupware.org/OpenGroupware.org/branches/ogo-gsmake2 However, OGo, on Linux, *BSD usually compiled against libFoundation, seems to have a problem when compiled against gnustep-base. Stable or unstable doesn't matter, it ends up, with the same segmentation fault, see forwarded mail below. This segfault was observed on OpenBSD(i386) and Linux. There seem to be differences in libFoundation and gnustep-base with regards to NSAutoreleasePool, but I have no real idea, what the actual problem is. Any idea, what could be the problem? or how to investigate further? any more information I could provide? thanks Sebastian
--- Begin Message ---Good afternoon! I have been working to get an installation of Ogo using the gsmake2 versions of SOPE and OGo. I am able to get the software installed and running. I can log in to the Web Interface. However, the action taken immediately after log in causes the ogo-webui to restart. I have the following backtrace from the process in gdb: #0 0x00000000 in ?? () #1 0x01088b35 in -[NSAutoreleasePool emptyPool] (self=0xb93a780, _cmd=0x1395cf8) at NSAutoreleasePool.m:405 #2 0x0108895a in -[NSAutoreleasePool dealloc] (self=0xb93a780, _cmd=0x1395cf0) at NSAutoreleasePool.m:324 #3 0x0108890f in -[NSAutoreleasePool release] (self=0xb93a780, _cmd=0x13cab78) at NSAutoreleasePool.m:317 #4 0x0116966e in -[NSRunLoop acceptInputForMode:beforeDate:] (self=0x9409f70, _cmd=0x13cac58, mode=0x13ca418, limit_date=0x940f5d0) at NSRunLoop.m:1137 #5 0x011698f8 in -[NSRunLoop runMode:beforeDate:] (self=0x9409f70, _cmd=0x36a648, mode=0x13ca418, date=0x9409838) at NSRunLoop.m:1186 #6 0x002422f0 in -[WOCoreApplication run] (self=0x93cf328, _cmd=0x380e50) at WOCoreApplication.m:541 #7 0x00273b5c in WOApplicationMain (_appClassName=0x80564dc, argc=1, argv=0xbffecca4) at WOApplicationMain.m:42 #8 0x002962a0 in WOWatchDogApplicationMain (appName=0x80564dc, argc=1, argv=0xbffecca4) at WOWatchDogApplicationMain.m:316 #9 0x08049a0c in main () I have attempted to debug this but after almost two days I am no closer to the source. In the emptyPool function he segmentation fault occurs because imps[hash] is zero (NSAutoreleasePool.m:405) for the object being deallocated from the pool in that iteration. If I put a conditional around that line of (ie, if (imps[hash])) the segmentation fault occurs further down in the objc runtime. I realize this is probably *not* a problem with the objc runtime, but I was unable to see any other cause for this further up in the OGo code. I have seen this bug after having installed gnustep-startup-0.18.4 and with gnustep-startup-0.19.2. The line number reference above is for version 0.19.2. If there is anything else I can do to debug this problem please let me know. I am very interested in getting to the bottom of this but I seem to have hit a roadblock. Any information you can share would be very helpful! Thanks in advance, Will -- OpenGroupware.org Developer [EMAIL PROTECTED] http://mail.opengroupware.org/mailman/listinfo/developer
--- End Message ---
_______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
