Hey all,
I'm stuck on debugging this issue.
The problem is that I've approached all the gphoto calling functions the same, but one particular function (listconfig) segfaults when I use PD functions, in particular outlet_symbol().
I've attached the src.
What is different about listconfig compared to say, getconfig, which works without a hitch?
The backtrace does not mean much to me: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x48021320 (LWP 17483)] outlet_symbol (x=0x24, s=0x100c8cb8) at m_obj.c:364 364 for (oc = x->o_connections; oc; oc = oc->oc_next) (gdb) bt #0 outlet_symbol (x=0x24, s=0x100c8cb8) at m_obj.c:364 #1 0x0fd3bff0 in listConfig () from /home/bbogart/src/gphoto/gphoto.pd_linux #2 0x1004ec28 in pd_typedmess (x=0x100c7d80, s=0x24442442, argc=269257912, argv=0x7f7f7f7f) at m_class.c:728 #3 0x10050ad4 in outlet_anything (x=<value optimized out>, s=0x100c7490, argc=0, argv=0x100aafe0) at m_obj.c:387
Any help would be appreciated.
Thanks, .b.
On Wed, 18 Mar 2009, B. Bogart wrote:
The problem is that I've approached all the gphoto calling functions the same, but one particular function (listconfig) segfaults when I use PD functions, in particular outlet_symbol(). I've attached the src. What is different about listconfig compared to say, getconfig, which works without a hitch?
You can't use Pd functions from another thread than the one that Pd runs in. Even banalities like gensym can fail.
Because those are race-condition issues, it will look like most things work, until something previously working mysteriously fails because of an obscure lucky timing that isn't lucky anymore. Very often, those crashes will appear to be random. They may also be "heisenbugs", which means that the bug seemingly disappears when you try to track it down, then reappears as soon as you try to run the programme normally...
You will need a special contraption to have the second thread talk to the first thread, involving a threadsafe queue of messages and something in the first thread that looks for messages in the queue. (argh.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
The problem is that I've approached all the gphoto calling functions the same, but one particular function (listconfig) segfaults when I use PD functions, in particular outlet_symbol().
when calling pd's api functions from a separate thread, make sure to hold the global pd lock ...
tim
On Wed, 18 Mar 2009, Tim Blechmann wrote:
The problem is that I've approached all the gphoto calling functions the same, but one particular function (listconfig) segfaults when I use PD functions, in particular outlet_symbol().
when calling pd's api functions from a separate thread, make sure to hold the global pd lock ...
Yes, sorry, I should have known.
This is sys_lock() and sys_unlock() if pd is compiled with THREAD_LOCKING enabled.
Afaik, this will do the rough equivalent of a [delay 0] across threads, so that your (Ben's) thread's execution is inserted between two t_clock events ([delay], [metro], etc.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Mathieu Bouchard wrote:
On Wed, 18 Mar 2009, Tim Blechmann wrote:
The problem is that I've approached all the gphoto calling functions the same, but one particular function (listconfig) segfaults when I use PD functions, in particular outlet_symbol().
when calling pd's api functions from a separate thread, make sure to hold the global pd lock ...
Yes, sorry, I should have known.
This is sys_lock() and sys_unlock() if pd is compiled with THREAD_LOCKING enabled.
right, didn't remember the function names ...
Afaik, this will do the rough equivalent of a [delay 0] across threads, so that your (Ben's) thread's execution is inserted between two t_clock events ([delay], [metro], etc.)
not really ... [delay 0] will schedule the outlet during the next dsp tick in the pd thread ... waiting for the interpreter lock requires the os to schedule the thread, the function and all triggered object functions, are called in the object thread ...
tim
On Wed, 18 Mar 2009, Tim Blechmann wrote:
Mathieu Bouchard wrote:
Afaik, this will do the rough equivalent of a [delay 0] across threads, so that your (Ben's) thread's execution is inserted between two t_clock events ([delay], [metro], etc.)
not really ... [delay 0] will schedule the outlet during the next dsp tick in the pd thread ...
uh, i haven't read that part of the code in detail, but wouldn't that be _before_ the next dsp tick instead? (I was likening sys_lock to the use of [delay] in a single-threaded setting, I wasn't suggesting to use the real [delay] in a multi-thread setting)
waiting for the interpreter lock requires the os to schedule the thread, the function and all triggered object functions, are called in the object thread ...
I was beginning to reply to this paragraph, but I realised that I don't understand the grammar of it. Could you please rephrase?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Afaik, this will do the rough equivalent of a [delay 0] across threads, so that your (Ben's) thread's execution is inserted between two t_clock events ([delay], [metro], etc.)
not really ... [delay 0] will schedule the outlet during the next dsp tick in the pd thread ...
uh, i haven't read that part of the code in detail, but wouldn't that be _before_ the next dsp tick instead? (I was likening sys_lock to the use of [delay] in a single-threaded setting, I wasn't suggesting to use the real [delay] in a multi-thread setting)
tick: - timer callbacks - signal processing
waiting for the interpreter lock requires the os to schedule the thread, the function and all triggered object functions, are called in the object thread ...
I was beginning to reply to this paragraph, but I realised that I don't understand the grammar of it. Could you please rephrase?
|threaded object a| | |trivial object b|
thread of object a: - call sys_lock(), blocking - os wakes this thread - call inlet handlers of object b - ...
tim
Tim Blechmann wrote:
not really ... [delay 0] will schedule the outlet during the next dsp tick in the pd thread ...
i'm pretty sure that this is _not_ true. a [delay 0] will schedule the message within the same tick. actually i haven't found a simple & reliable way to schedule a message in the next tick, regardless of samplerate and blocksize.
fgmasdr IOhannes
not really ... [delay 0] will schedule the outlet during the next dsp tick in the pd thread ...
i'm pretty sure that this is _not_ true. a [delay 0] will schedule the message within the same tick.
rescheduling a timer interrupt from a second thread, there is no such thing as the `same tick' ;)
Tim Blechmann wrote:
not really ... [delay 0] will schedule the outlet during the next dsp tick in the pd thread ...
i'm pretty sure that this is _not_ true. a [delay 0] will schedule the message within the same tick.
rescheduling a timer interrupt from a second thread, there is no such thing as the `same tick' ;)
ah yes, i forgot that there are only "next ticks" :-)
fgmasdr IOhannes
On Thu, 19 Mar 2009, Tim Blechmann wrote:
rescheduling a timer interrupt from a second thread, there is no such thing as the `same tick' ;)
Are you assuming that pd is running with any realtime priority like -rt ? What about -nrt ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Thanks for the comments Tim & Mathieu,
It seems I have two options:
* Not send output to PD (very limited functionality)
* Use Tim's suggestion.
Mathieu Bouchard wrote:
Afaik, this will do the rough equivalent of a [delay 0] across threads, so that your (Ben's) thread's execution is inserted between two t_clock events ([delay], [metro], etc.)
Does this mean that rendering/audio in PD will be interrupted during this time of global locking?
Ah! I would only need to lock while before I do the PD calls right?
Something like:
sys_lock(); outlet_symbol(); sys_unlock();
?
Thanks! .b.
On Wed, 18 Mar 2009, Tim Blechmann wrote:
The problem is that I've approached all the gphoto calling functions the same, but one particular function (listconfig) segfaults when I use PD functions, in particular outlet_symbol().
when calling pd's api functions from a separate thread, make sure to hold the global pd lock ...
Yes, sorry, I should have known.
This is sys_lock() and sys_unlock() if pd is compiled with THREAD_LOCKING enabled.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Thu, 19 Mar 2009, B. Bogart wrote:
Mathieu Bouchard wrote:
Afaik, this will do the rough equivalent of a [delay 0] across threads, so that your (Ben's) thread's execution is inserted between two t_clock events ([delay], [metro], etc.)
Does this mean that rendering/audio in PD will be interrupted during this time of global locking?
Well, in the same way that when a [delay] or a [metro] outputs a bang it "interrupts" the rendering. But those events are never nested nor overlapping in real time, so a block always finishes computation before something else happens, and a message sent from [delay] always gets "fully processed" before something else happens, and so on. It wouldn't be much different from what you'd get if you turned the 2nd thread into a separate server that you'd communicate with using [netsend], really.
The only thing is that sometimes, pd runs in the 2nd thread, but that doesn't make so much of a difference, as pd is then not running in the 1st thread at the same time. The question is not which thread is in use, but how many of them at a time.
Replacing the lock by a message queue could have had some advantages, but it's more work.
Ah! I would only need to lock while before I do the PD calls right? sys_lock(); outlet_symbol(); sys_unlock(); ?
Exactly.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Thanks for all the comments.
I'm now added wrapped outlet calls with sys_lock() and sys_unlock().
The reason I was getting a constant segfault in listconfig (and not in the other functions) was that I was calling the thread function, not the wrapper!
So I've checked gphoto into svn, under "bbogart".
Lots of extra features to add, but this is a decent base that allows a linux user to control a supported PTP camera from PD.
Should I put a sys_lock() and sys_unlock() for each post() and error() call?
Feel free to tinker with it, writing the "TODO" now.
.b.
Mathieu Bouchard wrote:
On Thu, 19 Mar 2009, B. Bogart wrote:
Mathieu Bouchard wrote:
Afaik, this will do the rough equivalent of a [delay 0] across threads, so that your (Ben's) thread's execution is inserted between two t_clock events ([delay], [metro], etc.)
Does this mean that rendering/audio in PD will be interrupted during this time of global locking?
Well, in the same way that when a [delay] or a [metro] outputs a bang it "interrupts" the rendering. But those events are never nested nor overlapping in real time, so a block always finishes computation before something else happens, and a message sent from [delay] always gets "fully processed" before something else happens, and so on. It wouldn't be much different from what you'd get if you turned the 2nd thread into a separate server that you'd communicate with using [netsend], really.
The only thing is that sometimes, pd runs in the 2nd thread, but that doesn't make so much of a difference, as pd is then not running in the 1st thread at the same time. The question is not which thread is in use, but how many of them at a time.
Replacing the lock by a message queue could have had some advantages, but it's more work.
Ah! I would only need to lock while before I do the PD calls right? sys_lock(); outlet_symbol(); sys_unlock(); ?
Exactly.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Thu, 19 Mar 2009, B. Bogart wrote:
Should I put a sys_lock() and sys_unlock() for each post() and error() call?
I'd like to say no, but the answer is yes, really.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Hi Ben, if it's just about sending messages to outlets, you could also use a lock-free fifo to queue up the messages (in the second thread) and a timer to send out the elements to the outlets asynchronously (pd thread). That's what flext does internally. gr~~~
Am 19.03.2009 um 17:28 schrieb B. Bogart:
Thanks for the comments Tim & Mathieu,
It seems I have two options:
Not send output to PD (very limited functionality)
Use Tim's suggestion.
Mathieu Bouchard wrote:
Afaik, this will do the rough equivalent of a [delay 0] across threads, so that your (Ben's) thread's execution is inserted between two t_clock events ([delay], [metro], etc.)
Does this mean that rendering/audio in PD will be interrupted during this time of global locking?
Ah! I would only need to lock while before I do the PD calls right?
Something like:
sys_lock(); outlet_symbol(); sys_unlock();
?
Thanks! .b.
On Wed, 18 Mar 2009, Tim Blechmann wrote:
The problem is that I've approached all the gphoto calling functions the same, but one particular function (listconfig) segfaults when I use PD functions, in particular outlet_symbol().
when calling pd's api functions from a separate thread, make sure to hold the global pd lock ...
Yes, sorry, I should have known.
This is sys_lock() and sys_unlock() if pd is compiled with THREAD_LOCKING enabled.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
B. Bogart -
IOhannes m zmoelnig -
Mathieu Bouchard -
Thomas Grill -
Tim Blechmann