discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] ctest -V segfault, coredump reveals nothing


From: kkarranc
Subject: [Discuss-gnuradio] ctest -V segfault, coredump reveals nothing
Date: Wed, 16 Apr 2014 13:27:34 -0700 (PDT)

Hi All,
I have a gnuradio block which I am testing through a C++ QA function.  I
call the handler function directly in C++ QA test function, and everything
runs.

My test function is structured as follows:
  - I create a pointer to the object I want to create by using the make
function, which returns a boost::shared_ptr to the object.  
  - I then do obj-->handler() to run all the tests and they pass fine (The
reason this is a handler and not a standard work() function is because this
block is based on gr-eventstream and it is a subclass of the es_trigger
block).  
  - At the end, I can see that the destructor to my object is being called
and that completes nicely.  However, after desctruction of my object, I get
a segfault from ctest (I am running the test through ctest -V to see what is
going on instead of make test).

I suspect what is going on is something w/ the boost::shared_ptr but I don't
know what exactly.  

I created a core dump through the usual methods and I can't get it to output
anything useful to help me debug the problem.  Here is the output of "i
stack"

Core was generated by `test-wifi_detector'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000000031 in ?? ()
(gdb) i stack
#0  0x0000000000000031 in ?? ()
#1  0x00007f6a7b3ae11e in ?? ()
#2  0x00007fff8cea6d10 in ?? ()
#3  0x0000000002261ab0 in ?? ()
#4  0x00007fff8cea6cf0 in ?? ()
#5  0x00007f6a7b3b178e in ?? ()
#6  0x00007fff8cea7540 in ?? ()
#7  0x00000000022612b0 in ?? ()
#8  0x00007fff8cea6d10 in ?? ()
#9  0x00007f6a7b3a1072 in ?? ()
#10 0x0000000100000000 in ?? ()
#11 0x00000000022612b0 in ?? ()
#12 0x00007fff8cea6d30 in ?? ()
#13 0x00007f6a7b3a1101 in ?? ()
#14 0x00007fff8cea6d40 in ?? ()
#15 0x000000000226ffa0 in ?? ()
#16 0x00007fff8cea6d50 in ?? ()
#17 0x00007f6a7b3aa090 in ?? ()
#18 0x00007fff8cea7120 in ?? ()
#19 0x000000000226ff98 in ?? ()
#20 0x00007fff8cea6d70 in ?? ()
#21 0x00007f6a7b3ace28 in ?? ()
#22 0x000000000224ba88 in ?? ()
#23 0x000000000226ff90 in ?? ()
#24 0x00007fff8cea6d90 in ?? ()
#25 0x00007f6a7b3afc9a in ?? ()
#26 0x000000000226ff90 in ?? ()
#27 0x00007fff8cea6dbf in ?? ()
#28 0x00007fff8cea6dd0 in ?? ()
#29 0x00007f6a7b3aea96 in ?? ()
#30 0x000000000226ff70 in ?? ()
#31 0x000000000224ba88 in ?? ()
#32 0x0000000000000000 in ?? ()

I tried rebuilding with the debug flags enabled during compile by doing
this:  cmake -DCMAKE_BUILD_TYPE=Debug ../  && make clean && make && make
install && ctest -V  but I still get question marks.  As for the executable
I am passing into gdb, I tried: "test-wifi_detector   /bin/bash  and  
ctest)

Does anybody have any ideas as to how I can proceed to figure out what is
going on?  I am pretty convinced that the block itself is not segfaulting
because the destructor gets called and that gets cleaned up.  Another reason
why I think the block is OK is because when I run it in a grc flowgraph, it
works fine ... its just in test mode that this happens.  Another reason why
I think this is something with boost::shared_ptr is, in my unittest function
in C++, if i call sptr.reset(), it segfaults right there (I've verified the
only way I know how, which is with print statements before and after).

Thanks,
Kiran



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/ctest-V-segfault-coredump-reveals-nothing-tp47635.html
Sent from the GnuRadio mailing list archive at Nabble.com.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]