[Discuss-gnuradio] Re: make check seg faults

[Ketan Mandke]

Correction. The "-O" fix that I thought I had only works some of the
time. This is a very peculiar bug.

On Dec 11, 2007 8:24 PM, Ketan Mandke <address@hidden> wrote:
> I recently created an object which spawns an omni_thread and then
> cleans it up when stop() is called. The object that I created works
> fine during normal operation, however when I run make check I get very
> strange behavior. In Ticket #180
> (http://gnuradio.utah.edu/trac/ticket/180), Eric describes the exact
> behavior that I am observing. After every compilation the first
> attempt at make check always fails. Every make check after that
> succeeds.
> ---------------------------------------------------------
> make[3]: Leaving directory `/home/mandke/hydra/gr-hydra/src/python/phy'
> Making check in mpif
> make[3]: Entering directory `/home/mandke/hydra/gr-hydra/src/python/mpif'
> make  check-TESTS
> make[4]: Entering directory `/home/mandke/hydra/gr-hydra/src/python/mpif'
> ./run_tests: line 48: 15196 Segmentation fault      $file
> FAIL: run_tests
> ===================
> 1 of 1 tests failed
> ===================
> make[4]: *** [check-TESTS] Error 1
> make[4]: Leaving directory `/home/mandke/hydra/gr-hydra/src/python/mpif'
> ---------------------------------------------------------
>  I thought this might have something to do with the fact that python
> is doing JIT compilation to byte-code the first time it runs the code,
> so I changed run_tests.in  for this test so that it would run the
> qa_*.py file with the "-O" option (to optimize the python code). This
> seems to work. I have no idea why, but I have been stressing over this
> problem for a few days now.
>
> Does anyone have any insight into this  problem? or any more
> information about Ticket #180?
>
> All of my problems with omni_threads seem to occur during the cleanup
> phase of their execution (i.e. when they should be getting destroyed).
> From my experience so far, it seems that python tries to exit before
> the omni_threads have had a chance to be completely freed up. In
> general, I could really use some guidelines (do's and especially
> don'ts) for creating classes that inherit from omni_thread.
>
> --
> Ketan Mandke
>



-- 
Ketan Mandke