discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] top block segfaults


From: Johnathan Corgan
Subject: Re: [Discuss-gnuradio] top block segfaults
Date: Thu, 17 Jan 2008 11:35:55 -0800
User-agent: Thunderbird 2.0.0.6 (X11/20071022)

beezle bub wrote:

> For some reason the top block code is causing a segfault for me, and
> I don't know why.  Is there anything in top block that could cause
> this?  Or, is it more likely likely a problem with my own python
> code?

We currently have an open bug in the trunk and stable branches:

http://gnuradio.org/trac/ticket/181

This, on the systems that exhibit it, will turn (some) exceptions thrown
in swig wrapped C++ into aborts, even when the code is there to catch
the exception and handle it gracefully.

Since the new flow graph code in 3.1 is all done in C++ (in anticipation
of allowing pure C++ GNU Radio applications in 3.2), if there is a
misconfigured flowgraph in the user's Python code, the C++ runtime will
throw an exception and the handler will report it with a helpful
message.  But, because of ticket:181, it simply becomes a segfault instead.

That's probably what you're seeing here.

To track down the original problem, execute Python and your script
entirely from gdb.  When you get the abort, do an 'info threads' and
'thread apply all bt'.

On the faulting thread, a couple of stack frames from the top, will be
the GNU Radio code that threw the exception.  Switch to that frame and
list the code, you'll see the conditional test and the proper error message.

In your case, the function running was tb.run(), which invokes numerous
checks on the flow graph topology before handing it to the scheduler, so
one of these checks is probably failing.

Ticket:181 is our highest priority bug at this point, and after many
hours of tracing through swig generated code and x86 assembly, we think
it is either a swig bug or (less likely) a gcc bug.  The conditions (gcc
version, swig version, 64-bit vs. 32-bit, Python version, specific
exception) that trigger it are not consistent either, but when it does
happen, it happens reliably.

Eric and I have spent many hours trying to tackle this one--any help is
appreciated.

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]