Crash on load with fl.frommax~

Issue #54 resolved
Owen Green created an issue

See the attached patch. If one builds this simple network, triggering frommax with audiotrigger, all is well. Likewise if one reconnects the audiotrigger before turning audio on. However, launching patch and turning audio on causes a crash. Perhaps the thing that finishes making connections when audio is first turned on hasn't finished?

Comments (11)

  1. Alex Harker repo owner

    It turns out I can't program in C++, otherwise this wouldn't have happened. Can you pull, build and test again?

  2. Owen Green reporter

    Not being able to program C++ must be making this project really hard.

    Yup, seems happy now.

  3. Alex Harker repo owner

    I like a good challenge, but yes it doesn't help much.

    In the end I had changed the code with the assumption that I was passing a pointer by reference to swap, but that is too finicky for me, so I altered it to explicitly return and overwrite the swapped pointer - so now the meaning should be clearer when reading. The FromHost object is pretty complex, because it is dealing with memory management and threading and nobody likes either of those things.

  4. Owen Green reporter
    • changed status to open

    I now get a crash if frommax~ hasn't had input before its first trigger <pre><code> ----------begin_max5_patcher---------- 283.3ocwQsraCCBD7L7Uf3raT7iDW0ekpnJr8lVRwfEfScTT52dgE69HM25g dYQ6ryN6NKmoDdiYBbb1CrGYDxYJgfPQ.xbNg2KlZUBGRiqg2LMG3YoRdXxi v6UqF.aixz956KEkcXo.861rfoG6MidE3Q0xmQc9SJ.IuvKQxeZ.RKGmy18k DR80JLH7suH0O+jEZ8oVJx2tZcFKupL9TWDiEgHaWrkKTZLj8ms8dqoOP8Vt t7+v0atGMZx70U2z0npbkTe8eOJXD+mmBmYz1trSy+mr0etacfyK0Buzn+Fm xDmeMVwvvQv5lIiiHbqOXrwz5LLUpSokXpENJW3WgHBav29foGsoK3z1JdpU SGX0iR7LQiS9B8C.nNWqBC -----------end_max5_patcher----------- </code></pre>

  5. Owen Green reporter

    Trouble seems to be here, in FromHost::process()

    requestOutputSize(0, mVectorFrame ? mVectorFrame->size(): 0);
     allocateOutputs();       
     double *output = getOutput(0, &size);
    

    insofar as if mVectorFrame is null, then it goes ahead and tries to allocate 0 bytes of memory. Maybe just bailing instead would be the thing?

  6. Owen Green reporter

    Though I see bailing would create ugliness with releasing the lock. Would seem more elegant if there was something RAIIish - would using SpinLockHolder in process() bring too much overhead?

  7. Alex Harker repo owner

    Right pointer, wrong problem. Allocating zero size outputs is totally valid, as is copying an output with no size and a NULL point. Referencing a vector pointer that is NULL is not. Please pull and check again.

  8. Log in to comment