Solaris 10 Compile

[wrmichael]

dbx ->

signal SEGV (no mapping at the fault address) in Receive_objflags at 0x3d98c
0x0003d98c: Receive_objflags+0x0140: stb %g1, [%o5 + 1968]


:TT8888888888888TTTTTTTTTT888888 TiiiiiiiiiiiiiTTTTTTTTT8888TTTTii:
:iTT88888888888TTTTTTTTTTTT88888 TiiiiTTTTTTTTTTT88888888888TTTTTi:
::TT8888888TTTTTTTTTTTTTTTTT8888: : iiiiiTTTTTTTT888888888888TTTTTii:
::iiTTTTTTTTTTTTTiiiiiiTTTTTTT88 ii. :iiiTTTTTT8888888888888TTTTTiiii:
::iiiTTTTTTTiiiiiiiiTTTTTTTTT888. .T8ii.. iiiiTTTTTT8888888TTTTTTTTiiiiii::'
``:::::iiiiiiiiiiTTTTTTTTTTT8888888TTTiiiiiiiiTTTTTTTTTTTTTTTTiiiiiiii:::'
``::::::iiiTTTTTTTTTT8888888TTTTTTTTiiiTTTTTTTTTTTTTTTTTTTiii::'''
MAngband v1.1.2 (27th Apr 2009) Press ? for help in gamesignal SEGV (no mapping at the fault address) in Receive_objflags at 0x3d98c
0x0003d98c: Receive_objflags+0x0140: stb %g1, [%o5 + 1968]
(dbx) WHERE
WHERE: not found
(dbx) where
=>[1] Receive_objflags(0x1, 0xb36b0, 0xc50, 0x0, 0x62158, 0x61514), at 0x3d98c
[2] Net_packet(0xc50, 0xd36c0, 0xc50, 0x0, 0x6222c, 0xc50), at 0x3b360
[3] Net_input(0x1, 0x3e8, 0x3, 0x1, 0x9e2c8, 0x5f578), at 0x3b5bc
[4] 0x34a80(0x0, 0x62170, 0x621c0, 0x0, 0x0, 0x0), at 0x34a80
[5] client_init(0x0, 0x0, 0x0, 0x4, 0x0, 0x67780), at 0x353d0
[6] main(0x1, 0xffbffd64, 0xffbffd6c, 0x93e6c, 0xff310100, 0x0), at 0x495cc
(dbx)

using gdb

MAngband v1.1.2 (27th Apr 2009) Press ? for help in game
Program received signal SIGSEGV, Segmentation fault.
0x0003d98c in Receive_objflags ()
(gdb) where
#0 0x0003d98c in Receive_objflags ()
#1 0x0003b368 in Net_packet ()
#2 0x0003b5c4 in Net_input ()
#3 0x00034a88 in ?? ()
#4 0x00034a88 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

Thought I might get a better view of the problem. but it doesn't look like it....

[Billsey]

See if either of the debuggers will tell you the state of rbuf when the error occurs. If I were a betting man, I'd bet the issue will be in the results returned from either Packet_scanf() or rle_decode().

[wrmichael]

gdb

This GDB was configured as "sparc-sun-solaris2.10"...
(no debugging symbols found)
/export/home/waynem/mb/./core: Permission denied.
(gdb) run
Starting program: /export/home/waynem/mb/mangclient
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0x0003d98c in Receive_objflags ()
(gdb) print rbuf
$1 = 8
(gdb)

dbx

(dbx) run
Running: mangclient
(process id 24991)
Reading libc_psr.so.1
signal SEGV (no mapping at the fault address) in Receive_objflags at 0x3d98c
0x0003d98c: Receive_objflags+0x0140: stb %g1, [%o5 + 1968]
(dbx) print rbuf
dbx: warning: unknown language, 'c' assumed
rbuf = 6
(dbx)

Starting program: /export/home/waynem/mb/mangclient
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
/export/home/waynem/mb/mangclient: Error (Incorrect password) reading savefile.

Program exited with code 0377.
(gdb) where
No stack.
(gdb) print rbuf
$1 = 0
(gdb)

looks like I get different results.

[Flambard]

I'd say we're either looking at faulty code in Receive_objflags (and there's reason to suspect it, as it was added relatively recently), either at more fundamental data-type problem in networking code.

If you can step-throu Receive_objflags, I'm pretty sure you'll find a problem there. I'd be very suspicous of unitialized variables, those passed to Packet_ functions espessially (y, c, a).

If that's not the case, and it's a networking issue indeed, tracking it down might be harder. I gather you're running a sparc processor, which suggests some unique datatype sizes and what not (I have no expertise in that, just guessing). The code in question uses bytes/chars tho, so I'm not sure if that's relevant. Some relevant information is provided at http://mangband.org/developer/ticket/822 . We never had REAL problems with the issues mentioned there, thus low-priority mark, but our testing base is fairly limited, sparc/Solaris might very well be affected.

P.S. If the server runs fine and allows Windows clients to play on it, we can probably rule out the data-type error possibility, and concentrate on buggy Receive_objflags code :)

[wrmichael]

I can spend some time on it next weekend, this weekend is a boy scout camping trip.

I am not a active unix C programmer, mostly work with java,.Net and other scripting languages but I can work through the code.

if you anyone has desire I can arrange a ssh connection and they can look, but since your solaris user base is small I can see how it would be a low priority.

I'll keep you posted.

[Flambard]

I'll gladly take a look via ssh. Thanks for your time and interest in the subject matter. Oh, and have a nice trip :)