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]
