Here’s a sample with:
Gnu Radio 3.1.1
g++ 4.0.1
Python 2.4.4
Swig 1.3.33
OSX 10.4.11
[eds-mac:~] edwardc% python
Python 2.4.4 (#1, Dec 19 2007, 10:55:40)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.
from gnuradio import gr
gr.firdes.hilbert(0)
Traceback (most recent call last):
File “”, line 1, in ?
File
“/usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_py_general.py”,
line 2837, in hilbert
return _gnuradio_swig_py_general.firdes_hilbert(*args)
IndexError: Hilbert: Must have odd number of taps
^D
[eds-mac:~] edwardc% g++ --version
i686-apple-darwin8-g+±4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
5363)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
[eds-mac:~] edwardc% swig -version
SWIG Version 1.3.31
Compiled with /usr/bin/g+±4.0 [i686-apple-darwin8.8.2]
Please see http://www.swig.org for reporting bugs and further
information
[eds-mac:~] edwardc% uname -a
Darwin eds-mac.gsfc.nasa.gov 8.11.1 Darwin Kernel Version 8.11.1: Wed
Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386
past@culmus:~$ python
Python 2.4.4 (#2, Apr 5 2007, 20:11:18)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
from gnuradio import gr
gr.firdes.hilbert(0)
terminate called after throwing an instance of ‘std::out_of_range’
what(): Hilbert: Must have odd number of taps
Aborted
past@culmus:~$ g++ --version
g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
past@culmus:~$ swig -version
SWIG Version 1.3.33
Compiled with g++ [i686-pc-linux-gnu]
Please see http://www.swig.org for reporting bugs and further
information
past@culmus:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : Pentium III (Katmai)
stepping : 2
cpu MHz : 451.025
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr sse up
bogomips : 902.97
Patrick
Engineers motto: cheap, good, fast: choose any two
Patrick S.
Student of Telematik, Techn. University Graz, Austria
Thanks everyone for testing and reporting your results. We have a
workaround checked into the GNU Radio trunk that so far seems to be
holding without any side effects.
What we need now is to know if there are configurations for which this
workaround is not effective. So, if you’d like, please upgrade to the
latest trunk version and retry your tests.
Please only post to the list if the problem continues even after using
trunk revision >= 7461; we’re looking for exceptions at this point.
Python 2.4.4 (#1, Nov 1 2007, 23:42:22)
[GCC 4.1.2 (Gentoo 4.1.2)] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
from gnuradio import gr
gr.firdes.hilbert(0)
terminate called after throwing an instance of ‘std::out_of_range’
what(): Hilbert: Must have odd number of taps
Aborted
$ g++ --version
g++ (GCC) 4.1.2 (Gentoo 4.1.2)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
$ swig -version
SWIG Version 1.3.31
Compiled with x86_64-pc-linux-gnu-g++ [x86_64-pc-linux-gnu]
Please see http://www.swig.org for reporting bugs and further
information
$ svn info
Path: .
URL: http://gnuradio.org/svn/gnuradio/branches/releases/3.1
Repository Root: http://gnuradio.org/svn
Repository UUID: 221aa14e-8319-0410-a670-987f0aec2ac5
Revision: 7023
Node Kind: directory
Schedule: normal
Last Changed Author: jcorgan
Last Changed Rev: 6822
Last Changed Date: 2007-11-05 17:02:31 -0800 (Mon, 05 Nov 2007)
$ uname -a
Linux localhost 2.6.22-gentoo-r9 #1 SMP Sun Nov 25 22:16:51 PST 2007
x86_64 Intel(R) Core™2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux
Please only post to the list if the problem continues even after using
trunk revision >= 7461; we’re looking for exceptions at this point.
As with r7554, GNU Radio still have the swig problem with top_block().
The
flow_graph does not have this problem. I’m using Ubuntu 7.10, on P4
system.
Here is my tests :
====================================================
firas@ubuntu:~$ python
Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
from gnuradio import gr
tb = gr.top_block()
tb.start ()
tb.stop ()
tb.start ()
terminate called after throwing an instance of ‘std::runtime_error’
what(): already running
Aborted
firas@ubuntu:~$ python
Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
from gnuradio import gr
fg = gr.flow_graph ()
fg.start ()
fg.stop ()
fg.start ()
fg.stop ()
=================================================
My system information is :
firas@ubuntu:~$ g++ --version
g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
firas@ubuntu:~$ python -V
Python 2.5.1
firas@ubuntu:~$ swig -version
SWIG Version 1.3.31
Compiled with g++ [i686-pc-linux-gnu]
Please see http://www.swig.org for reporting bugs and further
information
firas@ubuntu:~$ uname -a
Linux ubuntu 2.6.17-12-server #2 SMP Tue Dec 18 02:13:45 UTC 2007 i686
GNU/Linux
firas@ubuntu:~/newgnuradio$ svn info
Path: .
URL: http://gnuradio.org/svn/gnuradio/trunk
Repository Root: http://gnuradio.org/svn
Repository UUID: 221aa14e-8319-0410-a670-987f0aec2ac5
Revision: 7554
Node Kind: directory
Schedule: normal
Last Changed Author: jcorgan
Last Changed Rev: 7536
Last Changed Date: 2008-02-01 11:48:00 -0500 (Fri, 01 Feb 2008)
Yes. The GNU Radio is working. Only when I run the sequence tb.start() ,
tb.stop() then tb.start() in the running python code, I get this problem
[I cannot run tb.start() two times].
This actually sounds like a new, different issue; I’ll look at this
today.
Yes. The GNU Radio is working. Only when I run the sequence tb.start() ,
tb.stop() then tb.start() in the running python code, I get this problem
[I cannot run tb.start() two times].
Regards,
Firas
On Mon, Feb 04, 2008 at 11:47:57PM -0800, Firas A. wrote:
Yes. The GNU Radio is working. Only when I run the sequence tb.start() ,
tb.stop() then tb.start() in the running python code, I get this problem
[I cannot run tb.start() two times].
This actually sounds like a new, different issue; I’ll look at this today.
This issue has been fixed in r7565 on the trunk, however there is a
clarification needed. The specific issue, an abort instead of a
Python exception, was because the SWIG compiler was not told that the
underlying C++ code could throw an exception, so it wasn’t being
handled correctly.
However, it is correct behavior to throw an exception in the above
scenario.
The semantics of running a GNU Radio gr.top_block have give the user
two different options:
Use gr.top_block.run(). This will cause the flowgraph to be run in
a separate thread (possibly multiple threads), and block the mainline
thread until either the flowgraph ends on its own, or an exception
occurs (like a CTRL-C generated SIGINT.). Everything is handled
automatically for the user. Most of our non-GUI example applications
use this option.
Use gr.top_block.start(). This will cause the flowgraph to be
started in a separate thread (possibly multiple threads), then control
immediately returns to mainline thread context. This allows the
application to do other things in parallel with the flowgraph. All
the GUI-based examples use this (the flowgraph management is actually
handled for the user in gr-wxgui.)
In the case of #2, at some point the flowgraph must be stopped. The
application first calls stop(). This signals all the flowgraph
threads to exit their next opportune moment. Then the application
calls wait(), to allow all the threads to actually do so. At this
point the flow graph can be restarted (if needed) by calling start().
The exception in the original problem report was caused by not calling
wait in between. Note that this is different behavior from the old,
Python-based flowgraph code*.
With the current trunk now:
$ python
Python 2.5.1 (r251:54863, Oct 5 2007, 13:50:07)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
from gnuradio import gr
tb = gr.top_block()
tb.start()
tb.stop()
tb.start()
Traceback (most recent call last):
File “”, line 1, in
File
“/usr/local/lib/python2.5/site-packages/gnuradio/gr/top_block.py”,
line 45, in start
self._tb.start()
File
“/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py”,
line 1461, in start
return _gnuradio_swig_py_runtime.gr_top_block_sptr_start(*args)
RuntimeError: top block already running or wait() not called after
previous stop()
tb.wait()
tb.start()
tb.stop()
tb.wait()
$
*The fix for ticket:211, changeset r7053 last November caused this
divergence by moving the change in running status from stop() to
wait().
In general, these are cases where we have not told SWIG (via the
associated .i file) that a particular method may raise an exception.
Yes, this is a bug. There are probably a few of them. And QA code
should be testing these.
This is a good task for someone to contribute to GNU Radio, as the
patches would be only a couple lines in a .i file and a test in a QA
file. But there is time involved in searching for the places where we
have left these out.
If someone wants to work in this area, I’d be happy to walk them
through a couple instances.