Stefan Hundhammer wrote:
A common mistake is to release objects too soon. I don't know any more details about your project, but that one happened to me lately, too:
My application is a multi-threaded SMTP-proxy written in C. One thing it does is call clamav to scan emails for virus.
Just to give you an example of how the application can easily mess up its own stack with that kind of thing. ;-)
Yep, got it. Does anyone have suggestions as to how to trap a stack corruption? I'm almost certainly asking a naive question - I'm not quite familiar with debugging C on Intel (my normal hunting grounds are assembler on S390). I'm thinking of maintaining a couple flags/checksum(ish) variable at each start/end of a stack, and then checking those at entry/exit? Does anything exist that will assist me doing this? (this method was been very successful in catching corruptions in both CICS and TPF). The error I'm chasing seems highly intermittent - I can process 100.000s of emails (sample of 1014 emails repeated in multiple threads) over 24+ hours with no problem, but also trigger it within 30mins of starting a test. /Per Jessen, Zürich