Make check seg faults

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 M.

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 M. [email protected] wrote:

Making check in mpif

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 M.


Ketan M.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs