bugGNUstep - Bugs: bug #23039, gdnc crashes on OpenBSD/sparc64 on...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #23039: gdnc crashes on OpenBSD/sparc64 on application connection

Submitted by:  Sebastian Reitenbach <buzzdee>
Submitted on:  Thu 24 Apr 2008 06:17:04 PM UTC  
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

( Jump to the original submission)

Mon 29 Dec 2008 01:35:30 PM UTC, comment #25:

Closed ... working with latest libffi and gnustep core.

Richard Frith-Macdonald <CaS>
Project Member
Sun 28 Dec 2008 07:16:16 PM UTC, comment #24:

updated to latest stable release of gnustep base, gui and make.
linked against libffi-3.0.8, meanwhile on openbsd 4.4.
gdnc is not crashing anymore.

Sebastian Reitenbach <buzzdee>
Project Member
Mon 30 Jun 2008 09:15:39 AM UTC, comment #23:

Oops ... it seems that libffi had been removed from the system I was testing on, and I failed to spot the warnings that base was actually using ffcall when I configured it to use libffi, so when i thought I was testing with the new fixes for libffi, I was actually testing the ffcall implementation again ... no wonder the behavior was the same.

Richard Frith-Macdonald <CaS>
Project Member
Mon 30 Jun 2008 05:53:44 AM UTC, comment #22:

I haven't figured out the cause of the crash yet, but I've now got ffi to the same stage as ffcall. Which is to say that I've fixed ffi support to the point where it works as well as ffcall support ... passing tests for invocations etc, but crashing when it comes to specifically invoking a method with the same method signature as when registering an observer for distributed objects.

The fact that this method is in the nsinvocation.m test program, and does nothing but print out a message, and doesn't involve the distributed objects system, shows that the problem is with the invocation of a method with this particular signature rather than anything to do with gdnc.

Richard Frith-Macdonald <CaS>
Project Member
Tue 24 Jun 2008 06:33:55 PM UTC, comment #21:

the host is up and running again.
let me know if I can help out somehow.

Sebastian Reitenbach <buzzdee>
Project Member
Tue 10 Jun 2008 11:43:26 AM UTC, comment #20:

Sorry, no progress on this, haven't had time to look at it in the last two weeks :-(
This is really just a ping to let you know I'm still alive and hope to get to look at this next week.

Richard Frith-Macdonald <CaS>
Project Member
Tue 27 May 2008 01:18:57 PM UTC, comment #19:

I added a -ggdb to the LDFLAGS statement in the Makefiles for trampoline, avcall, callback and vacall, and recompiled it manually.

The source is in:
/usr/ports/devel/ffcall/w-ffcall-1.10/ffcall-1.10

Sebastian Reitenbach <buzzdee>
Project Member
Tue 27 May 2008 10:12:04 AM UTC, comment #18:

Not much in the way of progress except to confirm that ffi does not appear to work on bsd and nor does ffcall. I've gone into the ffcall stuff in some depth, enough to confirm that the problem is definitely in ffcall rather than a gdnc bug. It seems that the ffcall based method invocation fails for adding an obnserver ... in fact I added an empty method with the same name and arguments to nsinvocation.m in base/testing, and invoking this empty method also crashes on bsd/sparc64
This means we can test/produce this bug simply by executing the nsinvocation test program. It appears that everything is fine right up to the point where the code enters the av_call() function. therefore, the next stage is to get hold of the ffcall source and debug using a copy of ffcall built from local source, so that gdb can be used to step through and debug the ffcall code itsself (confirming that the values passed into it are correct etc).

Richard Frith-Macdonald <CaS>
Project Member
Sun 25 May 2008 03:52:19 PM UTC, comment #17:

cannot observe any difference, also with libffi compiled with gcc 4.2.

make check had some errors, I posted to the libffi-discuss list:
http://sourceware.org/ml/libffi-discuss/2008/msg00098.html

Sebastian Reitenbach <buzzdee>
Project Member
Sat 24 May 2008 01:41:11 PM UTC, comment #16:

compiled with gcc 4.2, linked against libffi, gdnc does not crash anymore, however, e.g. SystemPreferences died on startup with an again, different backtrace:

$ openapp Gorm
2008-05-24 12:17:45.860 Gorm[4797] File NSLock.m: 611. In [GSLazyRecursiveLock -gcFinalize] objc_mutex_deallocate() failed

