Csound Csound-dev Csound-tekno Search About

[Cs-dev] Serious problem in csoundFTAlloc

Date2008-11-29 11:57
Fromjpff
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

Date2008-11-29 13:47
FromRichard Dobson
SubjectRe: [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