Bus error when attempting to use carl on NeXTSTEP 3.3 on m68k
larb0b opened this issue · comments
Running carl through micro_inetd over port 8765.
carl compiled with cc -O3 carl.c -o carl.
https://i.imgur.com/rHW1pV5.jpeg
Through gdb:
Program generated(1): Memory access exception on address 0x0 (protection failure).
0xe358 in mutex_try_lock ()
Any difference on lower optimization settings?
That backtrace unfortunately is not very useful. Can you compile it with -g to get some additional symbols?
(And do a bt full so we can see everything)
And the compiler version as well, just to make sure it's the same as 3.3 on hppa.
micro_inetd compiled with
cc -g -O0 micro_inetd.c -o micro_inetd -lposix
carl compiled with
cc -g -O0 carl.c -o carl
erebus> gdb micro_inetd/micro_inetd
GDB is free software and you are welcome to 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.
GDB 4.7 (NeXT 3.1), Copyright 1992 Free Software Foundation, Inc...
Reading symbols from /me/Projects/micro_inetd/micro_inetd...done.
(gdb) r 8765 cryanc/carl -p
Starting program: /me/Projects/micro_inetd/micro_inetd 8765 cryanc/carl -p
Program generated(1): Memory access exception on address 0x0 (protection failure).
0xe358 in mutex_try_lock ()
(gdb) bt full
No symbol "full" in current context.
(gdb) bt
#0 0xe358 in mutex_try_lock ()
#1 0x934c in _malloc_fork_prepare ()
#2 0x4fc8 in _cthread_fork_prepare ()
#3 0x4444 in fork ()
cc -v output
Reading specs from /lib/m68k/specs
NeXT Computer, Inc. version cc-437.2.6, gcc version 2.5.8
I'm not sure how to get this ancient gdb to read symbols from carl as well while running it under micro_inetd.
Don't worry -- this strongly suggests the problem is actually in micro_inetd because carl doesn't fork. If you run carl https://some.site/ does that work right?
I remember something similar with A/UX when I added -lbsd to get micro_inetd to work and I don't remember what I had to do. I'm still surprised it's required for m68k NeXTSTEP.
After doing some reading around, -lposix is generally not recommended it seems.
http://www.nextcube.org/board/browse/1118/2742
Adding #define waitpid(p, s, o) wait3((union wait *)(s), (o), (struct rusage *) 0) to micro_inetd.c instead of using -lposix did the trick and micro_inetd seems to be working fine now (and carl actually already was, as you suggested)!
Excellent! This makes me wonder if I should be maintaining a micro_inetd fork but at least this will help people figure out how it works. Still surprised this didn't work out of the box on the 68K NeXT.
whoops