Problems with glibc and gdb on Alpha (SX164 2.2.7) (fwd)

[hjl@lucon.org (H.J. Lu)]

From slouken@devolution.com  Thu May 13 16:10:26 1999
Return-Path: <slouken@devolution.com>
Delivered-To: hjl@lucon.org
Received: from roboto.devolution.com (roboto.devolution.com [204.247.175.130])
	by ocean.lucon.org (Postfix) with ESMTP id 027C657B7
	for <hjl@lucon.org>; Thu, 13 May 1999 16:10:25 -0700 (PDT)
Received: from slouken by roboto.devolution.com with local (Exim 2.11 #1)
	id 10i4dZ-0004Fi-00; Thu, 13 May 1999 16:11:33 -0700
To: hjl@lucon.org (H.J. Lu)
Cc: slouken@devolution.com, highlander@lokigames.com
Subject: Problems with glibc and gdb on Alpha (SX164 2.2.7)
X-Mailer: My Mailer 1.5  <slouken@devolution.com>
Message-Id: <E10i4dZ-0004Fi-00@roboto.devolution.com>
From: Sam Lantinga <slouken@devolution.com>
Date: Thu, 13 May 1999 16:11:33 -0700

Okay, I'm trying to track down a memory stomping bug on Alpha SX164
running Linux 2.2.7.

I have the gdb and glibc that shipped with RedHat 6.0
GNU gdb 4.17.0.11 with Linux support
/lib/libc-2.1.1.so

First problem:
The backtrace() API doesn't seem to work.  It returns 0.
I stepped into the call with a debug version of glibc:
__backtrace (array=0x1201507e8, size=8192) at ../sysdeps/generic/backtrace.c:66
66	  int cnt = 0;
(gdb) list
61	     int size;
62	{
63	  struct layout *current;
64	  void *top_frame;
65	  void *top_stack;
66	  int cnt = 0;
67	
68	  top_frame = __builtin_frame_address (0);
69	  top_stack = CURRENT_STACK_FRAME;
70	
(gdb) 
71	  /* We skip the call to this function, it makes no sense to record it.  */
72	  current = (struct layout *) top_frame;
73	  while (cnt < size)
74	    {
75	      if ((void *) current INNER_THAN top_stack
76		  || !((void *) current INNER_THAN __libc_stack_end))
77	       /* This means the address is out of range.  Note that for the
78		  toplevel we see a frame pointer with value NULL which clearly is
79		  out of range.  */
80		break;

(gdb) n
69	  top_stack = CURRENT_STACK_FRAME;
(gdb) 
72	  current = (struct layout *) top_frame;
(gdb) 
73	  while (cnt < size)
(gdb) print current
$2 = (struct layout *) 0x11ffffa20
(gdb) print top_stack
$3 = (void *) 0x11ffffa30
(gdb) print __libc_stack_end
$4 = (void *) 0x11ffffab0
(gdb) print *current
$5 = {next = 0x120005948, return_address = 0x11ffffa40}
(gdb) print *current->next
$6 = {next = 0x23bd090827ba0015, return_address = 0xb02f001044000401}
(gdb) bt
#0  __backtrace (array=0x1201507e8, size=8192)
    at ../sysdeps/generic/backtrace.c:73
#1  0x120005948 in foo () at t.c:15
#2  0x120005a08 in main (argc=1, argv=0x11ffffac8) at t.c:23
#3  0x120005b10 in __libc_start_main (main=0x1200059e0 <main>, argc=1, 
    argv=0x11ffffac8, init=0x1200057c0 <_init>, fini=0x120044000 <_fini>, 
    rtld_fini=0x1201507e8 <symbols>, stack_end=0x11ffffab0)
    at ../sysdeps/generic/libc-start.c:78


Second problem:
I added lots of debugging to malloc.c, to find out where the problem is,
but gdb won't give me a full backtrace:
Ack!
Hit me! ((char*)p + sz <= (char*)(((mbinptr)((char*)&(((ar_ptr)->av)[2*(0) + 2]) - 2*(sizeof(size_t))))->fd))

Program received signal SIGINT, Interrupt.
0x121532148 in __libc_nanosleep () at __libc_nanosleep:-1
__libc_nanosleep:-1: No such file or directory.
Current language:  auto; currently c
(gdb) bt
#0  0x121532148 in __libc_nanosleep () at __libc_nanosleep:-1
#1  0x121532080 in __sleep (seconds=536868536)
    at ../sysdeps/unix/sysv/linux/sleep.c:78
#2  0x1214eaa28 in do_check_chunk (ar_ptr=0x11ffff5a8, p=0x100000000)
    at malloc.c:2188
#3  0x1214eb324 in do_check_inuse_chunk (ar_ptr=0x121a9cf38, p=0x122730a20)
    at malloc.c:2232
(gdb) 

The backtrace shows my malloc debugging hooks, but nothing about where
the function was called from.

Third problem:
The program is multi-threaded, and pthread_self() crashes if I link with
the dmalloc library.  It crashes at:
  return THREAD_GETMEM(self, p_tid);
which is defined to be:
	self->p_tid

Fourth problem:
gdb crashes if I try to print malloc_stats() from the command line.
It works fine in a simple test program, but when I break anywhere in the
game, it runs malloc_stats() and then crashes, apparently in a random C
library function: 
main (argc=1, argv=0x11ffffb78) at ctp/civ3_main.cpp:2211
2211		Setup_FPU();
(gdb) print malloc_stats()
Arena 0:
system bytes     =      53520
in use bytes     =      47712
Total (incl. mmap):
system bytes     =      53520
in use bytes     =      47712
max system bytes =      53520
max mmap regions =          0
max mmap bytes   =          0

Program received signal SIGSEGV, Segmentation fault.
getenv (name=0x121626728 "LD_WARN") at ../sysdeps/generic/getenv.c:84
../sysdeps/generic/getenv.c:84: No such file or directory.
The program being debugged stopped while in a function called from GDB.
When the function (malloc_stats) is done executing, GDB will silently
stop (instead of continuing to evaluate the expression containing
the function call).
(gdb) 

If any of the above problems can be fixed, I can find the problem.
I told you everything in the hopes that you can see a pattern or a
solution that I haven't.

I will get gdb-4.17.0.12 and gdb-4.18 in the hopes that one of them
will work, and keep going, but if you can see a solution, it would be 
GREATLY appreciated. :)

Thanks!
	-Sam Lantinga				(slouken@devolution.com)

Lead Programmer, Loki Entertainment Software
--
"Any sufficiently advanced bug is indistinguishable from a feature"
						 -- Rich Kulawiec 


-- 
H.J. Lu (hjl@gnu.org)