Thu 12 May 2005 05:27:21 AM UTC, original submission:
Since kernel 2.6.x using POSIX threads, I had a problem in my app, that some (not all!) threads stopped running and no updates were made in X.
I found out that the problem is in glib, when using debian kernel 2.6.x.
The problem is in
pthread_cond_timedwait
( pthread_cond_t, pthread_mutex_t, timespec).
Found something in google:
http://groups.google.de/group/linux.debian.bugs.dist/browse_thread/thread/88a605ece1942c94/7639d49e47f532b8?q=pthread_cond_timedwait+mutex+kernel+2.6.&rnum=2&hl=de#7639d49e47f532b8
The problem is, that when the timespec is in the past, the condition is detroyed or something.
This causes the next time to wait for the mutex, that the wait does not return and the thread hangs infinite.
We tested it with 5 pc or laptops and found, that the bug must have something todo with APM or IntelSpeedStep or else.
Sometimes it works, sometimes not.
I've added a small c testprogram bug.c (next post).
Try this: gcc -pthread -Wall -O2 -std=c99 bug.c -o bug
If U run bug, it can be that it runs well for more then one day, but it can happen that it stops running after a few seconds.
If it runs, stop it, run again. It will hang.
I dunno exact how to reproduce the hang.
Now my patch in pnet: pt_defs.c
_ILCondVarTimedWait(_ILCondVar cond, _ILCondMutex mutex, ILUInt32 ms)
sometimes is called with ms = 0.
so if we get gettimeofday and pass this to pthread_cond_timedwait with adding 0 ms, it might be, that the timespec is in the past. So we got the problem.
My patch:
if ms == 0 I added 100 micro seconds to the timespec to wait -> no problem any more. See brubbel-050512.patch.
This does not slowup pnet. Please confirm that.
I would like that the patch will be checked in cvs, maybe with some switches to disable, but enabled as default.
Can someone do this?
Many thx.
Brubbel
|