On Thu, Dec 8, 2011 at 21:47, Matt Mills <mmi...@2bn.net> wrote: > > Also, Here's the python I've been using to reproduce: > http://pastebin.com/at0FdzXp > and the GDB backtrace after its locked up: http://pastebin.com/vx9cgSzp >
The unlock() code, when the number of calls to unlock() reaches the same as the number of calls to lock(), initiates the process of reconfiguring the running flowgraph with the modified topology created by calls to connect() and disconnect() in the interim. At a certain point, it stops the running flowgraph. This is shown in stack frame #7 in your backtrace. To stop the graph, it interrupts all the threads in the thread group for the flowgraph (each block work() function runs in its own thread), showin in stack frame #5. Stack frames #4-#0 show the Boost library interrupting one of the threads, which ultimately results in a kernel syscall that never returns. It's possible that whatever thread is being interrupted is somewhere in an uninterruptible state, though I'm not sure what that could be. If you could do an "info threads" in gdb, that might shed some light. Johnathan Corgan
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
