CODEWITHSUNDEEP
gdbcentos7
Piotr Barejko
Piotr Barejko

Reputation: 648

CentOS: gdb hangs on __read_nocancel call

I am attaching with gdb to an executable that has been compiled with debug flags. gdb hangs on __read_nocancel call. If I run executable without attaching gdb then everything is fine and application exits normally with expected result.

I have done a bit of googling but I can't find anything concrete. Can anyone suggest any solution or workaround? Is this is a known problem?

Edit:

It turns out that library that I use forks and uses Python in the background. After I switch to inferior 1 and continue then program hangs.

Reading symbols from /usr/bin/python2.7...
[Attaching after process 13040 fork to child process 13041]
[New inferior 3 (process 13041)]
process 13041 is executing new program: /usr/bin/uname
[Inferior 3 (process 13041) exited normally]
(gdb) inferior 1
[Switching to inferior 1 [process 12455] (/usr/bin/python2.7)]
[Switching to thread 1.1 (Thread 0x7fec1cee5740 (LWP 12455))]
#0  0x00007fec1bc8cf42 in fork () from /lib64/libc.so.6
(gdb) c
Continuing.
^C
Thread 1.1 "python" received signal SIGINT, Interrupt.
0x00007fec1bcb6f70 in __read_nocancel () from /lib64/libc.so.6
(gdb) where
#0  0x00007ffff6db2f70 in __read_nocancel () from /lib64/libc.so.6
#1  0x00007ffff6d3fb14 in __GI__IO_file_underflow () from /lib64/libc.so.6
#2  0x00007ffff6d41063 in _IO_default_xsgetn () from /lib64/libc.so.6
#3  0x00007ffff6d32fdf in fread () from /lib64/libc.so.6
#4  0x00007ffff7a364ca in file_read (f=0x7fffeac4f8a0, args=<optimized out>) at Objects/fileobject.c:1084
#5  0x00007ffff7ac6345 in call_function (oparg=<optimized out>, pp_stack=0x7ffffffef5e0) at Python/ceval.c:4352

[Attaching after process 18291 fork to child process 18293]
[New inferior 3 (process 18293)]
process 18293 is executing new program: /usr/bin/uname
[Inferior 3 (process 18293) exited normally]
(gdb) info inferiors 
  Num  Description       Executable        
  1    process 18271     /opt/cpp_stuff/tests/test
  2    process 18291     /usr/bin/bash     
* 3    <null>            /usr/bin/uname    
(gdb)

Upvotes: 1

Views: 1370

Answers (1)

Employed Russian
Employed Russian

Reputation: 213799

gdb hangs on __read_nocancel call. If I run executable without attaching gdb then everything is fine and application exits normally with expected result.

No: GDB is not hanging.

Your application (python) is blocked trying to read from some FILE. The input python is expecting never comes, so it waits forever.

You haven't provided enough info for us to know what the first inferior is trying to read from, and why that input never comes.

Mark Plotnick's guess that you have another inferior (2?) which is stopped and is supposed to produce the output for which inferior 1 is waiting is likely to be correct. If so, you need to resume that other inferior.

Upvotes: 2

Related Questions