How would you tackle...?
If you've got a tough bug and would like inspiration or suggestions on how to tackle it, reach out for help here.
- 3 Topics
- 2 Replies
I was asked to take a look at a failure of a test that I wrote many years ago. This failure was, as far as we could tell, new, but it didn’t look like a regression. The test was multi-threaded with asynchronous signals using setitimer() to fire SIGALRMs at it. It appeared to have completed successfully, but at the end it printed a “test succeeded” message which our test system was expecting to see, only it didn’t appear. Happily our test system had saved a recording of the debuggee. Turns out that the printf(“test succeeded”) had been interrupted by a SIGALRM and so returned -EINTR. Actually it was more complicated than that - the compiler had turned the printf() into a puts(), which returns zero if it fails. This took 10-20 mins of head scratching with the recording, a few minutes thinking I was looking at a libc bug, but it was pretty straightforward really. So my challenge is - how would you go about debugging that _without_ a recording?
Hi. I am working on a complex open-source project and I have a bug that occurs in about 2/3 of runs. There are at least 3 ways the problem expresses: segfault, map access out-of-range and another less common way. (So it could be more than one bug.) When the bug occurs there are usually 15-20 interacting threads running, some of which are state-machines.The problem is that when I run it under udb the problem never occurs. I’ve tried nearly 100 times.I’m looking for ideas to make the bug occur or at least increase the likelihood that the bug will occur under udb. Ideas? Any help is greatly appreciated!
Already have an account? Login
Login to the community
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.