sebastia@ops:~> cat /tmp/systempreferences.bug.libffi.gcc4.2
$ debugapp SystemPreferences
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc64-unknown-openbsd4.3"...
(gdb) r
Starting program: /usr/GNUstep/System/Applications/SystemPreferences.app/SystemPreferences

Program received signal SIGBUS, Bus error.
0x0000000043d61360 in NSCountFrames () at NSDebug.m:991
991 _NS_COUNT_HACK(15); _NS_COUNT_HACK(16); _NS_COUNT_HACK(17);
Current language: auto; currently minimal
(gdb) bt
#0 0x0000000043d61360 in NSCountFrames () at NSDebug.m:991
#1 0x0000000043d6c328 in GSPrivateStackAddresses () at NSDebug.m:1100
#2 0x0000000043d8fe78 in -[NSException raise] (self=0x4b2d7b90, _cmd=0x442895b0) at NSException.m:822
#3 0x0000000043c5dc04 in -[GSArray _raiseRangeExceptionWithIndex:from:] (self=0x4b2d7810, _cmd=0x44289720, index=0, sel=0x4667ec50)
at GSArray.m:84
#4 0x0000000043c5eed0 in -[GSArray objectAtIndex:] (self=0x4b2d7810, _cmd=0x4667ec50, index=0) at GSArray.m:304
#5 0x000000004619357c in -[NSMenuView menuItemCellForItemAtIndex:] (self=0x4d3a5010, _cmd=0x4667ec20, index=0) at NSMenuView.m:401
#6 0x00000000461939e4 in -[NSMenuView itemChanged:] (self=0x4d3a5010, _cmd=0x4667eb40, notification=0x4b2d7a90) at NSMenuView.m:442
#7 0x0000000043df3b08 in -[NSNotificationCenter _postAndRelease:] (self=0x415a31b0, _cmd=0x442daad0, notification=0x4b2d7a90)
at NSNotificationCenter.m:1070
#8 0x0000000043df477c in -[NSNotificationCenter postNotification:] (self=0x415a31b0, _cmd=0x4667b168, notification=0x4b2d7a90)
at NSNotificationCenter.m:1099
#9 0x0000000046188cf4 in -[NSMenu itemChanged:] (self=0x48ddf910, _cmd=0x46681100, anObject=0x4b1fff10) at NSMenu.m:712
#10 0x000000004619f3a0 in -[NSMenuItem setTarget:] (self=0x4b1fff10, _cmd=0x46681080, anObject=0x48ddf910) at NSMenuItem.m:380
#11 0x000000004619d8d8 in -[NSMenuItem setSubmenu:] (self=0x4b1fff10, _cmd=0x4667b268, submenu=0x4d3a7790) at NSMenuItem.m:183
#12 0x0000000046189d78 in -[NSMenu setSubmenu:forItem:] (self=0x48ddf910, _cmd=0x30b548, aMenu=0x4d3a7790, anItem=0x4b1fff10) at NSMenu.m:869
#13 0x0000000000101ef8 in createMenu () at main.m:38
#14 0x00000000001019d0 in gnustep_base_user_main (argc=1, argv=0xfffffffffffdf008, env=0xfffffffffffdf018) at main.m:11
#15 0x0000000043e4a300 in main (argc=1, argv=0xfffffffffffdf008, env=0xfffffffffffdf018) at NSProcessInfo.m:913
#16 0x0000000000101618 in ___start ()
#17 0x0000000049a02f24 in _dl_start () from /usr/libexec/ld.so
#18 0x0000000049a02f24 in _dl_start () from /usr/libexec/ld.so
Previous frame identical to this frame (corrupt stack?)
(gdb) list GSArray.m:304
299
300 - (id) objectAtIndex: (unsigned)index
301 {
302 if (index >= _count)
303 {
304 [self _raiseRangeExceptionWithIndex: index from: _cmd];
305 }
306 return _contents_array[index];
307 }
308
(gdb) list NSMenuView.m:401
396 [self setNeedsSizing: YES];
397 }
398
399 - (NSMenuItemCell*) menuItemCellForItemAtIndex: (int)index
400 {
401 return [_itemCells objectAtIndex: index];
402 }
403
404 - (NSMenuView*) attachedMenuView
405 {
(gdb) list NSMenuView.m:442
437 */
438 - (void) itemChanged: (NSNotification*)notification
439 {
440 int index = [[[notification userInfo] objectForKey: @"NSMenuItemIndex"]
441 intValue];
442 NSMenuItemCell *aCell = [self menuItemCellForItemAtIndex: index];
443
444 // Enabling of the item may have changed
445 [aCell setEnabled: [[aCell menuItem] isEnabled]];
446 // Mark the cell associated with the item as needing resizing.
(gdb) frame 6
#6 0x00000000461939e4 in -[NSMenuView itemChanged:] (self=0x4d3a5010, _cmd=0x4667eb40, notification=0x4b2d7a90) at NSMenuView.m:442
442 NSMenuItemCell *aCell = [self menuItemCellForItemAtIndex: index];
(gdb) print index
$1 = 0
(gdb)
$2 = 0
(gdb)

David, yes, I took the libffi 3.0.5 from that page. Running the testsuite indeed had 9 unexpected failures, and 15 unsupported tests.

in all tests up to now, ffcall and libffi were compiled using gcc 3.3.5.

now I'm going to compile these too with gcc 4.2.

Sebastian Reitenbach <buzzdee>
Project Member
Sat 24 May 2008 12:12:37 PM UTC, comment #15:

Hello Sebastian,

Thank you very much for trying to get GNUstep running in OpenBSD/sparc64. As an interested bystander I was wondering whether you have tried getting libffi directly from:

http://sourceware.org/libffi/

- and possibly comparing the differences to the your version
- running the libffi test suite
- reporting the failures at http://sourceware.org/ml/libffi-discuss/
- possibly coordinating with whoever is the maintainer of libffi for OpenBSD

Cheers,
David

David Ayers <ayers>
Project Member
Sat 24 May 2008 10:31:52 AM UTC, comment #14:

Now using gcc 4.2., installed from ports, linked against ffcall. gdnc also dies with a SIGBUS on application connection. After gdnc died, in the terminal window where the application runs, an error message regarding locking, as mentioned in bug report #22373, shows up:

$ openapp Gorm
2008-05-24 12:17:45.860 Gorm[4797] File NSLock.m: 611. In [GSLazyRecursiveLock -gcFinalize] objc_mutex_deallocate() failed

now going to recompile against libffi

Sebastian Reitenbach <buzzdee>
Project Member
Sat 24 May 2008 09:20:09 AM UTC, comment #13:

Again, recompiled against ffcall with gcc 3.3.5, gdnc dies with SIGBUS, again with the b0rked backtrace:

$ ps ax | grep gd
15476 ?? Is 0:00.06 syslogd: [priv] (syslogd)
17276 ?? I 0:03.81 syslogd -a /var/empty/dev/log
8647 ?? Is 0:00.05 /usr/GNUstep/System/Tools/gdomap -p
28223 p2- I 0:17.83 gdb --args /usr/GNUstep/Local/Applications/EasyDiff.app/EasyDiff
21331 p3 I 0:00.48 /usr/GNUstep/System/Tools/gdnc --daemon
26193 p3 R+/1 0:00.00 grep gd
$ gdb -p 21331
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc64-unknown-openbsd4.3".
Attaching to process 21331
0x82009202 in ?? ()
(gdb) bt
#0 0x82009202 in ?? ()
#1 0xffff45a8 in ?? ()
Previous frame identical to this frame (corrupt stack?)
(gdb) symbol-file /usr/GNUstep/System/Tools/gdnc
Reading symbols from /usr/GNUstep/System/Tools/gdnc...done.
(gdb) bt
#0 0x82009202 in ?? ()
#1 0xffff45a8 in ?? ()
Previous frame identical to this frame (corrupt stack?)
(gdb) c
Continuing.

Program received signal SIGBUS, Bus error.
0x82009205 in ?? ()
(gdb) bt
#0 0x82009205 in ?? ()
#1 0xffff3448 in ?? ()
Previous frame identical to this frame (corrupt stack?)
(gdb)

going to recompile with gcc 4.2 now.

Sebastian Reitenbach <buzzdee>
Project Member
Sat 24 May 2008 05:20:39 AM UTC, comment #12:

I made a mistake ... I think when I did my last tests I was logged on to the wrong system (was looking at solaris sparc64 too).

It may be that libffi works fine on solaris, but not bsd, or it may be (as Chris suggested) that it's a compiler version issue.

Anyway, I definitely found and fixed a bug in gdnc, but I'm no longer sure which is the correct library to use (ffcall or ffi) on bsd, or if either of them really works well.

So ... libffi definitely works on sparc64/solaris, but I still don't know what works on bsd. I'm away for the weekend, so won't be able to look at this again until monday evening at the earliest.

Richard Frith-Macdonald <CaS>
Project Member
Fri 23 May 2008 08:52:20 PM UTC, comment #11:

checked out svn of make, base, gui, back, projectcenter, systempreferences, and gorm.

gdnc seems to not crash anymore, the pid is still the same.
However, the application is still failing as descibed here:
https://savannah.gnu.org/bugs/?func=detailitem&item_id=23040
with the backtrace, regarding libffi, i guess, the applications seem to have problem to connect to gdnc.

I'm going to install gcc 4.x, and see whether this makes a difference.

Sebastian Reitenbach <buzzdee>
Project Member
Fri 23 May 2008 04:11:52 PM UTC, comment #10:

Sorry to mess you around, but I've gone back to ffi again. This is because I just couldn't get ffcall working at all for 64bit sparc, and I did find that libffi actually builds and installs easily on sparc64 (using version 3.0.5 from http://sourceware.org/libffi) and mostly works (not for passing structures).

Anyway, using libffi gdb I was able to track down a bug in gdnc.m, and things now seem to work ok for me (current code in svn trunk), at least for sa imple test.

Please have a go and let me know how it works.

Richard Frith-Macdonald <CaS>
Project Member
Sun 18 May 2008 01:33:02 PM UTC, comment #9:

completely reinstalled the whole box.
Installed gnustep-startup-0.19.3, linked against ffcall. The sources are in /usr/local/src.
account is again setted up as before, well, the ssh host key changed.

Sebastian Reitenbach <buzzdee>
Project Member
Fri 16 May 2008 05:27:15 PM UTC, comment #8:

Then I'm going to reinstall everything linked against ffcall again. I can then also take a gnustep-startup if you prefer?
otherwise I'd reinstall again from the ports system.

Sebastian Reitenbach <buzzdee>
Project Member
Fri 16 May 2008 04:31:10 PM UTC, comment #7:

Looks like ffi is no better than ffcall on sparc64
We need to find time to debug one of them ... perhaps ffcall as it seems to work on more platforms and be the usual default.

Richard Frith-Macdonald <CaS>
Project Member
Wed 07 May 2008 06:22:53 PM UTC, comment #6:

ok, installed libffi-3.0.5, and recompiled everything.

/usr/local/lib/libgnustep-base.so.1.15:
Start End Type Open Ref GrpRef Name
00000000475c4000 00000000480dc000 dlib 1 0 0 /usr/local/lib/libgnustep-base.so.1.15
0000000045f94000 00000000465b0000 rlib 0 1 0 /usr/lib/libobjc.so.4.0
000000004ed54000 000000004f394000 rlib 0 1 0 /usr/local/lib/libgmp.so.7.1
000000004d884000 000000004df30000 rlib 0 1 0 /usr/local/lib/libgnutls.so.13.0
0000000041980000 0000000041fdc000 rlib 0 2 0 /usr/local/lib/libgcrypt.so.13.0
000000004519c000 00000000457a0000 rlib 0 3 0 /usr/local/lib/libgpg-error.so.2.0
000000004e178000 000000004e784000 rlib 0 4 0 /usr/local/lib/libintl.so.4.0
000000004d0e4000 000000004d7de000 rlib 0 6 0 /usr/local/lib/libiconv.so.4.0
0000000049538000 0000000049b7c000 rlib 0 1 0 /usr/local/lib/libxslt.so.3.5
0000000043778000 0000000043ef6000 rlib 0 2 0 /usr/local/lib/libxml2.so.9.7
000000004a660000 000000004ac76000 rlib 0 4 0 /usr/lib/libz.so.4.1
0000000050410000 0000000050a3a000 rlib 0 3 0 /usr/lib/libm.so.2.3
0000000046e84000 000000004748a000 rlib 0 1 0 /usr/local/lib/libffi.so.5.6
00000000449dc000 0000000045006000 rlib 0 1 0 /usr/lib/libiberty.so.8.0

when I now start e.g. AddressManager, or ProjectCenter, then the gdnc does not crash anymore. But AddressManager, and ProjectCenter still crash. They also spit out a lot of error messages, that I before assumed they came from connection problems to gdnc, and repeatedly retrying to restart it.
But at least the pid of gdnc is the same before and after running an application. So acutally, I am not sure, whether the application actually contacted gdnc at all.

I'll output backtrace of AddressManager to the other bugreport.

Sebastian Reitenbach <buzzdee>
Project Member
Tue 06 May 2008 08:05:43 PM UTC, comment #5:

no problem when it takes longer.

there is no libffi in the ports, so I need to install it otherwise. I'll let you know how it works.

Sebastian Reitenbach <buzzdee>
Project Member
Tue 06 May 2008 06:27:59 PM UTC, comment #4:

Sorry to be so long getting back to you about this ... I kept hoping to find time to look at this in more detail, but never finding that time.
The quick answer is that ffcall seems not to work on sparc64 and you need to try using libffi instead. What I haven't had time to really look at is why ffcall doesn't work on sparc64. As a temporary solution I have tried modifying the configure script for the base library to build with libffi on sparc64 systems and to warn if someone tries to build with ffcall on these systems.

Richard Frith-Macdonald <CaS>
Project Member
Thu 01 May 2008 06:07:56 AM UTC, comment #3:

I've set up ssh account on the server.

I created a rfm account, and put your ssh keys into the home directory of that user. I hope you still have the information, where to connect to, otherwise I can resend it in private mail.

The GNUstep.sh is sourced via .profile for the rfm account.

Sebastian Reitenbach <buzzdee>
Project Member
Wed 30 Apr 2008 09:52:17 AM UTC, comment #2:

> I can try debugging it if you give me access to the box ...

I'll copy your ssh key over to this box, and send you login information later today.

> I think the process would be to start gdnc, attach gdb to it,
> then start something to connect to gdnc and wait for the
> crash.

this I tried already, but the stack is corrupt.

> Of course, doing anything depends on you having a working copy
> of gdb which can handle 64bit code.

the gdb should be fine, take a look at bug report: 23040
the backtrace is from the application that tries to connect to gdnc

Sebastian Reitenbach <buzzdee>
Project Member
Wed 30 Apr 2008 09:04:01 AM UTC, comment #1:

Most likely any sparc64 problems related to gdnc are to do with method invocation/forwarding via ffcall.

I can try debugging it if you give me access to the box ...

I think the process would be to start gdnc, attach gdb to it, then start something to connect to gdnc and wait for the crash. If the stack is already too corrupt to tell us anything at that point, we would have to set a breakpoint somewhere in the NSConnection or NSPort code and catch the incoming connection before it attempts to invoke the method on the loacl object, then step through to see what's happening.

Of course, doing anything depends on you having a working copy of gdb which can handle 64bit code.

Richard Frith-Macdonald <CaS>
Project Member
Thu 24 Apr 2008 06:17:04 PM UTC, original submission:

I freshly installed a OpenBSD 4.3 on the sparc64, and used the following versions:
ffcall-1.10
gnustep-make-2.0.5
gnustep-base-1.15.3p0
gnustep-back-0.13.2
gnustep-gui-0.13.2

gcc -v
Reading specs from /usr/lib/gcc-lib/sparc64-unknown-openbsd4.3/3.3.5/specs
Configured with:
Thread model: single
gcc version 3.3.5 (propolice)

gdomap, gdnc, and gpbs are running.
when starting the first application, gdnc crashes.

unfortunately the backtrace is useless:

gdb -c gdnc.core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc64-unknown-openbsd4.3".
Core was generated by `gdnc'.
Program terminated with signal 6, Aborted.
#0 0x0000000045ea4eec in ?? ()
(gdb) bt
#0 0x0000000045ea4eec in ?? ()
#1 0x0000000045ea4eec in ?? ()
Previous frame identical to this frame (corrupt stack?)

Its the same, when I try to connect to the process via gdb -p <gdnc pid>

I tried to run the gdnc from within gdb, but after some time it spawned a child, and gdb returned and was unable to debug the child.

It doesn't matter what application I start, gdnc crashes all the time.

Any idea on how to debug this? I could also provide access to that box.

Sebastian Reitenbach <buzzdee>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ayers (Posted a comment)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by buzzdee (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-12-29 CaS Open/ClosedOpen => Closed
    2008-12-29 CaS StatusIn Progress => Fixed
    2008-05-24 CaS StatusFixed => In Progress
        Open/ClosedIn Test => Open
    2008-05-23 CaS StatusNone => Fixed
        Open/ClosedOpen => In Test

    Back to the top


    Powered by Savane 3.4