Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* GDB mainline segfaults on 32bit threaded program.
@ 2004-07-06 20:59 Manoj Iyer
  2004-07-07 14:47 ` Manoj Iyer
  0 siblings, 1 reply; 2+ messages in thread
From: Manoj Iyer @ 2004-07-06 20:59 UTC (permalink / raw)
  To: gdb


GDB (mainline cvs) built 32bit on ppc64 machine running sles9 dumps core
on a multithreaded program. gdb segfaults only when I set a breakpoint on
the thread fucntion and decide to stop there.

1. cc -o tbug_dwarf2 tbug.c -g dwarf-2 -lpthread
2. gdb tbug_dwarf2
3. br main
4. br tf
5. run <---- segfalts here
6. c


Attached is a testcase that can re-create this problem "tbug.c"

I used GDB to debug this core produced, here is the backtrace...
#0  0x0fe05694 in strcmp () from /lib/tls/libc.so.6
#1  0x100cfba8 in lookup_symtab (name=0xffffc360 "/root/manjo/tbug.c")
    at symtab.c:185
#2  0x100d9254 in symtab_from_filename (argptr=0xffffc480, p=0x104caafa
":tf",
    is_quote_enclosed=0, not_found_ptr=0x0) at linespec.c:1523
#3  0x100d99c4 in decode_line_1 (argptr=0xffffc480, funfirstline=1,
    default_symtab=0x0, default_line=0, canonical=0x0, not_found_ptr=0x0)
    at linespec.c:744
#4  0x100a432c in breakpoint_re_set_one (bint=0x104ca958) at
breakpoint.c:7157
#5  0x10051748 in do_catch_errors (uiout=0x104ca958, data=0x0) at
top.c:524
#6  0x10053d20 in catcher (func=0x1005172c <do_catch_errors>,
    func_uiout=0x104712c8, func_args=0xffffc848, func_val=0xffffc850,
    func_caught=0xffffc854,
    errstring=0x7f7f7f7f <Address 0x7f7f7f7f out of bounds>,
gdberrmsg=0x0,
    mask=6) at top.c:431
#7  0x10053d80 in catch_errors (func=0xffffc2f0, func_args=0x104cbeb8,
    errstring=0x7f7f7f7f <Address 0x7f7f7f7f out of bounds>, mask=0)
    at top.c:536
#8  0x100a2b14 in breakpoint_re_set () at breakpoint.c:7340
#9  0x100d2bd4 in new_symfile_objfile (objfile=0x104ca958, mainline=0,
verbo=0)
    at symfile.c:741
#10 0x100d4634 in symbol_file_add_with_addrs_or_offsets (abfd=0x104d0220,
    from_tty=0, addrs=0x0, offsets=0x0, num_offsets=0, mainline=0,
flags=8)


The macro FILENAME_CMP in symtab.c:185 uses the strcmp to do the
comparison, symtab_to_fullname() function returns NULL for s->fullname and
this causes strcmp to segfault. Although syntab.c:185 checks if full_path
!= NULL but it does not check if  const char *fp = symtab_to_fullname (s);
is not equal to NULL. I dont know what causes symtab_to_fullname() to
return NULL.

Thanks
Manoj Iyer


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: GDB mainline segfaults on 32bit threaded program.
  2004-07-06 20:59 GDB mainline segfaults on 32bit threaded program Manoj Iyer
@ 2004-07-07 14:47 ` Manoj Iyer
  0 siblings, 0 replies; 2+ messages in thread
From: Manoj Iyer @ 2004-07-07 14:47 UTC (permalink / raw)
  To: gdb

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2367 bytes --]


Sorry forgot to attach the testcase.

--
Manjo


On Tue, 6 Jul 2004, Manoj Iyer wrote:

>
> GDB (mainline cvs) built 32bit on ppc64 machine running sles9 dumps core
> on a multithreaded program. gdb segfaults only when I set a breakpoint on
> the thread fucntion and decide to stop there.
>
> 1. cc -o tbug_dwarf2 tbug.c -g dwarf-2 -lpthread
> 2. gdb tbug_dwarf2
> 3. br main
> 4. br tf
> 5. run <---- segfalts here
> 6. c
>
>
> Attached is a testcase that can re-create this problem "tbug.c"
>
> I used GDB to debug this core produced, here is the backtrace...
> #0  0x0fe05694 in strcmp () from /lib/tls/libc.so.6
> #1  0x100cfba8 in lookup_symtab (name=0xffffc360 "/root/manjo/tbug.c")
>     at symtab.c:185
> #2  0x100d9254 in symtab_from_filename (argptr=0xffffc480, p=0x104caafa
> ":tf",
>     is_quote_enclosed=0, not_found_ptr=0x0) at linespec.c:1523
> #3  0x100d99c4 in decode_line_1 (argptr=0xffffc480, funfirstline=1,
>     default_symtab=0x0, default_line=0, canonical=0x0, not_found_ptr=0x0)
>     at linespec.c:744
> #4  0x100a432c in breakpoint_re_set_one (bint=0x104ca958) at
> breakpoint.c:7157
> #5  0x10051748 in do_catch_errors (uiout=0x104ca958, data=0x0) at
> top.c:524
> #6  0x10053d20 in catcher (func=0x1005172c <do_catch_errors>,
>     func_uiout=0x104712c8, func_args=0xffffc848, func_val=0xffffc850,
>     func_caught=0xffffc854,
>     errstring=0x7f7f7f7f <Address 0x7f7f7f7f out of bounds>,
> gdberrmsg=0x0,
>     mask=6) at top.c:431
> #7  0x10053d80 in catch_errors (func=0xffffc2f0, func_args=0x104cbeb8,
>     errstring=0x7f7f7f7f <Address 0x7f7f7f7f out of bounds>, mask=0)
>     at top.c:536
> #8  0x100a2b14 in breakpoint_re_set () at breakpoint.c:7340
> #9  0x100d2bd4 in new_symfile_objfile (objfile=0x104ca958, mainline=0,
> verbo=0)
>     at symfile.c:741
> #10 0x100d4634 in symbol_file_add_with_addrs_or_offsets (abfd=0x104d0220,
>     from_tty=0, addrs=0x0, offsets=0x0, num_offsets=0, mainline=0,
> flags=8)
>
>
> The macro FILENAME_CMP in symtab.c:185 uses the strcmp to do the
> comparison, symtab_to_fullname() function returns NULL for s->fullname and
> this causes strcmp to segfault. Although syntab.c:185 checks if full_path
> != NULL but it does not check if  const char *fp = symtab_to_fullname (s);
> is not equal to NULL. I dont know what causes symtab_to_fullname() to
> return NULL.
>
> Thanks
> Manoj Iyer
>

[-- Attachment #2: TEST CASE --]
[-- Type: TEXT/x-csrc, Size: 872 bytes --]

#include <string.h>
#include <unistd.h>
#include <pthread.h>
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>

#define N       2

static void *
tf (void *arg)
{
  int n = (int) (long int) arg;
  char number[160];
  sprintf(number, "tf(%ld): begin", (long)arg);
  puts (number);

 sleep (10);
  sprintf(number, "tf(%ld): end", (long)arg);
  puts (number);
  return NULL;
}

int main (int argc, char *argv[])
{
  int n;
  pthread_t th[N];

  for (n = 0; n < N; ++n)
    if (pthread_create (&th[n], NULL, tf, (void *) (long int) n) != 0)
      {
        sleep(2);
        puts ("create failed");
        exit (1);
      }

  puts("after create");

  for (n = 0; n < N; ++n)
    if (pthread_join (th[n], NULL) != 0)
      {
        puts ("join failed");
        exit (1);
      }


  puts("after join");
  return 0;
}

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2004-07-07 14:47 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-07-06 20:59 GDB mainline segfaults on 32bit threaded program Manoj Iyer
2004-07-07 14:47 ` Manoj Iyer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox