Albeit the clear lack of interest  , I will update on my current results:
I performed the following:
in ssl.c/wolfSSL_new(WOLFSSL_CTX* ctx) I change:

ssl=(WOLFSSL*)XMALLOC(size(WOLFSSL),ctx->heap,DYNAMIC_TYPE_SSL)

with

ssl=(WOLFSSL*)malloc(sizeof(WOLFSSL))

this - for some reason, appears to have solved the issue.

anyone cares to shed some light on XMALLOC's operation?

i'm buffled...

thanks,
Dan

Hey all,
Just to be clear - If there is any sort of memory pooling, I would appreciate it if you could let me know...

thanks ,
Dan

thanks for your reply - however, I already solved the problem and suggest you patch it if possible:
while the session table is thread safe, the usage of ssl_decodePacket isn't thread safe, even if the the same session is always treated by the same thread:
note that whenever ssl_decodePacket is called, if syn is encountered the "CreateSession" method is invoked, which in turn calls RemoveStaleSessions. there, "old" sessions are removed, but no one makes sure that another thread is not currently using these "old" sessions. the bug is that currently used sessions are considered "old". this can be easily fixed by adding the following (one) line to the "GetSnifferSession" method in "sniffer.c" after the session is pointer is acquired and verified as non-null:

static SnifferSession* GetSnifferSession(...){
    ...
    while(session){ //obtaining the session according to ipInfo tcpInfo passed to the function
    }
    unlock(&SessionMutex);
    if(session){ //checking if a session was actually found
       .... 
       session->bornOn = time(NULL); ///******* new code ! *********// <--------------------
    }
}

this patch allows multithreaded use of ssl_decodePacket (assuming of course session-wise load balancing between the threads), and will not cause thread X to free a session thread Y is currently working on.
in addition, this also fixes a functionality problem (as I see it...), you don't really want to throw away a session SNIFFER_TIMEOUT seconds from arrival time, but only if the session was silent for SNIFFER_TIMEOUT.

what do you think?

regards,
Dan

Hey Chris,
thanks for responding and sorry for my late reply.

I didn't explain myself vividly enough. I am not modifying anything: I posted the values of the relevant variables as they were extracted from the dump (.core) file. Although the value of expected = session->srvExpected was extracted from the core file as being 1461, I specified that in order to truly reconstruct the path flow of the program, one should use expected = session->srvExpected = 4389. the reason for that being that the .core file gives the last "image" of the memory stack, and the value of session->srvExpected is modified (in the original code!) by adding to it the value of *sslBytes. since we are actually looking to trace back to the events that originally led to the value of sslBytes being negative, we should not use the values from core file effected by this undesired situation, but rather try to understand what were the values which lead to that situation. therefore, since session->srvExpected is modified AFTER sslBytes is obtained, the core file value for session->srvExpected is not relevant, we should try and conclude what was the value before hand (since it effects the flow of the program). due to the change being session->srvExpected += sslBytes, and sslBytes in the core file is -2928, I simply noted that one should use with session->srvExpected + 2928 in order to trace back what lead to sslBytes being negative.

to sum this: you can simply try and trace the code given the variable values I listed above with expected = session->srvExpected = 4389 and I am sure you will see the problem I encountered.

I monitor my own server and prefer to do so passively (less intrusive to the application). the crushes I suffer occur rarely, but I imagine that since I use it continuously, even the less probable session values occur.

so, are you sure

*sslBytes -= newEnd - reassemblyList->begin;

is necessary? it appears to me that even when removing it should still work (in fact, I tried it and it does work on my various examples). However, I am concerned that maybe it is necessary and I will now mess up a different session scenario.

thanks for your attention,

Dan

Hey,
sry for the late reply.
I am using the sniffer application in order to monitor one of my servers for personal use. since I am using it rather constantly, I am encountering some of these errors.

thanks,
Dan

Thanks for your reply.
I saw the "rollover" part in the code, I agree that a connection of more than 4Gb would cause the error I witnessed. However I am pretty sure that wasn't my case (it happened quite quickly after I run the application, no time for 4Gb to accumulate).
If I understand correctly - the rollover handling that takes place only addresses the situation where the current packet's sequence has rolled over and therefore is much smaller than the *expected sequence number* - in which case "real" is adjusted. however, what if the following scenario takes place:
the expected sequence number is close to 2^32, a packet with that SN arrives and this packets "ends" after 2^32. I believe a packet of this sort will raise the assert call in CreateBuffer, or worse (in Release mode), will cause a seg fault due to the later execution  of memcpy with a negative size_t value of [end-*begin] (which is negative, as the packet starts at around 2^32 and ends not far from 0).

does this make sense to you?

I hope I understood the code correctly.

thanks for your attention,

regards,
DanC

testing on my part shows that adding the mentioned code solves this particular seg fault which resulted in release mode (the assert wasn't active and thus a later memcpy used the *negative* $added value as param of type size_t to memcpy ---> seg fault).

1. i am still not sure of the +1 at the end of the expression there
2. while not yet sure, it might be that this fix alone is not complete, for now it appears to have solve this particular seg fault

DanC