[Cs-dev] Serious problem in csoundFTAlloc
| Date | 2008-11-29 11:57 |
| From | jpff |
| Subject | [Cs-dev] Serious problem in csoundFTAlloc |
This is a follow upo to the problem some people have with the
contrapunctus example. The trouble is in Engine/fgens.c in
csoundFTAlloc.
In particular the lines
else if (len != (int) ftp->flen) {
if (csound->actanchor.nxtact != NULL) { /* & chk for danger */
csound->Warning(csound, Str("ftable %d relocating due to size change"
"\n currently active instruments "
"may find this disturbing"), tableNum);
}
csound->flist[tableNum] = NULL;
csound->Free(csound, ftp);
csound->flist[tableNum] = (FUNC*) csound->Malloc(csound, (size_t) size);
}
This destroys a table and creates a new one. If any other opcode is
running at that time the Free will lead to a dangling pointer.
At present I cannot think of a solution, good or otherwise! Best
might be to not free and so waste space. Anyone any other ideas?
==John ffitch
PS I have an e-mail problem at present so I cannot see csound or
csound-devel mailing lists until some engineering works are completed.
Please copy me in directly on any response
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net |
| Date | 2008-11-29 13:47 |
| From | Richard Dobson |
| Subject | Re: [Cs-dev] Serious problem in csoundFTAlloc |
Probably any solution robust in all cases (incl multiple threads etc) would incur a time penalty as well as a memory one. Presumably in the early days this was a calculated risk in the context of offline rendering. So perhaps raise the warning level to DEFCON 1: "ftable %d forced to relocate due to high-risk size change\n" "this will likely cause a warp-core breach or other critical malfunction\n" Perhaps table redefinitions were really meant to be used only between score sections, after all running instruments have completed? Disallowing ftable reallocations within a running section might be a reasonable compromise, unless of course there is some realtime piece out there that absolutely depends... Richard Dobson jpff wrote: > This is a follow upo to the problem some people have with the > contrapunctus example. The trouble is in Engine/fgens.c in > csoundFTAlloc. ... > This destroys a table and creates a new one. If any other opcode is > running at that time the Free will lead to a dangling pointer. > > At present I cannot think of a solution, good or otherwise! Best > might be to not free and so waste space. Anyone any other ideas? ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |