From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: Running a ia32 compiled program on x86_64 (EMT64); when one thread continually signals another the FS register value appears to be modified in the resulting sigcontext, e.g. Main thread: while (1) { pthread_kill(testThread, mySignal); } Test Thread: mySigHandler(int sig, siginfo_t *sip, void *arg) { if ( (scp->fs != myFs) || (scp->fs != getFS()) ) doesntMatchCrash(); } Will attach repro, case. It appears that a few fprintf statements between signalling prevent the problem, but if I just spin and signal FS appears as 3 in the sigcontext instead of the original 0. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Start a test thread, records the FS value, and spins doing user code 2. Continuously signal the test thread 3. The FS register appears to change when handling the signal. Test program: gcc -g -Wall -lpthread -o fsmt fsmt.c && ./fsmt Actual Results: Starting FS: 0 Now hit me with: 10 Main signaling 1st Main signaling 2nd Main signaling looping forever Aborted (core dumped) Expected Results: Show loop forever Additional info: uname: 2.6.9-1.906_ELsmp #1 SMP Sun Dec 12 23:05:02 EST 2004 x86_64 x86_64 x86_64 GNU/Linux rpm -q --queryformat '\n%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' glibc: glibc-2.3.4-2.i686 glibc-2.3.4-2.x86_64
Created attachment 110640 [details] repro case Compile on ia32 and run on x86_64
I see the bug. I'll pursue it upstream. Aside from the contrived test case, I don't know of something concrete (and valid) actually broken by this.
So the originally we were out to repro a problem with an invalid FS reg after handling an async signal...this was as close as I could get so far. Was interested in other possible side-effects that may explain some other crashes we've experienced with IA32 code on x86_64.
I don't think the bug shown by your test program could be the source of any real-world problem. It only affects selectors that you cannot use without getting a GP fault. The only way a user program could be affected is if it explicitly compares the segment register values rather than trying to use them, like your test program does. The bug turns the selector 0 into 3, but both have the same effect if you use them (to fault). If the %fs value before the signal was a valid segment selector, then I don't see how signal handling would change it (unless of course your handler clobbered that word in the struct sigcontext on the stack). If you think there may be a real problem here, then please try to work up a test case that uses a nonzero %fs value and demonstrates some erroneous behavior.
Sorry for the late reply, I agree this isn't "real-world problem" - go ahead and close this. If FS is intialized, all is well. Was thinking this could have been related to another problem with a bad CS register, but upon further inspection, I very much doubt it.