|
First a correction. My test
program does terminate with a bus error on receiving signal USR1. Just in case anyone
is interested - It turned out that the BUS error results from the fact that
when coreutils was built, it used the signal numbers from the devel machine
(x86). These numbers are different from our mips kernel on which we want to use
oprofile (mips has slightly different signal numbers from x86). Many thanks to
David Daney for drawing my attention to this. Cheers, Ani From:
linux-mips-bounce@xxxxxxxxxxxxxx [mailto:linux-mips-bounce@xxxxxxxxxxxxxx] On
Behalf Of Anirban Sinha Hi: I have been trying to hunt down this bug for several days
now. What mainly happens is that when oprofiled wakes up from read() in
/dev/oprofile/buffer on receiving a signal USR1 (i.e, when someone does
opcontrol –start after doing opcontrol—start-daemon), it somehow
gets SIGBUS within glibc read(). We are using a mips machine with Sybyte
SB1 processor. On intel, this error does not show up. Interestingly, when I
tried running a small test program that simply reads /dev/oprofile/buffer, the
error can’t be reproduced! Ralf and others, any insights, suggestions or useful
comments from experience will be really really appreciated. I am spending a lot
of time trying to fix this bug. Cheers, Ani |
