Hi list,
I'm having problems already cited elsewhere with rvbap - whereby it crashes with a "Signal 6" when adjusting the azimuth and having first configured the external with a 2D speaker array (eg. with a message: "define_loudspeakers 2 -45 45 0 180").
While i've seen this reported i haven't seen any solutions. eg. here: http://sourceforge.net/tracker/index.php?func=detail&aid=3383881&gro...
I've tried this with pdextended on linux (i'm using ubuntu 11.04) and also by compiling the external with this source: http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/vbap/
Same thing.
Does anyone have any suggestions?
thanks,
Iain
Le 2011-10-05 à 14:59:00, Iain Mott a écrit :
I'm having problems already cited elsewhere with rvbap - whereby it crashes with a "Signal 6" when adjusting the azimuth and having first configured the external with a 2D speaker array (eg. with a message: "define_loudspeakers 2 -45 45 0 180"). I've tried this with pdextended on linux (i'm using ubuntu 11.04) and also by compiling the external with this source: http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/vbap/ Same thing. Does anyone have any suggestions?
When you compile the external from source, you have the possibility to enable debug. I edited Makefile (with an uppercase) to change that, but debugging info was already enabled (-g). I changed the optimisation flags though (-O1 instead of -O6 -fomit-frame-pointer).
btw, the use of those flags is misleading, as -O6 is completely the same as -O3, and -fomit-frame-pointer (which hinders debugging) is already included in -O2 and -O3 (in -O1 it depends, see manpage).
-funroll-loops, however, has no impact on debuggability...
Then if you run :
valgrind pd vbap-help.pd
and click around a bit, you get :
==10071== Invalid read of size 4 ==10071== at 0x4F42667: additive_vbap (vbap.c:419) ==10071== by 0x4F43527: vbap_bang (vbap.c:526) ==10071== by 0x4F45217: choose_ls_tuplets (define_loudspeakers.c:757) ==10071== by 0x4F45664: vbap_def_ls (define_loudspeakers.c:62) ==10071== by 0x80C7498: pd_typedmess (m_class.c:716) ==10071== by 0x3FFFFFFF: ??? ==10071== Address 0x43886bc is 4 bytes before a block of size 16 alloc'd ==10071== at 0x4024F12: calloc (vg_replace_malloc.c:467) ==10071== by 0x80CB2BC: getbytes (m_memory.c:24) ==10071== by 0x4F45217: choose_ls_tuplets (define_loudspeakers.c:757) ==10071== by 0x4F45664: vbap_def_ls (define_loudspeakers.c:62) ==10071== by 0x80C7498: pd_typedmess (m_class.c:716) ==10071== by 0x3FFFFFFF: ???
which is a lot more informative when it can report function names, rather than just the library names...
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Thanks for the debugging information. I followed your instructions and came up with similar errors when running:
valgrind pd rvbap-help.pd
ie.
==4000== Invalid write of size 4 ==4000== at 0x4034D0F: rvbap_bang (rvbap.c:619) ==4000== by 0x80B7362: outlet_bang (in /usr/bin/pd) ==4000== Address 0x49df6ec is 4 bytes before a block of size 16 alloc'd ==4000== at 0x4025315: calloc (vg_replace_malloc.c:467) ==4000== by 0x80B8710: getbytes (in /usr/bin/pd) ==4000==
this corresponds to the following block of code and the last statement in this "final_gs[ls[i]-1]=g[i];", is line 619 cited above.
static void rvbap_bang(t_rvbap *x)
// top level, vbap gains are calculated and outputted
{
t_atom at[MAX_LS_AMOUNT];
float g[3];
long ls[3];
long i;
float *final_gs, overdist, oversqrtdist;
final_gs = (float *) getbytes(x->x_ls_amount * sizeof(float));
if(x->x_lsset_available ==1){
vbap(g, ls, x);
for(i=0;i<x->x_ls_amount;i++)
final_gs[i]=0.0;
for(i=0;i<x->x_dimension;i++){
final_gs[ls[i]-1]=g[i];
}
.........
My C programming is very rusty to say the least and I've not been able to fix it.
If it's obvious to anyone else - please let me know.
Best,
Iain
On Wed, 2011-10-05 at 21:13 -0400, Mathieu Bouchard wrote:
Le 2011-10-05 à 14:59:00, Iain Mott a écrit :
I'm having problems already cited elsewhere with rvbap - whereby it crashes with a "Signal 6" when adjusting the azimuth and having first configured the external with a 2D speaker array (eg. with a message: "define_loudspeakers 2 -45 45 0 180"). I've tried this with pdextended on linux (i'm using ubuntu 11.04) and also by compiling the external with this source: http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/vbap/ Same thing. Does anyone have any suggestions?
When you compile the external from source, you have the possibility to enable debug. I edited Makefile (with an uppercase) to change that, but debugging info was already enabled (-g). I changed the optimisation flags though (-O1 instead of -O6 -fomit-frame-pointer).
btw, the use of those flags is misleading, as -O6 is completely the same as -O3, and -fomit-frame-pointer (which hinders debugging) is already included in -O2 and -O3 (in -O1 it depends, see manpage).
-funroll-loops, however, has no impact on debuggability...
Then if you run :
valgrind pd vbap-help.pd
and click around a bit, you get :
==10071== Invalid read of size 4 ==10071== at 0x4F42667: additive_vbap (vbap.c:419) ==10071== by 0x4F43527: vbap_bang (vbap.c:526) ==10071== by 0x4F45217: choose_ls_tuplets (define_loudspeakers.c:757) ==10071== by 0x4F45664: vbap_def_ls (define_loudspeakers.c:62) ==10071== by 0x80C7498: pd_typedmess (m_class.c:716) ==10071== by 0x3FFFFFFF: ??? ==10071== Address 0x43886bc is 4 bytes before a block of size 16 alloc'd ==10071== at 0x4024F12: calloc (vg_replace_malloc.c:467) ==10071== by 0x80CB2BC: getbytes (m_memory.c:24) ==10071== by 0x4F45217: choose_ls_tuplets (define_loudspeakers.c:757) ==10071== by 0x4F45664: vbap_def_ls (define_loudspeakers.c:62) ==10071== by 0x80C7498: pd_typedmess (m_class.c:716) ==10071== by 0x3FFFFFFF: ???
which is a lot more informative when it can report function names, rather than just the library names...
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-10-06 à 08:32:00, Iain Mott a écrit :
Thanks for the debugging information. I followed your instructions and came up with similar errors when running:
I don't know why we get different numbers of stack items, but if you want more than two, look for the --num-callers=… option.
But yeah, we are getting the same errors, it's just that the one I posted at first was for a bug in [vbap] and not [rvbap].
My C programming is very rusty to say the least and I've not been able to fix it.
Well, it's not like it's a super-obvious fix. I think both bugs take more than a few minutes of reading.
If it's obvious to anyone else - please let me know.
I'm emailing the authors... I don't know them, but anyway...
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-10-06 à 10:31:00, Mathieu Bouchard a écrit :
Well, it's not like it's a super-obvious fix. I think both bugs take more than a few minutes of reading.
If it's obvious to anyone else - please let me know.
I'm emailing the authors... I don't know them, but anyway...
It really looks like two copies of the same bug, or almost. It's not a copy-paste, but both happen when doing
final_gs[ls[something]-1]=stuff;
.......
duh. here's the fix for one bug. but the other one would take more investigation.
Index: vbap.c
--- vbap.c (révision 15520) +++ vbap.c (copie de travail) @@ -77,6 +77,7 @@ #ifdef PD void vbap_setup(void) {
- post("%s: matju was here",__FUNCTION__); vbap_class = class_new(gensym("vbap"), (t_newmethod)vbap_new, 0,
(short)sizeof(t_vbap), 0, A_DEFFLOAT, A_DEFFLOAT, A_DEFFLOAT, 0);
@@ -415,7 +416,7 @@
final_gs[ls[0]-1] += g[0];
final_gs[ls[1]-1] += g[1];
final_gs[ls[2]-1] += g[2];
if (dim==3) final_gs[ls[2]-1] += g[2]; }}
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Oct 6, 2011, at 11:10 AM, Mathieu Bouchard wrote:
Le 2011-10-06 à 10:31:00, Mathieu Bouchard a écrit :
Well, it's not like it's a super-obvious fix. I think both bugs
take more than a few minutes of reading.If it's obvious to anyone else - please let me know.
I'm emailing the authors... I don't know them, but anyway...
It really looks like two copies of the same bug, or almost. It's not
a copy-paste, but both happen when doingfinal_gs[ls[something]-1]=stuff;
.......
duh. here's the fix for one bug. but the other one would take more
investigation.Index: vbap.c
--- vbap.c (révision 15520) +++ vbap.c (copie de travail) @@ -77,6 +77,7 @@ #ifdef PD void vbap_setup(void) {
- post("%s: matju was here",__FUNCTION__); vbap_class = class_new(gensym("vbap"), (t_newmethod)vbap_new, 0,
(short)sizeof(t_vbap), 0, A_DEFFLOAT, A_DEFFLOAT, A_DEFFLOAT, 0);
@@ -415,7 +416,7 @@
final_gs[ls[0]-1] += g[0]; final_gs[ls[1]-1] += g[1];
final_gs[ls[2]-1] += g[2];
if (dim==3) final_gs[ls[2]-1] += g[2];}
Thanks for digging that up, matju, I committed it. The sad thing is
that I fixed that bug back in 2006, then rvbap was forked off of that
version of vbap. Then I ported the newest version of vbap to Pd from
scratch, but forgot to include that bug fix.
/* BUG FIX: this was causing negative indices with 2
dimensions so I * made it only try when using 3 dimensions. * 2006-08-13 hans@at.or.at */
I guess that still leaves the rvbap bug tho. Perhaps the thing to do
is to take the rvbap changes to vbap, and then make a new rvbap based
on the new vbap.
.hc
“We must become the change we want to see. - Mahatma Gandhi
Le 2011-10-05 à 21:13:00, Mathieu Bouchard a écrit :
Then if you run :
valgrind pd vbap-help.pd
and click around a bit, you get :
Actually that's a different bug than the one you found, but that's a bug anyway, and it's the kind of thing that can cause a crash later (e.g. while closing a patch), though I don't know how to get it to really crash.
I made two mistakes... I forgot to paste that there's an Invalid Write of same size at the same place in the programme, just after the Read... a Write is more dangerous.
The other mistake, of course, is that at one point I switched from trying rvbap-help.pd to trying vbap-help.pd without even noticing. With rvbap-help.pd, I get this crash instead :
Invalid write of size 4 at 0x796DB34: rvbap_bang (rvbap.c:619) by 0x80CA552: outlet_bang (m_obj.c:371) by 0x80CA552: outlet_bang (m_obj.c:371) by 0x80FCB3A: trigger_list (x_connective.c:981) by 0x80FCE26: trigger_float (x_connective.c:1025) by 0x80CA0A6: outlet_float (m_obj.c:397) by 0x80CA0A6: outlet_float (m_obj.c:397) by 0x8079BFD: gatom_bang (g_text.c:585) by 0x807DEC1: gatom_motion (g_text.c:615) by 0x80A9268: canvas_motion (g_editor.c:1821) by 0x80C7765: pd_typedmess (m_class.c:792) by 0x80C734B: pd_typedmess (m_class.c:813) Address 0x461d424 is 4 bytes before a block of size 16 alloc'd at 0x4024F12: calloc (vg_replace_malloc.c:467) by 0x80CB2BC: getbytes (m_memory.c:24) by 0x80CA552: outlet_bang (m_obj.c:371) by 0x80CA552: outlet_bang (m_obj.c:371) by 0x80FCB3A: trigger_list (x_connective.c:981) by 0x80FCE26: trigger_float (x_connective.c:1025) by 0x80CA0A6: outlet_float (m_obj.c:397) by 0x80CA0A6: outlet_float (m_obj.c:397) by 0x8079BFD: gatom_bang (g_text.c:585) by 0x807DEC1: gatom_motion (g_text.c:615) by 0x80A9268: canvas_motion (g_editor.c:1821) by 0x80C7765: pd_typedmess (m_class.c:792)
which might or might not be a copy of the same bug...
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-
Hans-Christoph Steiner -
Iain Mott -
Mathieu Bouchard