bug-gdb
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gdb gets generic 8192 error every time. Debugging impossible.


From: I'm address@hidden
Subject: gdb gets generic 8192 error every time. Debugging impossible.
Date: Wed, 31 Mar 2004 14:16:33 -0800 (PST)

I'm just not sure where to send this to. I tried posting to 
address@hidden, but got a message bounced back that general
postings are not allowed. Can anyone on this list help, please?

Thanks,
-- Aditya.

Forwarded message:
>From address@hidden Thu Mar 25 23:52:50 2004
Subject: gdb craps out *every* time w/8192 generic error. 
To: address@hidden
Date: Thu, 25 Mar 2004 23:52:49 -0800 (PST)
Cc: address@hidden (Aditya Gurajada)

Hi folks,

I just recently joined this listserver, in the hope of getting some
advise/solutions to the following problem we are experiencing at work,
when using gdb [5.3, or 6.0] on RH Adavanced Server Linux (2.1AS).

(I don't even know if this is the right list to post to, so please excuse
 me if this is the wrong address, and re-direct me to the right group.)

Short summary: When the debugged process (in this case Sybase's RDBMS
server product) completes (i.e. in our parlance 'shuts down'), the gdb
debugger gets what appears like an internal error. No further work can
be done in that gdb session, and we have to re-start gdb, thereby losing
all breakpoints, and other context setup.

This problem is extremely frustrating, and any help will be most
appreciated. Here is a sample output to show exactly the output we get
from gdb. (The versions of gdb tested is at the end of this mail.)

---
(gdb) server_nightly_linuxdbaccess2
Error: sproject was already run once
[New Thread 8192 (LWP 19390)]
00:00000:00000:2004/03/25 09:56:31.31 kernel  Use license file 
/remote/mallory_pub1/main/release/SYSAM-1_0/licenses/license.dat.
---

[ ... ok that is not the problem. ...]

Then when we shutdown the server, either via isql 'shutdown' or even
'shutdown with nowait', the debugger returns a message like:

---
00:00000:00011:2004/03/25 10:04:36.24 server  SQL Server shutdown by request. 
00:00000:00011:2004/03/25 10:04:36.24 kernel  ueshutdown: exiting

Program received signal SIGCHLD, Child status changed.
Cannot find user-level thread for LWP 19390: generic error
---

Here is the problem:

        Cannot find user-level thread for LWP 19390: generic error

Once we get this message, that session of gdb is completely useless.
Nothing works. We have to quit gdb, and restart, which means losing
all your breakpoints etc. If you try to do anything else, we get:

---
(gdb) cont
Cannot find thread 8192: generic error
---

Interestingly, it's always 'Cannot find thread 8192'. The things I observed
is that the LWP # in the generic error at the end is the same as the LWP
that was reported on startup.

I imagine this is an issue with some signal handling (child process etc.)
but cannot figure out what else to do for signal settings other than the
following in my $HOME/.gdbinit:

---
handle all print
handle all pass
handle all nostop

handle SIGFPE stop
handle SIGKILL stop
handle SIGBUS stop
handle SIGSEGV stop
handle SIGALRM nopass
handle SIGALRM noprint

set unwindonsignal on
---

I even tried to 'handle' SIGUSR2 with [stop|nopass], but even that did
not improve this situation.

I searched through the gdb bugs db off of the gdb home page, but could
not find any reference to this issue. Searching on google for these tag
words comes up empty.

I've experienced these problem behaviour using the following tools:

[ 96 ] ll /usr/bin/ddd
-rwxr-xr-x    1 root     root      3301880 Jul 19  2001 /usr/bin/ddd*

[ 98 ] ddd -v
GNU DDD 3.3.1 (i386-redhat-linux-gnu)

[ 93 ] ll /usr/bin/gdb
-rwxr-xr-x    1 root     root      2479863 Jan  2 14:11 /usr/bin/gdb*
[ ptnqp_aditya_vu 94 ] /usr/bin/gdb -v
GNU gdb Red Hat Linux (5.3.90-0.20030710.41.2.1rh)

[ 95 ] ll /usr/local/bin/gdb
-rwxr-xr-x    1 root     root      6463046 Mar  1 13:41 /usr/local/bin/gdb*
[ ptnqp_aditya_vu 99 ] /usr/local/bin/gdb -v
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.

Thans, in advance,
-- Aditya.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]