Re: Writing a unittest against thread (un)safe ref-counter pointer
- From: Marcel Müller <news.5.maazl@xxxxxxxxxxxxxxx>
- Date: Thu, 27 Dec 2007 13:28:28 +0100
Hi!
Henrik Goldman schrieb:
Recently I had a bug report on our software which lead to 14 days of frustrations before the bug was discovered.
It turned out to be a thread (un)safe ref-counter pointer which would eventually do a double-delete.
So as a programmer I wanted to reproduce this problem as a unit-test to avoid these kind of situations in future.
However it turned out to be harder than imagined.
In a simplistic scenario I simply cannot reproduce it anymore.
There is no way to create test cases that are guaranteed to fail on undefined behaviour. It's in the nature of undefined behaviour that it may /not/ fail too.
However, as Dmitriy said, there are mostly ways to increase the probability of the fail case. But as long as they are intrusive (as in the example), they won't help you much.
In this case creating some tenths of threads which randomly create, copy and discard references in a common array of references for a while will maybe do the job. If your memory is clean afterwards and the program did not crash it is likely that your reference counter is clean.
In your case two thread switches have to occur close together, because once m_p is NULL the second delete turns into a no-op. So more helpfull than a test case is maybe a debug build that checks m_p for to be not NULL before the delete (if this is a valid assumption in your case).
In fact, I would not create a test case for exactly this problem at all now, because it is really unlikely that exactly this happens again.
I have not found anything better than experience and much care for now to avoid synchronization issues in core libraries of mutli-threaded applications. Test cases like the above can contribute, but they will only check for some faults and are expensive to build. Another method is a code review of a second (experienced) programmer that is only marginally involved in the project. I find almost everytime some potential synchronization issues in code at such reviews. Even in code that is productive since years.
A clean code desing that decouples synchronization and resource management as far as possible form the application logic is helpful too. If the critical parts are in a view small but heavy used classes, bugs are more likely to be found soon. Using tested implementations like the boost libraries are good advises too. Documenting the thread-safety of each class (and sometimes method) is required too. Debug builds might use assertions to check for some of these requirements.
Marcel
.
- References:
- Writing a unittest against thread (un)safe ref-counter pointer
- From: Henrik Goldman
- Writing a unittest against thread (un)safe ref-counter pointer
- Prev by Date: Re: CSingleLock
- Next by Date: Re: CSingleLock
- Previous by thread: Re: Writing a unittest against thread (un)safe ref-counter pointer
- Next by thread: Re: Writing a unittest against thread (un)safe ref-counter pointer
- Index(es):
Relevant Pages
|
