[PD] totally absurd

2007-10-05 Thread matteo sisti sette
Hi,

I'm struggling with a problem of the most weird kind.

I've not been able to isolate it, but I do can report a systematic
behaviour which astonishes me.

PD-Vanilla 0.40.1 in Windows XP

I have an enormous very complex patch that I've been developing for
months, built with a careful top-down/bottom-up design (i.e. designing
and reusing a huge lot of abstractions at various levels), with a lot
of GOP, also nested.
Up to now I didn't have any serious problem, and the programming of
the patch is quite clean; for example I used to be able to use it for
hours without without a single error message ever showing up in the
output.

Now, after some recent changes, the ABSURD behaviour is:

*CASE 1*
-I launch PD
-I open my main patch
-PD crashes immediately

*CASE 2*
-I launch PD
-I create a new patch (File/new)
-I put a [route a b c] (literally) object, and NOTHING more
-I open my main patch
-PD DOESN'T crash and the patch works great as it used to do.


If I launch PD with from commandline with -noloadbang, it never
crashes, so I guess the crash is caused by some message triggered by
some loadbang



I've repeated the two tests tens of times (always closing pd and
starting over from scratch) and the results are 100% coherent, i.e.
case 1 always crashes, and case 2 never crashes.
I'm really astonished: how is it possible that the mere existence or
non existence of a [route] object not connected to anything can
prevent or not the crash, whatever causes it?!!!???!?!?

I know I'm giving too little information to ask for a diagnosis, but
does anybody know of some weired bug of [route]??


The recent changes mentioned above, are in the [control_element]
abstractionn that I attach, which uses the [schange] and [switch2]
abstractions.
I can't see anything wrong in them
I can't reproduce the bug with a simple test patch using an instance
of [control_element]. It is used tons of times in my main patch.

Any idea? Do you see any potential problem in the attached patch that
may cause illegal situations under some circumstances?


I will greatly appreciate any help

Bye
m.

-- 
Matteo Sisti Sette
[EMAIL PROTECTED]
http://www.matteosistisette.com
#N canvas 377 0 760 672 12;
#X obj 151 81 r \$1-if-send;
#X obj 151 107 s \$1;
#X obj 200 151 r \$1;
#X obj 250 765 s \$1-if-receive;
#X obj 199 231 route float symbol;
#X obj 72 554 change;
#X obj 10 372 switch2;
#X msg 32 434 set \$1;
#X obj 29 404 t b f f;
#X msg 85 378 1;
#X obj 425 596 schange;
#X obj 475 416 switch2;
#X msg 533 506 set \$1;
#X msg 550 422 1;
#X obj 536 462 t b s s;
#X obj 242 673 list prepend set;
#X obj 242 703 list trim;
#X text 63 305 change object;
#X text 65 278 this used to go;
#X text 65 292 directly to the;
#X text 360 317 this used to go;
#X text 360 331 directly to the;
#X text 358 344 schange object;
#X connect 0 0 1 0;
#X connect 2 0 4 0;
#X connect 4 0 6 0;
#X connect 4 1 11 0;
#X connect 4 2 15 0;
#X connect 5 0 15 0;
#X connect 6 0 8 0;
#X connect 6 1 5 0;
#X connect 7 0 5 0;
#X connect 8 0 9 0;
#X connect 8 1 7 0;
#X connect 8 2 15 0;
#X connect 9 0 6 1;
#X connect 10 0 15 0;
#X connect 11 0 14 0;
#X connect 11 1 10 0;
#X connect 12 0 10 0;
#X connect 13 0 11 1;
#X connect 14 0 13 0;
#X connect 14 1 12 0;
#X connect 14 2 15 0;
#X connect 15 0 16 0;
#X connect 16 0 3 0;
#N canvas 263 183 639 477 12;
#X obj 115 59 inlet;
#X obj 107 368 outlet;
#X obj 387 375 outlet;
#X obj 389 77 inlet;
#X obj 389 170 select 0 1;
#X obj 290 48 loadbang;
#X obj 290 102 f \$1;
#X obj 109 288 spigot 1;
#X obj 369 291 spigot 0;
#X msg 138 242 1;
#X msg 178 243 0;
#X msg 402 247 1;
#X msg 442 248 0;
#X obj 141 207 t b b;
#X obj 364 207 t b b;
#X connect 0 0 8 0;
#X connect 0 0 7 0;
#X connect 3 0 4 0;
#X connect 4 0 13 0;
#X connect 4 1 14 0;
#X connect 5 0 6 0;
#X connect 6 0 4 0;
#X connect 7 0 1 0;
#X connect 8 0 2 0;
#X connect 9 0 7 1;
#X connect 10 0 7 1;
#X connect 11 0 8 1;
#X connect 12 0 8 1;
#X connect 13 0 12 0;
#X connect 13 1 9 0;
#X connect 14 0 10 0;
#X connect 14 1 11 0;
#N canvas 444 238 458 308 12;
#X obj 171 46 inlet;
#X obj 189 274 outlet;
#X obj 181 152 select -;
#X obj 177 211 t s s;
#X obj 105 86 route set;
#X obj 105 111 symbol;
#X connect 0 0 4 0;
#X connect 2 1 3 0;
#X connect 3 0 1 0;
#X connect 3 1 2 1;
#X connect 4 0 5 0;
#X connect 4 1 2 0;
#X connect 5 0 2 1;
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] totally absurd

2007-10-05 Thread IOhannes m zmoelnig
matteo sisti sette wrote:
 I'm really astonished: how is it possible that the mere existence or
 non existence of a [route] object not connected to anything can
 prevent or not the crash, whatever causes it?!!!???!?!?

most likely you are experiencing memory corruption.
the instantation of another object ([route]) will just change the memory
layout sufficiently to not expose the bug.

 I know I'm giving too little information to ask for a diagnosis, but
 does anybody know of some weired bug of [route]??

as said above, it is unlikely that [route] is directly related to your
trouble. it just helps to (not) expose the real problem.


this kind of bugs is generally hard to track down.
i would suggest to create a list of all objects you are using, do a
ranking of the likelihood that they are the culprits and investigate
them separately.

also make sure that you are using the latest and greatest (well, the
greatest might be sufficient) release of any externals you are using.


fmga.dsr
IOhannes

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list