"Lost Process" Bug in GDB (UnixWare V5.0)

[Marvin Taylor]

I've seen this twice in recent weeks/months.... I don't recall details of 
the first time.

SCENARIO:
---------
   After my PUT (program under test) has a problem (fatal SIGSEGV), I wish 
to kill/restart it, but it appears to have "lost" the process, and refuses 
to continue in any fashion (I finally used SIGQUIT to terminate the 
debugger itself).

BACKGROUND:
-----------
I doubt most of this relates to the problem, but thought I'd try to be 
thorough:

 - PUT is multi-threaded, some are permanent, some transient (PThread 
library).
 - PUT uses socket I/O as well as some telephony hardware (not that it 
matters).
 - Access is via 'rlogin' session.
 - Process has EUID of 0 (root) when running.

 - GDB 5.0 was downloaded from the SCO site.
 - Program is compiled with GCC V2.95.2 (also from SCO site).
 - I've debugged the program in GDB countless times, where I kill/restart it
   with no problems.

 - This is an Avaya (was part of Lucent) Conversant System V8.0, MAP40.
 - Running on a single CPU (Pentium III 500Mhz) in run-level 4 (multi-user 
w/lots
   of other processes running).
 - Running under UnixWare 7.1.1

To my knowledge nothing else directly affected the PUT -- it's before 7am 
and I'm pretty sure
no one is in yet (only a few use this particular machine anyway).

I've copied the screen output below.

SUMMARY:
--------
As a user, the fact that it "lost" the process is only mildly 
annoying.  The fact that
it refuses to continue in any fashion is much more so.

FEEDBACK:
---------
I don't expect any feedback on this problem.  It happens rarely, but since 
it seems to be a legitimate bug, I thought I'd send it in.   I'm not sure 
how much else I can add to what's here, but if necessary, I will try.

Oh, and thanks for GDB; I've used it for years now, on nearly a half-dozen 
platforms.  The debugger shipped with UnixWare sucks miserably in 
comparison -- but then most do!

SCREEN CAPTURE:
---------------
After running 'c'ontinue several times, hitting the same breakpoint.  Note 
that 'mesg' is an enum with ~40 valid values, so the PUT is already hosed 
at this point.  I aborted the 'r'un because I then decided to 'k'ill first 
and reset the program's output log file.

                ======================

(gdb) c
Continuing.

Breakpoint 5, ChanSock::notify (this=0x812a208, mesg=858076213, p1=0x66322561,
    p2=0x63696f76, p3=0x32253165, p4=0x73667666) at ChanSock.cc:354
354             sendString( msg );
(gdb) n
355     }
(gdb) n
warning: Cannot insert breakpoint 0:
Cannot access memory at address 0x32663225
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) n
Program not restarted.
(gdb) k
Kill the program being debugged? (y or n) y
procfs: couldn't find pid 6626 in procinfo list.
(gdb) info break
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x08051f3e in handler(int) at ChTest2.cc:204
2   breakpoint     keep y   0xbffa0ba0  <exit>
5   breakpoint     keep y   0x0806688a in ChanSock::notify(MessageID, SNVal 
*, SNVal *, SNVal *, SNVal *) at ChanSock.cc:354
        breakpoint already hit 8 times
(gdb) help cont
Continue program being debugged, after signal or breakpoint.
If proceeding from breakpoint, a number N may be used as an argument,
which means to set the ignore count of that breakpoint to N - 1 (so that
the breakpoint won't break until the Nth time it is reached).
(gdb) bt
#0  0x73656c69 in ?? ()
procfs: couldn't find pid 6626 in procinfo list.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
procfs: couldn't find pid 6626 in procinfo list.
(gdb) r *.cfg
The program being debugged has been started already.
Start it from the beginning? (y or n) y
procfs: couldn't find pid 6626 in procinfo list.
(gdb) k
Kill the program being debugged? (y or n) y
procfs: couldn't find pid 6626 in procinfo list.
(gdb) q
The program is running.  Exit anyway? (y or n) n
Not confirmed.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
procfs: couldn't find pid 6626 in procinfo list.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
procfs: couldn't find pid 6626 in procinfo list.
(gdb) help procfs
Undefined command: "procfs".  Try "help".
(gdb) quit
The program is running.  Exit anyway? (y or n) y
procfs: couldn't find pid 6626 in procinfo list.
(gdb) Quit
(gdb) + kill 5307
Killed
cvis8-3(marvint)% gdb --version
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-sco-sysv5uw7.0.1".