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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
