Problem with my modified IP tunnelling example

GNU Radio
1

Hi,

I’ve tried the IP tunnelling example in
gnuradio-examples-0.7/python/gmsk2/tunnel_ip_null_mac.py and it seems to
work fine.

I’ve since been modifying the IP tunnelling example to use my MAC in
place
of null_mac. I have fixed the code to use the new MAC in the form of a
C++
extension.

However, now when I try to run the modified IP tunnelling example, the
program craches at either of two different points in init() of
transmit_path class with the message ‘Floating exception’. The exact
crash
point seems to depend on which directory I run the example in.

What’s wrong? What is a floating exception?

Thanks,
Jeremy

2

gnuradio-examples-0.7/python/gmsk2/tunnel_ip_null_mac.py and it seems to
work fine.

I’ve since been modifying the IP tunnelling example to use my MAC in place
of null_mac. I have fixed the code to use the new MAC in the form of a C++
extension.

That’s great that you’re working on some MAC algorithms, we really need
them. First, though, I noticed your using /python/gmsk2/. I’d recommend
updating to the newer release or ‘svn up’ if you use the repository.
That
directory is now called “digital” and does more than just GMSK. It might
also have a few bug fixes related to your problem.

Also, check out digital/tunnel.py for a CSMA MAC implementation.

However, now when I try to run the modified IP tunnelling example, the
program craches at either of two different points in init() of
transmit_path class with the message ‘Floating exception’. The exact crash
point seems to depend on which directory I run the example in.

What’s wrong? What is a floating exception?

A floating exception (I think) is a math error. You’re doing something
with
a float that can’t be computed.

You’ll need to post more information about your specific problem for me
to
be of any more help. Specifically, are you changing the transmit_path.py
file at all? If so, please post the changes.

Tom

3

On Mon, Nov 27, 2006 at 07:05:26PM +0800, Jeremy Chew wrote:

However, now when I try to run the modified IP tunnelling example, the
program craches at either of two different points in init() of
transmit_path class with the message ‘Floating exception’. The exact crash
point seems to depend on which directory I run the example in.

What’s wrong? What is a floating exception?

Thanks,
Jeremy

Sorry, I’ve got no clue.

Any particular reason you’re using really old code?
Consider using gnuradio-3.0.2 or svn.

See http://gnuradio.org/trac/wiki

Eric

4

Hi,

I’m using an older version as this is what that came when I downloaded
GR a
few months ago and I haven’t seen a need to change what I have
installed.
I’m new to GR, Linux and Python so I’m more eager to debug what I have
without introducing even newer stuff.

Anyway, the earlier problem was due to a C++ bug affecting another
thread.
This has been fixed. Now there’s a problem with passing the packets
created
in the C++ extension, called sm, to Python.

The following describes what I do, which is setting the callback, and
then
calling the callback.

SETTING THE CALLBACK POINTER IN THE C++ EXTENSION

The Python call that is to receive the packet from the C++ extension is
inherited from null_mac class and is named self.fg.send_pkt(). It is
passed
from a sub-class of null_mac in Python to the extension with:

sm.settx2llecallback(self.fg.send_pkt)

The corresponding C++ call is:

static PyObjects_pcTxDnCallback=0;
…
static
PyObjectsm_settx2llecallback(PyObjecta_pcSelf,PyObjecta_pcArgs)
{…
PyObject*l_pcCallback=0;
…
if(PyArg_ParseTuple(a_pcArgs,“O:set_callback”,&l_pcCallback))
{
if(PyCallable_Check(l_pcCallback))
{…
Py_XINCREF(l_pcCallback);
s_pcTxDnCallback=l_pcCallback;
…
}

When the above executes, PyCallable_Check() seems to run with no error.

PASSING PACKETS FROM THE EXTENSION TO PYTHON CODE

Later, a packet is created in the C++ extension in the form of an
unsigned
char array. To pass it to the Python IP tunneling code, I do the
following:

BOOL Tx2PyLle(unsigned chardata,UINT16 len)
{
…
PyObjectl_pcArgs=0;
…
l_pcArgs=Py_BuildValue(“(s#)”,reinterpret_cast<char*>(data),static_cast(len));
if(l_pcArgs )
{…
assert(s_pcTxDnCallback);
…;
PyObject*l_pcRet=PyEval_CallObject(s_pcTxDnCallback,l_pcArgs);
…
}

This function above has a segmentation fault at PyEval_CallObject().

My queries are:

  1. Is the callback to Python passed and set correctly in the extension?

  2. Is it right to assume that in Python, the packets are Python strings?

Thanks a lot,
Jeremy

----- Original Message -----
From: “Eric B.” [email protected]
To: “Jeremy Chew” [email protected]
Cc: [email protected]
Sent: Tuesday, November 28, 2006 2:53 AM
Subject: Re: [Discuss-gnuradio] Problem with my modified IP tunnelling
example

5

Thanks Eric.

Regarding the packet data-type, since I’m modifying
gnuradio-examples-0.7/python/gmsk2/tunnel_ip_null_mac.py, I want to have
the
same format used
in that file. Based on examination of the Python code used in there, I
understand that the packets are Python strings.

Could I confirm that this is true? I’m afraid that a wrong packet
data-type
is
causing the crash when the callback is called.

Jeremy

----- Original Message -----
From: “Eric B.” [email protected]
To: “Jeremy Chew” [email protected]
Cc: [email protected]
Sent: Tuesday, December 05, 2006 2:06 AM
Subject: Re: [Discuss-gnuradio] Problem with my modified IP tunnelling
example

6

On Mon, Dec 04, 2006 at 04:51:30PM +0800, Jeremy Chew wrote:

   if(PyCallable_Check(l_pcCallback))
   {...
       Py_XINCREF(l_pcCallback);
       s_pcTxDnCallback=l_pcCallback;

…
}

When the above executes, PyCallable_Check() seems to run with no error.

OK.

l_pcArgs=Py_BuildValue("(s#)",reinterpret_cast<char*>(data),static_cast(len));
My queries are:

  1. Is the callback to Python passed and set correctly in the extension?

Beat me. I let SWIG handle all this stuff for me.
FWIW, the latest GNU Radio code uses SWIG directors to enable C++ code
to call back into Python. It works fine as long as you are using SWIG
1.3.31.

  1. Is it right to assume that in Python, the packets are Python strings?

The message payloads are strings. The gr.messages are wrapped C++
objects (not strings). I’m not sure which type you are trying to pass
to/from C++.

Eric

7

Thanks again. This information really helps.

This may sound like a silly question: If the packets are SWIG-wrapped,
am I
right that this means I need to use SWIG to handle them in the C++
extension? This is an important question to me as I am not familiar with
SWIG.

Jeremy

----- Original Message -----
From: “Eric B.” [email protected]
To: “Jeremy Chew” [email protected]
Cc: [email protected]; “Harry Han” [email protected]
Sent: Tuesday, December 05, 2006 12:22 PM
Subject: Re: [Discuss-gnuradio] Problem with my modified IP tunnelling
example

8

On Tue, Dec 05, 2006 at 11:06:04AM +0800, Jeremy Chew wrote:

causing the crash when the callback is called.

Jeremy

It’s a SWIG wrapped C++ gr_message_sptr. It is not a string.

[eb@cyan ~]$ python
Python 2.4.2 (#1, Oct 13 2006, 17:11:24)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.

from gnuradio import gr
m=gr.message()
m
<gnuradio.gr.gnuradio_swig_python.gr_message_sptr; proxy of <Swig Object
of type ‘gr_message_sptr *’ at 0x80c44b8> >

type(m)
<class ‘gnuradio.gr.gnuradio_swig_python.gr_message_sptr’>

9

On Wed, Dec 06, 2006 at 03:12:34PM +0800, Jeremy Chew wrote:

Thanks again. This information really helps.

This may sound like a silly question: If the packets are SWIG-wrapped, am I
right that this means I need to use SWIG to handle them in the C++
extension? This is an important question to me as I am not familiar with
SWIG.

Jeremy

Jeremy,

I keep getting the feeling that “you are not doing your homework.”

There is good documentation on SWIG at www.swig.org.

You have all of the GNU Radio code in front of you.

It seems rather foolish to attempt to extend GNU Radio in a
non-standard way without understanding the “how” or “why” of the
standard (known to work!) method.

http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html

You continue down the same path even though I pointed out in one of my
last messages to you that the code in the trunk supports calling back
from C++ into Python using the gr_feval* classes.

If you don’t take advantage of information that people give you, why
would you expect them to give you more?

Eric