Segmentation Fault ??

[Paul McKenzie]

the application fails at some point when i compile it in gcc (linux) but works just fine with the VC compiler on windows (based on a 24 hour runtime) so debugging all this has become a real pain in the arse as i have to wait at least 24 hours for it to ''crash'' with that segmentation fault.

That is the issue with multithreaded programs. If you have a threading issue, you may never have it come up when you compile with one compiler as opposed to another. You can't even predict if you change compiler settings in Visual C++, the error won't shows up. As a matter of fact, even if it isn't a threading issue, you shouldn't be fooled into thinking your program is OK if it runs on a compiler but fails to run with another compiler. That other compiler where it is not working is giving you the red flag that your program has a bug and you need to fix it.

And as I stated earlier, any corruption bugs leads to undefined behaviour. This means the application may seem to work, but as soon as you change compiler options, or add/remove code, or use another version or brand of compiler, or you run the program on a different machine, all sorts of "weird" bugs could crop up at runtime (I put "weird" in quotes, since as I stated, there are no weird bugs in C++, unless the compiler itself is producing broken code, and the possibility of that happening is fairly remote).

just wondered if anyone experienced the same annoying problem.

Yes, it's called "debugging multithreaded programs". Again, any issue with threading will occur at random times, times that you cannot predict. Every programmer who has worked with multithreaded programs has encountered this issue.

I use multiple threads for mysql operations such as inserting rows, updating rows, deleting rows etc. i am aware of synchronization methods such as mutexes. i use boost::thread mutexes.
but i'm keeping my code clean of object sharing because mutexes with mysql can lead to really bad performance (tested before)

You never mentioned anything about racing conditions, reentrancy, etc. Just because you used synchronization objects doesn't mean you used them correctly.

Proper usage of synchronization objects, and the usage of the correct synchronization objects is not a trivial topic. When you write the code, you have to identify before even running the program where the potential problems may exist.

Just to let you know, in the industry, if a company uses multithreading heavily, they will not hire a programmer if they have little to no experience in multithreaded applications, regardless of how much C++ they've done, 2 years or 20 years. A 24-hour wait time before a crash is generated would be considered unacceptable -- you need to identify in the code all of the issues that could occur, and then write the proper code to overcome these issues. If you missed anything, then you go through the code again and attempt to see what parts of the code are using the corrupted variable(s) and identify what could cause the corruption.

Regards,

Paul McKenzie