On Wed, Apr 16, 2014 at 6:21 PM, Kiran Karra <[email protected]> wrote: >>> Any chance you can share the code? > > > I will try to get some approval here to release, however it may be a bit of > time before I am allowed to do that unfortunately. > > >>> Try and remove the .xml-file output from the test and run again. Maybe > > it's a problem of persistence? > > I tried this just now, still seg faulting but thanks for the suggestion. > > Any ideas as to why I can't see a stacktrace in GDB even though I rebuilt > the code with debug symbols? That seems strange to me. Tim suggested that > perhaps this is due to ctest swallowing the segfault as a fail in the test > ... and I think that is actually what is happening, because I see ctest move > onto the next test. I looked at ctest help but didn't find a way for it to > not swallow the segfaults... does anybody have any ideas here? > > Thanks again, > Kiran
Sounds plausible. Ctest is actually just running a shell script. You can try running that script through gdb. The name of the script will be printed near the top of ctest -V. Alternatively you should be able to find it in $build/modname/python/namespace/qa_whatever_your_test_is_called.sh; an example for gr-digital: build/gr-digital/python/digital/qa_mpsk_snr_est_test.sh Nathan _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
