This appears to be specific to RH 6.2, as I was able to take the
perl-5.00503-10 RPM from RH 6.2 and apply it to an RH 6.1 system and the
bug does not show up. On RH 6.2, opening a pipe to a command is not
functioning correctly such that orders are not sent to the command and the
handle is not in blocking mode. For example
open(DEBUG_HANDLE, "|gdb $name $PID");
print DEBUG_HANDLE "where\n";
print DEBUG_HANDLE "detach\n";
print DEBUG_HANDLE "quit\n";
<more script stuff>
the code attaching to gdb will no longer work in a perl script, and results
in the debugger hanging attached to the process because it has recieved
none of the commands while perl reports an error on stdin and continues
executing any further perl commands.
If more information is needed, I can provide it. This issue has shown up
on a customer site and I've been able to duplicate it on a base RH 6.2
Does this still show up when using another tool to feed commands to gdb?
Tested standalone gdb with the command "tail -f foo | gdb /bin/ls" and echoing commands into foo showed up and were executed by gdb - so it still
appears to be something wrong in perl specifically.
Then I suspect this is gdb's behavior rather than perl's. On a Raw Hide
system with gdb 5.0, this no longer occurs.
Does it show up on a 6.2 system with 6.1 gdb?
Works with the pinstripe beta.
Can you tell me what the "pinstripe" beta/RAWHIDE is/are and what the planned availability is? At present, we're writing a Release Note for Lotus
Domino Release 5.05 which will state that our debug tool "nsd" is unable to run on RH 6.2 due to a bug in perl/gdb on RH6.2 - it'd be nice to also put
something in stating a workaround to allow this to work - "nsd" is our primary tool for capturing debug information in the field on problems/crashes with
the Lotus Domino product. Thanks! kenbo
RawHide is a recent cut from out build trees (available from our ftp site and
some mirrors), pinstripe is a beta of the upcoming 7.0.
Do you have a sample script which demonstrates your behaviour?
And did you try the gdb and/or perl from 6.1 on the 6.2 system?
I just duplicated the bug on my RH 6.1 machine for the first time by upgrading gdb to the gdb shipping with RH 6.2 - so it looks like you are right and it is
a gdb issue. I will download the latest gdb from your site and see if it still happens or if it is gone. Thanks. kenbo
I cannot install the rawhide verion of gdb as it's major number is > 3 and rpm will not handle it; niether can I upgrade rpm to new version with rawhide for
the same reason. In order to verify that the gdb from rawhide fixes the issue, I need to be able to install this gdb on a RH 6.1 or RH 6.2 machine - is this
possible then? Thanks. kenbo
Tried rpm 3.0.5 from ftp.rpm.org? (which will be an update RSN - possibly today
Ok, I installed rpm 3.0.5.x from ftp.rpm.org and it allows me to install the > 3 packages. However, gdb-5.05 requires libncurses.so.5 and libc.so.6 - both
of which basically require me to upgrade my OS to rawhide, which is not acceptable as a "fix" to running Domino/Notes on RH6.2. Any other ideas? If
not, we're gonna have to just go with the release note that says that nsd does not work on RH6.2 due to a bug in gdb. Thanks! kenbo
Try rebuilding the SRPM... we are thinking of doing an errata of this. If you
could confirm that it is actually working, that would be one more reason for
Rebuilt the gdb-5.0 and it is better, but still not fully working. Now it does not remain attached to the processes, but it is still failing to gain commands.
Here is a sample output of a run conclusion:
Reading symbols ...
Loaded symbols ...
0x40xxxxx in __select () from ...
(gdb) Hangup deteced on fd 0
error detected on stdin
Detaching from program: /opt/lotus/notes/latest/linux/server, Thread x
Since there is no place on here for attachments, I will send you email with a modified version of nsd.pl, called nsd_test.pl
which you can use to duplicate the bug by running it with a find command running in the background - I've put some
directions in the top of the file on how to run it and how to modify the script to do more. Hopefully this will help in
finding a cure. Thanks! kenbo
Sorry, this ain't a bug in GDB.
The fact that xxgdb, ddd, etc, works fine tells me it's a problem in perl if
anywhere, but more to the point, the way you are going about this is wrong.
If you want a tty to communicate with gdb, create a tty and do gdb
Don't try to play games with stdin.
If you need something more complex, look at the new MI interface.
OK - bug in usage according to one of the GDB develpers (don't use GDB though a