discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Thread safety of PMT objects in python


From: Jonas Deitmerg
Subject: [Discuss-gnuradio] Thread safety of PMT objects in python
Date: Mon, 4 Jul 2016 21:33:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1

Hello everyone,

I've recently experienced some unexpected behavior when working with
PMTs in messages and tags. Although I have already figured out how to
avoid this issue, I'd like to know whether it's a systematic error or
just a misunderstanding on my part.

The problem arises when accessing 'old' PMTs. That is PMTs, that were
handed over to python from the C++ domain in the past, i.e. through a
message handling callback. It appears the PMTs are only valid throughout
the duration of the function they were handed to.

To illustrate the problem I have attached some python code which will
reliably crash with a segmentation fault.


Here's my current understanding of what's happening:

1. The block's thread sees a message that needs to be processed.

2. It dispatches the message (packed as pmt::pmt_t) to the callback
function. Through Swig. I assume the reference counting of the pmt
object is lost here.

3. The python function works on the data, e.g. saves it for later use.

4. Control returns to the C++ side, the pmt object goes out of scope and
is freed.

5. Some other python code tries to access the pmt object and a segfault
occurs.


Is this roughly correct? If so, is there a way to solve this nicely?
It's obviously possible to unpack the pmt object in step 3 and save the
contained data for later use. But I'm probably not the last one to get
bitten by this, and it's not exactly fun to debug.

My setup consists of gnuradio 3.7.9.2, swig 3.0.10 and python 2.7.11
running on Arch Linux, kernel 4.6.3, 64 bit.

Thanks in advance
Jonas

Attachment: min_err_repro.py
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]