tags 499142 + patch thanks To correct an earlier comment, gcj _is_ using threads.
The cause of this bug appears to be a race condition in send_get_fakem(). When crafting messages, we stuff a serial number and pid into the message to ensure uniqueness. In the case of threads, our pids will be the same, so that doesn't really help us - we must rely on the serial number. Unfortunately, we didn't protect access to the static (and therefore shared) serial variable with our semaphore, resulting in this scenario: THREAD A THREAD B ------------------------------------- serial++ buf->serial=serial lock() serial++ lock() recvmsg() serial != buf->serial Solution is to grab the semaphore before incrementing serial. Thanks to Troy Heber for helping me work through this one. diff -urpN fakeroot-1.10.1.orig/communicate.c fakeroot-1.10.1/communicate.c --- fakeroot-1.10.1.orig/communicate.c 2008-08-03 16:26:49.000000000 -0600 +++ fakeroot-1.10.1/communicate.c 2008-11-18 15:10:24.000000000 -0700 @@ -521,9 +521,9 @@ void send_get_fakem(struct fake_msg *buf if(init_get_msg()!=-1){ pid=getpid(); + semaphore_up(); serial++; buf->serial=serial; - semaphore_up(); buf->pid=pid; send_fakem(buf); -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]