# Re: make test passes, but Linux kernel log says "undefined instruction" **URL:** \ **Category:** GNU Radio\ **Created:** [June 29, 2013, 12:40am UTC](https://www.ruby-forum.com/t/re-make-test-passes-but-linux-kernel-log-says-undefined-instruction/245673 "2013-06-29T00:40:07Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Sadaf\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/858c86/32.png) [@Sadaf\_N](https://www.ruby-forum.com/u/Sadaf_N)\ **Post date:** [June 29, 2013, 12:40am UTC](https://www.ruby-forum.com/t/re-make-test-passes-but-linux-kernel-log-says-undefined-instruction/245673/1 "2013-06-29T00:40:07Z")
> Gnu Radio v3.6.4.2 on ARM target. > make test : 100% pass. > But this happens each time python does “from gnuradio import gr\_unittest”: > \<6\>[390.919792] python (1771): undefined instruction: pc=42a9c328 \<6\>[ > 390.919822] Code: 00000000 00000000 f26ee1fe e12fff1e (ee190f1d) > For example, when qa\_add\_and\_friends is started. > This just showed up when switched from Ubuntu 12.04 LTS to 13.04, and installed > new versions of g++, libboost, etc… I went back and checked my older 12.04 > environment which does not exhibit this. My cmake configuration was the same > (except I took out -DENABLE\_BAD\_BOOST, as I now have Boost 1.53). > Some version changes: > g++ : 4.6.3-1ubuntu5 to 4.7.3-1ubuntu1 > python: 2.7.3 to 2.7.4 > swig: 2.0.4 to 2.0.8 > If I had not looked at the kernel log, I would not have noticed. > I’ll see if I can narrow this down. But any experience appreciated. An update on this. I see the above log several times during a fresh build of gnuradio, during “cmake …/”, and it starts right around this point in the cmake output: ## – Looking for C++ include sys/resource.h - found – Python checking for python \>= 2.5 – Python checking for python \>= 2.5 - found So at least this eliminates the collection of compiler flags I have on the cmake command line I actually am using. ---
**Author:** ![Monahan-MitchellS\_T](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/8edcca/32.png) [@Monahan-MitchellS\_T](https://www.ruby-forum.com/u/Monahan-MitchellS_T)\ **Post date:** [July 2, 2013, 10:04pm UTC](https://www.ruby-forum.com/t/re-make-test-passes-but-linux-kernel-log-says-undefined-instruction/245673/2 "2013-07-02T22:04:32Z")
> But this happens each time python does “from gnuradio import gr\_unittest”: > \<6\>[390.919792] python (1771): undefined instruction: pc=42a9c328 \<6\>[ > 390.919822] Code: 00000000 00000000 f26ee1fe e12fff1e (ee190f1d) A “final” update, just to close my own thread. Case 1: It happens during “cmake ../” for gnuradio. It’s caused because python imports “hashlib”, which in turn imports “\_hashlib”. Manually enter python and “import \_hashlib” triggers the kernel log above. Case 2: The situation above (“from gnuradio import gr\_unittest”) boils down to an import of \_ssl. Same thing, a manual import of \_ssl in python triggers the same. Using sys.modules.values() in python to see the libraries loaded for each case, and then ldd to see the dependent libraries, there are 7 in common between \_hashlib and \_ssl. The one I most suspect is libcrypto.so (/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0), which is the only one of the 7 that didn’t come from the Ubuntu Core I am using (ubuntu-core-13.04-core-armhf). I believe it was installed as a dependency of installing git (which installed libssl.so.1.0.0). My conclusion: maybe this is something to report to Ubuntu Core maintainers. ---
**Author:** ![Monahan-MitchellS\_T](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/8edcca/32.png) [@Monahan-MitchellS\_T](https://www.ruby-forum.com/u/Monahan-MitchellS_T)\ **Post date:** [July 2, 2013, 11:52pm UTC](https://www.ruby-forum.com/t/re-make-test-passes-but-linux-kernel-log-says-undefined-instruction/245673/3 "2013-07-02T23:52:36Z")
On Tue, Jul 2, 2013 at 3:59 PM, Monahan-Mitchell, Tim [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > My conclusion: maybe this is something to report to Ubuntu Core maintainers. Tim, That’s good news. Thanks for following up on it. This definitely doesn’t seem like it’s an issue with GNU Radio at this point. Tom