patchDotGNU Portable.NET - Patches: patch #4010, Workaround Patch for bug in debian...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #4010: Workaround Patch for bug in debian kernel 2.6.x and glibc

Submitter:  Heiko Weiss <brubbel>
Submitted:  Thu 12 May 2005 05:27:21 AM UTC
   
 
Category:  None Priority:  5 - Normal
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open

Mon 30 May 2005 06:12:31 AM UTC, comment #3: 


Could someone please check in the patch?

Heiko Weiss <brubbel>
Group Member
Thu 12 May 2005 07:51:35 AM UTC, comment #2: 


Damn.
App hangs again after running 2 days.
Maybe timeout to small.
Increased timeout from 100 ys to 500 ys.

Give it a try ...


Heiko Weiss <brubbel>
Group Member
Thu 12 May 2005 05:28:27 AM UTC, comment #1: 

small test bug.c
gcc -pthread -Wall -O2 -std=c99    bug.c   -o bug

Heiko Weiss <brubbel>
Group Member
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



Heiko Weiss <brubbel>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #8828:  brubbel-050512.patch added by brubbel (3KiB - application/octet-stream)
file #8827:  bug.c added by brubbel (976B - application/octet-stream - bugtest)
file #8826:  brubbel-050512.patch added by brubbel (3KiB - application/octet-stream - patch in pnet)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 3 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-05-12 brubbel Attached File- Added brubbel-050512.patch, #4600
2005-05-12 brubbel Attached File- Added bug.c, #4599
2005-05-12 brubbel Attached File- Added brubbel-050512.patch, #4598

Back to the top

Powered by Savane 3.13-f8d8.
Corresponding source code