discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: opengroupware and gnustpe-base WAS: [OGo-Developer] gsmake2 branch


From: Sebastian Reitenbach
Subject: Fwd: opengroupware and gnustpe-base WAS: [OGo-Developer] gsmake2 branch segmentation fault
Date: Mon, 18 Feb 2008 10:01:00 +0100

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 --- Subject: [OGo-Developer] gsmake2 branch segmentation fault Date: Fri, 15 Feb 2008 16:09:16 -0500 User-agent: Thunderbird 2.0.0.9
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
developer@opengroupware.org
http://mail.opengroupware.org/mailman/listinfo/developer

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]