[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pnet-developers] [patch #4010] Workaround Patch for bug in debian kerne
From: |
Heiko Weiss |
Subject: |
[Pnet-developers] [patch #4010] Workaround Patch for bug in debian kernel 2.6.x and glibc |
Date: |
Thu, 12 May 2005 05:27:22 +0000 |
User-agent: |
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) |
URL:
<http://savannah.gnu.org/patch/?func=detailitem&item_id=4010>
Summary: Workaround Patch for bug in debian kernel 2.6.x and
glibc
Project: DotGNU Portable.NET
Submitted by: brubbel
Submitted on: Don 12.05.2005 um 05:27
Category: None
Priority: 5 - Normal
Status: None
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
_______________________________________________________
Details:
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
_______________________________________________________
File Attachments:
-------------------------------------------------------
Date: Don 12.05.2005 um 05:27 Name: brubbel-050512.patch Size: 2,98KB By:
brubbel
patch in pnet
<http://savannah.gnu.org/patch/download.php?item_id=4010&item_file_id=4598>
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/patch/?func=detailitem&item_id=4010>
_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/
- [Pnet-developers] [patch #4010] Workaround Patch for bug in debian kernel 2.6.x and glibc,
Heiko Weiss <=