Follow-up Comment #5, bug #26766 (project gnustep):
While advice about killing all existing processes and then making sure only
one copy of gdnc is running is good, the problem is a segmentation fault
rather than an exception, so there is an issue in the local process (even if
it's triggered by something else going on in a remote one), so I don't think
looking at gdnc will help.
The segfault is at 'NSDistributedNotificationCenter.m:782' which (assuming
the code is running a recent version of the base library) is in the call to
-registerClient: in the gdnc process ... ie it's at the point when handling
sending of a DO method or receiving its response.
That pretty much isolates the issue to the ffcall or ffi library and/or its
interaction with gnustep-base. I don't know what system this is running on,
but the gdb warning 'Using host libthread_db library
"/lib64/libthread_db.so.1".' suggests it's a 64bit cpu, and we know that
support for 64bit systems in libffi and ffcall has historically been rather
weak, so the thing to do would be to check that the base library is linked
with the latest available libffi (which might mean something more recent than
whatever comes with the operating system).
If that doesn't work then the thing to do is set a breakpoint at
NSDistributedNotificationCenter.m:782 and then step through instruction by
instruction to find where things are going wrong ... if the crash is inside
libffi itsself, this would also need you to get the source for libffi and
build/use it so that gdb could show you the code as you step through.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?26766>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep
