Ubuntu

gdb crashed with SIGSEGV in iterate_over_threads()

Reported by Fabien Tassin on 2008-08-16
56
This bug affects 3 people
Affects Status Importance Assigned to Milestone
gdb (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: gdb

This is on Intrepid.
gdb is crashing very often on mozilla products

To reproduce, simply try:

gdb /usr/lib/firefox-3.0.1/firefox
run

(you may have to adjust the firefox path depending on which version you are currently running)

2 out of 3 times, gdb crashes and firefox starts anyway.

ProblemType: Crash
Architecture: i386
CrashCounter: 1
DistroRelease: Ubuntu 8.10
ExecutablePath: /usr/bin/gdb
NonfreeKernelModules: nvidia
Package: gdb 6.8-3ubuntu1
ProcAttrCurrent: unconfined
ProcCmdline: /usr/bin/gdb /usr/lib/firefox-3.1a2pre/firefox-3.1 -x /tmp/mozargs.d32727
ProcEnviron:
 SHELL=/usr/bin/tcsh
 PATH=/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
 LANG=en_US.UTF-8
Signal: 11
SourcePackage: gdb
StacktraceTop:
 ?? ()
 iterate_over_threads ()
 ?? ()
 resume ()
 ?? ()
Title: gdb crashed with SIGSEGV in iterate_over_threads()
Uname: Linux 2.6.26-5-generic i686
UserGroups: adm admin audio cdrom dip floppy fuse kvm libvirtd lpadmin plugdev pulse-rt scanner video

Fabien Tassin (fta) wrote :

StacktraceTop:clear_lwpid_callback (thread=0x9e39b60, dummy=0x0)
iterate_over_threads (callback=0x80a31a0 <clear_lwpid_callback>, data=0x0)
thread_db_resume (ptid={pid = 32732, lwp = 32732, tid = 0}, step=1, signo=TARGET_SIGNAL_0)
resume (step=1, sig=TARGET_SIGNAL_0) at /build/buildd/gdb-6.8/gdb/infrun.c:651
keep_going (ecs=0xbfb2a9a4) at /build/buildd/gdb-6.8/gdb/infrun.c:2975

Changed in gdb:
importance: Undecided → Medium
Ludovico Cavedon (cavedon) wrote :

Confirming this bug:

cavedon@cavedon-laptop:~/pulse/alsatest$ PULSE_LOG=5 sudo gdb pulseaudio
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
(gdb) r
Starting program: /usr/bin/pulseaudio
[Thread debugging using libthread_db enabled]
[New process 26860]
Executing new program: /usr/bin/pulseaudio
warning: Cannot initialize thread debugging library: generic error
warning: Cannot initialize thread debugging library: generic error
warning: Cannot initialize thread debugging library: generic error
warning: Cannot initialize thread debugging library: generic error
[New process 26860]
[Thread debugging using libthread_db enabled]
Segmentation fault (core dumped)
cavedon@cavedon-laptop:~/pulse/alsatest$ W: main.c: This program is not intended to be run as root (unless --system is specified).
E: core-util.c: Home directory /home/cavedon not ours.

cavedon@cavedon-laptop:~/pulse/alsatest$

Changed in gdb (Ubuntu):
status: New → Confirmed
Matthias Klose (doko) wrote :

confirming a bug in gdb seen with firefox with a random testcase from pulseaudio, which doesn't have the thread libs loaded correctly? unlikely.

Changed in gdb (Ubuntu):
status: Confirmed → New

On Sun, Apr 5, 2009 at 4:36 AM, Matthias Klose <email address hidden> wrote:
> confirming a bug in gdb seen with firefox with a random testcase from
> pulseaudio, which doesn't have the thread libs loaded correctly?
> unlikely.

I omitted to say that gdb, in my case, is crashing in
iterate_over_threads(). Given the fact that it is segfaulting in the
same function, I though it was very likely to be the same problem.

Do you want me to open a new bug with all the apport stuff?

About the thread libraries: mhm, yes, that may a hint to the problem.
Fabien, does it also write to you
warning: Cannot initialize thread debugging library: generic error
when debugging firefox?

Thanks,
Ludovico

Maxim Levitsky (maximlevitsky) wrote :

Same bug have just happened here, also trying to debug pulseaudio.

michiel (bm-hartsuiker) wrote :

I had a problem similar to this when I was trying to debug Firefox on Gentoo, and while searching for a solution I came across this bug report.
Rebuilding glibc and gdb fixed it for me. So I think It's caused by updating the kernel without rebuilding glibc/gdb against the new kernel.

skierpage (skierpage) wrote :

This is happening to me trying to debug x64 Firefox nightly.

With respect to comment #9, I recently updated Kubuntu 9.04 jaunty amd64 to KDE 4.3 using apt-get, which also gave me a new kernel
2009-07-29 03:22 /boot/vmlinuz-2.6.28-15-generic
I don't have a "glibc", but I have glib and libc from April that came with my vmlinuz-2.6.28-11-generic kernel, and a /usr/bin/gdb dated 2008-09-08.

halfdog (halfdog) wrote :

Also happens with sun java 6: gdb --args /usr/bin/java on hardy lts with sun java6 SE

Could it be related to

      if (stop_soon == STOP_QUIETLY || stop_soon == NO_STOP_QUIETLY)
        {
          resume (0, TARGET_SIGNAL_0);

which sounds like true || false, while further down the code the pattern

      stop_soon == STOP_QUIETLY || stop_soon == STOP_QUIETLY_NO_SIGSTOP

is used?

Apart from that: It seems that suse linux gdb is not affected by that, Could it be that it is already fixed in an upstream version? Is source of suse packages available?

Phillip Susi (psusi) wrote :

Are you able to reproduce this on 12.04 or later, and if so, can you provide detailed steps?

Changed in gdb (Ubuntu):
status: New → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for gdb (Ubuntu) because there has been no activity for 60 days.]

Changed in gdb (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers