Package: gdb
Version: 6.0-2
Severity: normal
Tags: sid
While trying to get the highly i386-centric hhexen code going on ppc, I ran
into a segfault. Asking a backtrace in gdb produced a rather interesting
result:
...
skill 2, episode 1, map 1 skill 2, episode 1, map 1
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 1934)]
P_LoadACScripts (lump=808426069) at base/p_acs.c:310
310 ACScriptCount = *buffer++;
(gdb) bt
#0 P_LoadACScripts (lump=808426069) at base/p_acs.c:310
#1 0x10040a44 in P_SetupLevel (episode=808426069, map=45, playermask=3340, skill=55) at base/p_setup.c:1100
#2 0x10019de8 in G_DoLoadLevel () at base/g_game.c:633
#3 0x1001b4d4 in G_InitNew (skill=sk_baby, episode=1, map=0) at base/g_game.c:1673
#4 0x1001afd8 in G_StartNewGame (skill=sk_medium) at base/g_game.c:1332
#5 0x1001b31c in G_DoNewGame () at base/g_game.c:1587
#6 0x1001a6f4 in G_Ticker () at base/g_game.c:835
#7 0x100183d8 in TryRunTics () at base/d_net.c:891
#8 0x1001c5e0 in H2_GameLoop () at base/h2_main.c:550
#9 0x1001bdd0 in H2_Main () at base/h2_main.c:301
#10 0x1000f308 in main (argc=-200605696, argv=0x7ffffa24) at base/i_linux.c:1733
Note that skill _appears_ to have suddenly changed from 2 (sk_medium) to 0
(sk_baby) from the 4th to the 3th frame. However, definitely not by the
hhexen code... In reality, the input variable to G_StartNewGame() is only
used when passing it along to G_InitNew(). And effectively, as a fprintf()
which is the first statement inside G_InitNew() shows - the first of the two
"skill 2, ...\t" outputs right before the segfault - the value passed is
still 2.
Similarly further on:
(gdb) l base/g_game.c:633
628 memset (players[i].frags,0,sizeof(players[i].frags));
629 }
630
631 SN_StopAllSequences();
632 fprintf (stderr, "skill %d, episode %d, map %d\t", gameskill, gameepisode, gamemap);
633 P_SetupLevel (gameepisode, gamemap, 0, gameskill);
634 displayplayer = consoleplayer; // view the guy you are playing
635 starttime = I_GetTime ();
636 gameaction = ga_nothing;
637 Z_CheckHeap ();
As you can see, the second of those "skill..." outputs before the segfault
comes from inside G_DoLoadLevel(), using file global variables set by
G_InitNew(). They are still as they should be, and they are passed unchanged
to P_SetupLevel() right after that fprintf() - but gdb prints very different
values to the P_SetupLevel() call. (Note also that a literal 0 is used as
the third argument, which gdb manages to change into something completely
different in the backtrace)
This is an ppc running up to date sid. Application is CVS from hhexen
(:pserver:[email protected]:/cvs/cvsroot, password "anonymous",
module hhexen) with the attached patch. Run autogen.sh, copy config.* from
autotools-dev, be sure to have sdl, gl & glu dev libs installed, ./configure
--enable-gl, make, gdb ./hhexen-gl, run -g (mandatory within gdb to avoid
focus grab) and hit enter 4 times at the intro screen to start a new level -
segfault. Oh, and you need a data .wad file from a dos installation; if you
don't have hexen the demo .wad reportedly should work too, if you enable it
with some ./configure flag.
Regards,
Filip
-- System Information:
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux aegir 2.4.20-ben10 #4 Mon Jun 23 19:34:48 CEST 2003 ppc
Locale: LANG=nl_BE@euro, LC_CTYPE=nl_BE@euro
Versions of packages gdb depends on:
ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an
ii libncurses5 5.3.20030719-4 Shared libraries for terminal hand
ii libreadline4 4.3-8 GNU readline and history libraries
-- no debconf information
--
I have not lost my mind, its backed up on tape somewhere
Subject: Re: Bug#224014: gdb: reports incorrect argument values for function calls
Date: Sun, 14 Dec 2003 22:25:37 -0500
On Sun, Dec 14, 2003 at 07:17:47PM +0100, Filip Van Raemdonck wrote:
> Package: gdb
> Version: 6.0-2
> Severity: normal
> Tags: sid
>
> While trying to get the highly i386-centric hhexen code going on ppc, I ran
> into a segfault. Asking a backtrace in gdb produced a rather interesting
> result:
>
> ...
> skill 2, episode 1, map 1 skill 2, episode 1, map 1
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 1934)]
> P_LoadACScripts (lump=808426069) at base/p_acs.c:310
> 310 ACScriptCount = *buffer++;
> (gdb) bt
> #0 P_LoadACScripts (lump=808426069) at base/p_acs.c:310
> #1 0x10040a44 in P_SetupLevel (episode=808426069, map=45, playermask=3340, skill=55) at base/p_setup.c:1100
> #2 0x10019de8 in G_DoLoadLevel () at base/g_game.c:633
> #3 0x1001b4d4 in G_InitNew (skill=sk_baby, episode=1, map=0) at base/g_game.c:1673
> #4 0x1001afd8 in G_StartNewGame (skill=sk_medium) at base/g_game.c:1332
> #5 0x1001b31c in G_DoNewGame () at base/g_game.c:1587
> #6 0x1001a6f4 in G_Ticker () at base/g_game.c:835
> #7 0x100183d8 in TryRunTics () at base/d_net.c:891
> #8 0x1001c5e0 in H2_GameLoop () at base/h2_main.c:550
> #9 0x1001bdd0 in H2_Main () at base/h2_main.c:301
> #10 0x1000f308 in main (argc=-200605696, argv=0x7ffffa24) at base/i_linux.c:1733
>
> Note that skill _appears_ to have suddenly changed from 2 (sk_medium) to 0
> (sk_baby) from the 4th to the 3th frame. However, definitely not by the
> hhexen code... In reality, the input variable to G_StartNewGame() is only
> used when passing it along to G_InitNew(). And effectively, as a fprintf()
> which is the first statement inside G_InitNew() shows - the first of the two
> "skill 2, ...\t" outputs right before the segfault - the value passed is
> still 2.
This is a pretty common thing with GDB. The debug information is not
verbose enough to track when the register becomes unavailable. For
some other architectures a new, more reliable mechanism has been
implemented - but no one has converted PowerPC yet.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer