Segmentation fault in wav file sink

All,

The attached script crashes with a segmentation fault (or with the I/O
error text in the code). My C++ knowledge is lacking however I believe
this
is because work() and close() are both being called simultaneously from
different threads. The close() call is being made while the execution of
work() is already past the “is this file handle working?” test (I
think?).

Thanks,
Matt.

On 12/11/2011 03:18 AM, Matt M. wrote:

Matt.


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I think that what I’d do is cause the close() method to simply set a
flag that says “close desired”, and then do the actual close at the end
of
the work function, probably under a mutex.

If there is no samples flowing into the wav file sink block would work()
be
called? (IE, if there is a closed valve in front of the wav_file sink)

On Sun, Dec 11, 2011 at 01:18:59AM -0700, Matt M. wrote:

All,

The attached script crashes with a segmentation fault (or with the I/O error
text in the code). My C++ knowledge is lacking however I believe this is
because work() and close() are both being called simultaneously from different
threads. The close() call is being made while the execution of work() is
already past the “is this file handle working?” test (I think?).

Hi Matt,

a couple of things:

  • Do you randomly get either segfault or i/o error? I always get the i/o
    with this code.
  • Your code stresses the WAV-code a lot :slight_smile: What are you trying to
    accomplish? Are you finding a bug in wavfile_sink or do you need this
    behaviour for something? Because you don’t need close() if you just
    want to switch files.
  • In any case, you’re right. It’s possible to call close() during work()
    after do_update() is finished and thus yank the fp out from under our
    feet. Actually, I can’t think of any case where we need to call
    close() manually–perhaps it should even be private?

MB


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

On Mon, Dec 12, 2011 at 3:41 AM, Martin B. [email protected]
wrote:

  • Do you randomly get either segfault or i/o error? I always get the i/o
    with this code…

I get both.

  • Your code stresses the WAV-code a lot :slight_smile: What are you trying to
    accomplish? Are you finding a bug in wavfile_sink or do you need this
    behaviour for something? Because you don’t need close() if you just
    want to switch files.
  • In any case, you’re right. It’s possible to call close() during work()
    after do_update() is finished and thus yank the fp out from under our
    feet. Actually, I can’t think of any case where we need to call
    close() manually–perhaps it should even be private?

I don’t think making close() private is really the right solution. I’m
recording distinct conversations so having an open() unmute() mute()
close() sequence per call makes the most sense (if a channel is idle for
20
minutes between transmissions then I’m going to have the last wav file
open
for 20 minutes; unless I open a temporary file to write nothing to,
which
just seems silly).

-Matt.

On Mon, Dec 12, 2011 at 11:49:56AM +0100, Martin B. wrote:

On Sun, Dec 11, 2011 at 02:31:03PM -0500, Marcus D. Leech wrote:

I think that what I’d do is cause the close() method to simply set a flag that
says “close desired”, and then do the actual close at the end of
the work function, probably under a mutex.

That sounds sensible. It could be done in do_update().

I’m sending a patch to patch-gnuradio. In it’s current form, it’s just
not thread-safe.

MB


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

On Sun, Dec 11, 2011 at 02:31:03PM -0500, Marcus D. Leech wrote:

I think that what I’d do is cause the close() method to simply set a flag that
says “close desired”, and then do the actual close at the end of
the work function, probably under a mutex.

That sounds sensible. It could be done in do_update().

MB


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

On Mon, Dec 12, 2011 at 10:47 AM, Martin B. [email protected]
wrote:

not thread-safe.

But wont this only close() a file when the sink is receiving samples? I
would think it would be extremely confusing if close() doesnt actually
close a file until the next sample is received, especially if there is a
valve in front of the wav_file sink.

On Mon, Dec 12, 2011 at 10:57 AM, Matt M. [email protected] wrote:

But wont this only close() a file when the sink is receiving samples? I
would think it would be extremely confusing if close() doesnt actually
close a file until the next sample is received, especially if there is a
valve in front of the wav_file sink.

Nevermind, I suppose I should look at the patch BEFORE replying :wink:

On Tue, Dec 13, 2011 at 11:24 PM, Matt M. [email protected] wrote:

On Mon, Dec 12, 2011 at 10:52 AM, Martin B. [email protected]wrote:

Yes, that makes sense. Try this (is the same as what I sent to
patch-gnuradio). It works with your script.

FYI, I’ve run this for the past 24 hours (on the production app, not the
test script) and haven’t seen any segfaults.

That’s great, thanks for the update.

I’ve applied Martin’s patch on the ‘next’ branch.

Tom

On Mon, Dec 12, 2011 at 10:52 AM, Martin B. [email protected]
wrote:

Yes, that makes sense. Try this (is the same as what I sent to
patch-gnuradio). It works with your script.

FYI, I’ve run this for the past 24 hours (on the production app, not the
test script) and haven’t seen any segfaults.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs