gdb drops out with 'I/O possible message'

gdb drops out with 'I/O possible message'

[Andrew Walrond]

What might cause gdb to do this?

$ sudo gdb /bin/ruby
GNU gdb 6.3
Copyright 2004 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 "x86_64-unknown-linux-gnu"...Using host 
libthread_db library "/pkg/glibc/lib/libthread_db.so.1".

(gdb) set args
(gdb) set args -- sbin/heretix --cf ruby version=stable --ec
(gdb) run
Starting program: /bin/ruby -- sbin/heretix --cf ruby version=stable --ec
No config directory found for kernel version 2.6.14
Build settings:  cpu=x86_64  build-jobs=5  make-jobs=4
Building symlink database...
Processing......
  +S ruby                 (version='20051027' cpu='x86_64')
    [ruby]

Elapsed time: 0h 2m 3s

I/O possible
sbin/heretix:461: [BUG] Segmentation fault
ruby 1.8.3 (2005-10-26) [x86_64-linux]

andrew@orac main $

Re: gdb drops out with 'I/O possible message'

[Daniel Jacobowitz]

On Fri, Oct 28, 2005 at 11:30:00PM +0100, Andrew Walrond wrote:
> What might cause gdb to do this?

I have no idea.  That message comes from ruby rather than GDB.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: gdb drops out with 'I/O possible message'

[Andrew Walrond]

On Saturday 29 October 2005 00:15, Daniel Jacobowitz wrote:
> On Fri, Oct 28, 2005 at 11:30:00PM +0100, Andrew Walrond wrote:
> > What might cause gdb to do this?
>
> I have no idea.  That message comes from ruby rather than GDB.

No, it doesn't...

$ grep -rF 'I/O possible' gdb-6.3
gdb-6.3/libiberty/strsignal.c:  ENTRY(SIGIO, "SIGIO", "I/O possible"),
gdb-6.3/gdb/proc-events.c:  { SIGIO, "SIGIO", "Socket I/O possible" },  /* 
alias for SIGPOLL */
gdb-6.3/gdb/signals/signals.c:  {"SIGIO", "I/O possible"},
andrew@orac test $

I have seen gdb drop out with this message when debugging c, c++ as well as 
ruby projects, but not frequently. In this particular example, I immediately 
re-ran gdb with the same commands and it worked exactly as expected.

I don't see 'I/O possible' often, but when I do gdb always seems to just exit.

This is running on linux x86_64 64bit linux with recent (-branch) glibc+nptl

Andrew Walrond

Re: gdb drops out with 'I/O possible message'

[Andreas Schwab]

Andrew Walrond <andrew@walrond.org> writes:

> On Saturday 29 October 2005 00:15, Daniel Jacobowitz wrote:
>> On Fri, Oct 28, 2005 at 11:30:00PM +0100, Andrew Walrond wrote:
>> > What might cause gdb to do this?
>>
>> I have no idea.  That message comes from ruby rather than GDB.
>
> No, it doesn't...

Just because gdb contains the string doesn't mean that it has printed it.

> $ grep -rF 'I/O possible' gdb-6.3

Glibc also contains this string:

libc/sysdeps/generic/siglist.h:  init_sig (SIGIO, "IO", N_("I/O possible"))
libc/sysdeps/generic/signame.c:  init_sig (SIGIO, "IO", "I/O possible");
libc/sysdeps/generic/signame.c:  init_sig (SIGPOLL, "POLL", "I/O possible");
libc/sysdeps/unix/siglist.c:    N_("I/O possible"),

> I have seen gdb drop out with this message when debugging c, c++ as well as 
> ruby projects, but not frequently. In this particular example, I immediately 
> re-ran gdb with the same commands and it worked exactly as expected.

Some process (ruby?) is probably enabling async I/O on stdin, which causes
all processes in the same process group to receive SIGIO whenever
something is available to be read on stdin.  Then the process crashes and
has no chance to disable async I/O.  With the next debugging session a new
process group is created, but the SIGIO signals are still sent to the old
(now defunct) process group, effectively dropping them on the floor.

> I don't see 'I/O possible' often, but when I do gdb always seems to just exit.

Try running gdb inside gdb to find out exactly why gdb is exiting.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gdb drops out with 'I/O possible message'

[Andrew Walrond]

On Monday 31 October 2005 09:43, Andreas Schwab wrote:
>
> Some process (ruby?) is probably enabling async I/O on stdin, which causes
> all processes in the same process group to receive SIGIO whenever
> something is available to be read on stdin.  Then the process crashes and
> has no chance to disable async I/O.  With the next debugging session a new
> process group is created, but the SIGIO signals are still sent to the old
> (now defunct) process group, effectively dropping them on the floor.

So is gdb in the same process group as the debug target process? (FWIW the 
process in question forks off several other processes) And will receive the 
same SIGIOs?

It just looks like gdb is catching a SIGIO and exiting...

In other (non ruby) applications where I have seen this problem, I do

	std::ios::sync_with_stdio(false)

which presumably enables async I/O on stdin/stdout etc.

Hmmm

Anyhow; I'll try the gdb inside gdb thing next time I can prodice this 
behaviour with any regularity.

Thanks

Andrew Walrond

Re: gdb drops out with 'I/O possible message'

[Daniel Jacobowitz]

On Mon, Oct 31, 2005 at 10:03:10AM +0000, Andrew Walrond wrote:
> On Monday 31 October 2005 09:43, Andreas Schwab wrote:
> >
> > Some process (ruby?) is probably enabling async I/O on stdin, which causes
> > all processes in the same process group to receive SIGIO whenever
> > something is available to be read on stdin.  Then the process crashes and
> > has no chance to disable async I/O.  With the next debugging session a new
> > process group is created, but the SIGIO signals are still sent to the old
> > (now defunct) process group, effectively dropping them on the floor.
> 
> So is gdb in the same process group as the debug target process? (FWIW the 
> process in question forks off several other processes) And will receive the 
> same SIGIOs?

It should not be; it goes to some effort to always keep the foreground
process group set correctly.

> In other (non ruby) applications where I have seen this problem, I do
> 
> 	std::ios::sync_with_stdio(false)
> 
> which presumably enables async I/O on stdin/stdout etc.

No, that has nothing to do with async I/O; it's just a question of
buffering.

-- 
Daniel Jacobowitz
CodeSourcery, LLC