Subject: Shared lib weirdness on Sep.27 mac68k
To: Ken Nakata <kenn@remus.rutgers.edu>
From: David Gilbert <dgilbert@pci.on.ca>
List: current-users
Date: 09/29/1995 17:32:46
>>>>> "Ken" == Ken Nakata <kenn@remus.rutgers.edu> writes:
Ken> I clean-built a GENERIC kernel current as of 27th, and it fails
Ken> to run any dynamically linked binaries. Ktrace shows all failing
Ken> binaries get SIGSEGV after closing shared libc file, but it tells
Ken> me nothing about what the failing program was doing between
Ken> closing shared libc and getting signal.
Ken> So, I picked hexdump (for no particular reason), compiled it with
Ken> -g flag, and tried it under the new kernel. It dumped a core
Ken> just like before, but later when I tried to see what was going on
Ken> with gdb on a good kernel (9/23), gdb refused to load the core
Ken> complaining it's not a core file... (file, OTOH, says the said
Ken> core file is a netbsd-core file)
Ken> Does anyone have any idea what might be going on? This is the
Ken> mac68k port I'm using. I need to compile a working kernel in
Ken> order to test my floating point emulator...
curiouser and curiouser! My Sun4/260 is having a similar
problem running Xsun --- it runs a little bit, and core dumps. When
it dumps, gdb will not read the core file with that complaint. I
would have rebuilt the kernel around that time too. That said, I
havn't had Xsun running yet, and the device driver for the cgtwo0 that
I have is suspect, but FYI... here's the stack trace I get when I run
Xsun under gdb from the start:
Program received signal SIGSEGV (11), Segmentation fault
0x3e74 in CG2SaveScreen ()
(gdb) bt
#0 0x3e74 in CG2SaveScreen ()
#1 0x4660 in sunInitCommon ()
#2 0x3fd0 in sunCG2Init ()
#3 0x1d9a4 in AddScreen ()
#4 0x3530 in InitOutput ()
#5 0x1d0f4 in main ()
(gdb)
Dave.
--
----------------------------------------------------------------------------
|David Gilbert, PCI, Richmond Hill, Ontario. | Two things can only be |
|Mail: dgilbert@pci.on.ca | equal if and only if they |
|http://www.pci.on.ca/~dgilbert | are precisely opposite. |
---------------------------------------------------------GLO----------------