Home/ Questions/Q 7847909
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T18:02:32+00:00

I apologise for posting a question that has been asked many times (I’ve just

  • 0

I apologise for posting a question that has been asked many times (I’ve just read 10 pages of them) but I can’t find a solution.

I’m working on a multi-threaded graphic/audio program using OpenGL and Portaudio respectively. The audio thread uses a library I’m making for audio processing objects. The SIGSEGV happens maybe 20% of the time (much less when debugging) and happens when resetting loads of audio objects with new stream information (sample rate, vector size etc). Code::blocks Debugger states the fault as originating from different places each time the fault happens.

This is the audio processing loop:

while(true){
    stream->tick();
    menuAudio.tick();
    {
        boost::mutex::scoped_lock lock(*mutex);
        if(channel->AuSwitch.resetAudio){
            uStreamInfo newStream(channel->AuSwitch.newSrate, 
                 channel->AuSwitch.newVSize, channel->AuSwitch.newChans);
            menuAudio.resetStream(&newStream);
            (*stream) = newStream;
            menuAudio.resetStream(stream);
            channel->AuSwitch.resetAudio = false;
        }
    }
}

It checks information from the graphics thread telling it to reset the audio and runs the resetStream function of the patch object, which is basically a vector for audio objects and runs each of them:

void uPatch::resetStream(uStreamInfo* newStream)
{
    for(unsigned i = 0; i < numObjects; ++i){
/*This is where it reports this error: Program received signal SIGSEGV,  
Segmentation fault. Variables: i = 38, numObjects = 43 */
        objects[i]->resetStream(newStream); 
    }
}

Sometimes it states the SIGSEGV as originating from different locations, but due to the rarity of it faulting when run with the debugger this is the only one I could get to happen.

As there are so many objects, I won’t post all of their reset code, but as an example:

void uSamplerBuffer::resetStream(uStreamInfo* newStream)
{
    audio.set(newStream, false);
    control.set(newStream, true);
    stream = newStream;
    incr = (double)buffer->sampleRate / (double)stream->sampleRate;
    index = 0;
}

Where the audio.set code is:

void uVector::set(uStreamInfo* newStream, bool controlVector)
{
    if(vector != NULL){
        for(unsigned i = 0; i < stream->channels; ++i)
            delete[] vector[i];
        delete vector;
    }
    if(controlVector)
        channels = 1;
    else
        channels = newStream->channels;
    vector = new float*[channels];
    for(unsigned i = 0; i < channels; ++i)
        vector[i] = new float[newStream->vectorSize];
    stream = newStream;
    this->flush();
}

My best guess would be that it’s a stack overflow issue, as it only really happens with a large number of objects, and they each run fine individually. That said, the audio stream itself runs fine and is run in a similar way. Also the loop of objects[i]->resetStream(newStream); should pop the stack after each member function, so I can’t see why it would SIGSEGV.

Any observations/recommendations?

EDIT:

It was an incorrectly deleted memory issue. Application Verifier made it fault at the point of the error instead of the occasional faults identified as stemming from other locations. The problem was in the uVector stream setting function, as the intention of the class is for audio vectors using multidimensional arrays using stream->channels, with the option of using single dimensional arrays for control signals. When deleting to reallocate the memory I accidentally set all uVectors regardless of type to delete using stream-> channels. 

if(vector != NULL){
    for(unsigned i = 0; i < stream->channels; ++i)
        delete[] vector[i];
    delete vector;
}

Where it should have been:

if(vector != NULL){
    for(unsigned i = 0; i < this->channels; ++i)
        delete[] vector[i];
    delete vector;
}

So it was deleting memory it shouldn’t have access to, which corrupted the heap. I’m amazed the segfault didn’t happen more regularly though, as that seems like a serious issue.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I you can spare the memory, you can try a tool like Electric Fence (or DUMA, its child) to see if it’s an out of bound write that you perform.
    Usually these types of segfaults (non-permanent, only occurring sometimes) are relics of a previous buffer overflow somewhere.

    You could try Valgrind also, which will have the same effect as the 2 tools above, to the cost of a slower execution.

    Also, try to check what’s the value of the bad address you’re accessing when this happens: is it looking valid? Sometimes a value can be very informative on the bug you’re encountering (typically: trying to access memory at 0x12 where 0X12 is the counter in a loop :)).

    For stack overflows… I’d suggest trying to increase the stack size of the incriminated thread, see if the bug is reproduced. If not after a good bunch of tries, you’ve found the problem.

    As for windows:

    • 0