Re: make test passes, but Linux kernel log says "undefined instruction"

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.

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.

On Tue, Jul 2, 2013 at 3:59 PM, Monahan-Mitchell, Tim
[email protected] 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