Qa_*.py

GNU Radio
1

Without exception, on the ps3 under FC5-PPC,

python qa_???.py

generates a segment fault so make check fails of course in
run_tests.sh. There is no other information provided at the segment
fault.

Bob

–
Robert W. McGwier, Ph.D.
Center for Communications Research
805 Bunn Drive
Princeton, NJ 08540
(609)-924-4600
(sig required by employer)

2

IIRC, the PS3 is running on a PowerPC w/ CELL extensions? If so,
then there must be something about “make check” on PPC’s that’s doing
this, since it also happens on OSX for PPC … but not on OSX for
Intel (nor on my other Linux virtual Intel machine running in
Parallels on an Intel-Mac). Unless someone else has a clue, I’ll
start investigating this on my home Mac during the spare cycles while
waiting for GNU Radio to install on a 200 MHz ARM (s … l … o …
w …). - MLD

3

On Mon, Feb 05, 2007 at 02:26:12PM -0500, Robert W McGwier wrote:

Without exception, on the ps3 under FC5-PPC,

python qa_???.py

generates a segment fault so make check fails of course in
run_tests.sh. There is no other information provided at the segment
fault.

Bob

That’s what I saw too. The standalone tests worked OK.

It could be that we’re generating 64-bit .so’s and that python is
compiled as a 32-bit app.

Try

$ file /usr/bin/python

$ file /usr/local/lib/libgnuradio-core.so

If that’s the case, then compiling our stuff in 32-bit mode would be
the next experiment. I think you can get that with

$ CXXFLAGS="-mno-powerpc64" ./configure

Note that CXXFLAGS is in front of ./configure

Any PPC experts out there? Besides the difference in address space,
is there any compelling advantage to using the PPC in 64-bit mode vs
32-bit mode? On the X86-64 it’s a big win to be in 64-bit mode since
you get twice as many registers. I know that this isn’t the case on
the PPC since you’ve always got 32 regs.

Eric

4

AFAIK, going from 32 to 64 bits on a PPC primarily doubles the
address space but otherwise has little significance.

On a PPC Mac, using “file” shows that both python and the gnuradio-
core shared library are MachO types, which doesn’t really help.

Testing the QA code individually, on my PPC Mac I find that in
gnuradio-core/src/python/gnuradio/gr:
work: qa_feval.py & qa_noise.py
don’t: qa_iir.py & qa_head.py

Using “python -v”, it looks like all of the libraries are loaded
correctly no matter working or not. When there is an error, I -
always- get:

pure virtual method called
terminate called without an active exception
Abort

which implies to me that there is “pure virtual” CppUnit inherited
class method that’s not being defined properly. My CppUnit is
version 1.12.0 … maybe there are changes since 1.11 (or 1.10)
causing this? - MLD