Bugs item #1469910, was opened at 2006-04-13 18:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1469910...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frank Barknecht (fbar) Assigned to: Miller Puckette (millerpuckette) Summary: Stack overflow with Data Structure arrays saved in patch
Initial Comment: Instances of data structure arrays that are saved in a patch can make that patch impossible to open again, if they are above a certain size. With attached patch, I can create and an array "cells" in the struct "ca" with up to 20 times 20 elements, 21 times 21 elements will give a message stack overflow on loading the patch.
Editing by hand or clearing the subpatch before saving can fix the patch, but it is not real solution.
The attached two patches show one patch with an empty subpatch (array-bug-empty.pd) and another one with an array of 21*21==441 elements, which I cannot open anymore.
Pd versions tested include 0.39.2 on Windows and current CVS on Linux, all show the same behaviour.
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1469910...
hi.
SourceForge.net wrote:
Initial Comment: Instances of data structure arrays that are saved in a patch can make that patch impossible to open again, if they are above a certain size. With attached patch, I can create and an array "cells" in the struct "ca" with up to 20 times 20 elements, 21 times 21 elements will give a message stack overflow on loading the patch.
Editing by hand or clearing the subpatch before saving can fix the patch, but it is not real solution.
The attached two patches show one patch with an empty subpatch (array-bug-empty.pd) and another one with an array of 21*21==441 elements, which I cannot open anymore.
Pd versions tested include 0.39.2 on Windows and current CVS on Linux, all show the same behaviour.
hmm, the array-bug-full.pd is very much the same as array-bug-empty.pd
anyhow, a quick workaround for this problem would be to rise the MSTACKSIZE (in m_binbuf.c:383) to a value that fits your needs. this however is no solution, as the problem will be just moved to some point further away.
on the long run, we should try to not have a MSTACKSIZE at all but rather detect the size needed at runtime. (i have no idea though, which speed penalty this means)
mfg.asd.r IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
hmm, the array-bug-full.pd is very much the same as array-bug-empty.pd
Hm, I cannot try this, because SF is down for maintainance (grrrrr...), but both are supposed to be the same patch, however one should have been the patch saved with a big array in [pd grid], the other should have an empty [pd grid].
anyhow, a quick workaround for this problem would be to rise the MSTACKSIZE (in m_binbuf.c:383) to a value that fits your needs. this however is no solution, as the problem will be just moved to some point further away.
Well, for now I can also delete the contents of the subpatch before saving as a workaround, however I don't understand, why I am able to create such an array when Pd is running, save the patch, but then the same array will make Pd refuse to reopen the patch again.
Pd should at least be able to load everything that it can create and save.
Ciao
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
hmm, the array-bug-full.pd is very much the same as array-bug-empty.pd
Hm, I cannot try this, because SF is down for maintainance (grrrrr...), but both are supposed to be the same patch, however one should have been the patch saved with a big array in [pd grid], the other should have an empty [pd grid].
Okay, SF is back, I replaced array-bug-full.pd with a really full Pd patch.
Ciao
On Tue, 18 Apr 2006, IOhannes m zmoelnig wrote:
on the long run, we should try to not have a MSTACKSIZE at all but rather detect the size needed at runtime. (i have no idea though, which speed penalty this means)
How do you detect how much stack space you need while still preventing pd from crashing from infinite recursion?
I don't know many systems that recurse through large linked-lists. Either they don't use linked-lists anymore, and/or they use higher-order functions, and/or they use tail-recursion.
why should recursion be used here?
but at least MSTACKSIZE could be replaced by a commandline option.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
Frank Barknecht -
IOhannes m zmoelnig -
Mathieu Bouchard -
SourceForge.net