I see advice on how to debug a python module that hangs up theprocess

[JD]

This is another Python problem, I think might be unrelated to
the earlier bug I found, and eventually figured out how to
report it to Sourceforge.

This is related to a question I have about Python hanging up
either from a shell, or by importing a module. This I would not
consider a bug, but more on my inexperience with Python.

If my code causes Python to just hang up, and not allowing me
to break out with control-C or control-D, is there a way to
find out what's going on? I don't think it's going into some
infinite loop, because I can usually break out of them with
control-C. What would cause the Python run-time system
to just loose things? The console is dead, but it echo's
carriage returns but that's all it does. The only way I can
release it, is to kill the process.

Is there someone who I might contact
via phone to walk me through this? (Assuming I can't get adequate
information here? Or does anyone care about Python bugs?) This is in
Python 2.3.3c1 on OpenBSD (though I doubt the OS matters). The symptom
is
that I run my program and Python locks up. I cannot control-C or
control-D
to get out of it; I have to log in separately and kill -9 the process.
The
process is listed as "D+" while it is hung, though it doesn't seem to be
accessing the disk, and I'm quite sure there are no disk problems
(though
I'm not physically next to the server, so I can't check the drive LED).

How should I approach debugging this? Are there Python tools? Or should
I
use gdb? ktrace? systrace? I'm assuming I have to do this, as a bug
report
which reads "Python locks up" isn't too useful.

John

 

[Robin Munn]

How should I approach debugging this? Are there Python tools? Or should
I
use gdb? ktrace? systrace? I'm assuming I have to do this, as a bug
report
which reads "Python locks up" isn't too useful.

The first step I'd suggest is to sprinkle print statements all around
your code:

print "About to call some_func()..."
some_func()
print "Returned from calling some_func()..."

Then you can watch the console output (or redirect it to a file for
later perusal) and see when the thing hangs.

 

[JD]

The first step I'd suggest is to sprinkle print statements all around
your code:

print "About to call some_func()..."
some_func()
print "Returned from calling some_func()..."

Then you can watch the console output (or redirect it to a file for
later perusal) and see when the thing hangs.

We already know the function it hangs up at. It's a Python function
we defined.

Obviously, we put a print statement right at the beginning of the
errant
function, but it doesn't appear to be getting there.

IE:

print "before function call"
my_function(some_arguments)
print "after function call"

def my_function(some_arguments):
print "start of function call" <--- this never gets called, or
we don't see the output
<rest of code>

So when this piece of code is called, we get:

before function call
<system hangs up>

Then, we have to do a "kill -9" the process.

John

 

[Paul Rubin]

print "before function call"
my_function(some_arguments)
print "after function call"

What are the arguments? Maybe their evaluation is hanging somehow.

 

[Bengt Richter]

We already know the function it hangs up at. It's a Python function
we defined.

Obviously, we put a print statement right at the beginning of the
errant
function, but it doesn't appear to be getting there.

IE:

print "before function call"
my_function(some_arguments)
print "after function call"

def my_function(some_arguments):
print "start of function call" <--- this never gets called, or
we don't see the output
<rest of code>

So when this piece of code is called, we get:

before function call
<system hangs up>

Then, we have to do a "kill -9" the process.

It would be more interesting if the above was real code instead of prose ;-)

If you know the failing function, and the place where it's being called as above,
what about actually copy/pasting the few lines instead of ad-libbing?

Also, as paul says, what are the arguments? What happens if you change

--
print 'before function call'
my_function(some_arguments)
print 'after function call'
--
to
--
print 'before argument evaluation'
the_arg_tuple = (arg_expr1, arg_expr2, etc.blah) # i.e., whatever "some_arguments" is, in parens
print 'before function call'
my_function(*the_arg_tuple)
print 'after function call'
--

If that hangs during some_expression tuple evaluation, you can do the expressions one at a time, e.g.

the_arg_tuple = (arg_expr1,)
print 'first ok'
the_arg_tuple = the_arg_tuple + (arg_expr2,)
print 'second ok'

etc.

**** But show us a real session copy/pasted, not code-prose, please. ****

You could also run python with -u so you're sure to get all the output flushed immediately,
just in case.

And just after the first before print, you could also use sys.settrace to hook in a debugging
trace that can at least trace non-C python stuff. It might get you closer.

E.g., (quick hack)
... sys.stdout.write('%7s %5s: %10s %r\n' % (
... event,
... frame.f_lineno,
... frame.f_code.co_name,
... frame.f_code.co_filename))
... sys.stdout.flush()
... if event != 'return': return ptrace
... ... return x*2
...
call 1: ? '<stdin>'
call 1: ? '<stdin>'
line 1: ? '<stdin>'
call 1: foo '<stdin>'
line 2: foo '<stdin>'
return 2: foo '<stdin>'
call 1: foo '<stdin>'
line 2: foo '<stdin>'
return 2: foo '<stdin>'
12
return 1: ? '<stdin>'

Maybe it will give more clues.

Regards,
Bengt Richter

 

[Jeff Schwab]

Did you try it without -9?

 

[Bengt Richter]

Bengt Richter wrote:

No I didn't. Please trim more carefully.

Did you try it without -9?

Regards,
Bengt Richter

 

[Jeff Schwab]

No I didn't. Please trim more carefully.

Sorry about that! I hereby print a retraction.

That should have been:

 

[JD]

yes - it wouldn't kill. Only the -9 option would kill it. Like I
posted earlier,
After identifying the function that hangs up (my putting "print"
statements before
and after), we also put a print statement at the beginning of the
function that
hangs up, but it never gets called. So the process of calling the
errant function
is enough to send it to never-never land. How does one debug these
kinds of
problems?

John

 

[Gustavo Campanelli]

I'm still newbie at Python, but not at programing, so this is just a
wild guess. Have you checked that you are not using a reserved word as
function or parameter name?
If the function hangs when it's invoked, are you using some Object as
part of the call? Have you checked that object?

Gedece

 

[Oleg A. Paraschenko]

Hello JD,

How should I approach debugging this? Are there Python tools? Or should
I
use gdb? ktrace? systrace?

I suggest to send process a signal that generates core (ABRT, SEGV or similar)

Then start gdb as usual to debug coredump:

gdb ..path..to..python core

In gdb. use command like "where" to understand what happens.

 

[JD]

I'm still newbie at Python, but not at programing, so this is just a
wild guess. Have you checked that you are not using a reserved word as
function or parameter name?

We are absolutely sure about that. What I think is going on, is
there might be some fluke where there might be
an Intel instruction that might cross a memory segment.

We tried selectively cutting out code in the offending function, to
determine exactly what part of the function
it hangs up at, and we get different results each time. The problem
is not repeatable or predictable, and
this is why we need to have some kind of improved control over the
Python runtime "engine" or mechanism.

I can HACK the function into working, by doing things to change the
length of the code, but this isn't going to
solve the problem or give me the REAL picture of what's going on in the
code. I need a real low level mechanism
that would allow me to run python under control of a low level
debugger, one that would allow me to break out
of the function and determine really where it hangs up.

If the function hangs when it's invoked, are you using some Object as
part of the call? Have you checked that object?

I think it's at a much lower level then this. The exact function HAD
been working in the past, but other modifications
of the code has somehow made it so this function is now hanging up.

I think this is a job for kernal-trace, or gdb (low level debugger),
and this is what I need to now how to do.

John

 

[Paul Rubin]

I think this is a job for kernal-trace, or gdb (low level debugger),
and this is what I need to now how to do.

Running Python under gdb isn't terribly difficult. What's the problem?
Also, if you mentioned whether your program uses threads, I missed it.