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]
Discuss-gnuradio Info Page
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:
What are you trying toMB
–
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
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 
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.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs