Thanks, I believe the problem has been solved (at least 10 continuous hours thus far of streaming without any socket enomem error), very much so as a result of this forum and the 'heap corruption' comment, and as it turns out, nothing to do with socket recv.
If of any interest / use to anybody, the only part of the application looking out for system errors was the socket handling, thus naturally an ENOMEM would show up there - obvious likely to most but not to me, actually any part of the application could have been screwing up the memory long before the socket tried to read. I put in ENOMEM checks all over the application and waited for one to pop up. Essentially the problem came from the below code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
|
class Streamer
{
vector< vector<data> > DataStreams; // Data container for each stream
void RecvSocketData(); // Read once from socket and append any data to relevant stream
};
int main()
{
Streamer myStreamer;
vector< vector<data> > ProcessStreams;
// Init number of data and process streams
vector<data> Stream;
for(int num = 0; num < 10; num++)
{
myStreamer.DataStreams.push_back(Stream);
ProcessStreams.push_back(Stream);
}
for(;;)
{
// Update process streams from streamer
ProcessStreams = myStreamer.DataStreams;
// Get latest stream data
myStreamer.RecvSocketData();
// Do whatever to ProcessStreams
}
}
}
|
After a few hours, an ENOMEM was triggered after 'ProcessStreams = myStreamer.DataStreams'. I don't really know why, its sequential, no multiple access, no mutexing required, and it only caused an issue with the socket reading (simply because it was told to disconnect on ENOMEM). It seemingly did not effect the data containers, subsequent processing, storage, results, display, no noticeable memory leak, no segmentation, no crash, all I had to do was create a new socket, reconnect and it would carry on without issue until the next ENOMEM.
Anyways, thanks again, I learned quite a bit.