Re: oprofiled getting SIGBUS on read from /dev/oprofile/buffer...

[David D. <dd...@av...>]

David Daney wrote:
> I am running linux 2.6.14-rc2 (from linux-mips.org) on a 32 bit MIPS CPU 
> (ATI Xilleon).  This CPU has no performance counters so the oprofile 
> driver is running in the "timer" mode (i.e. kernel boot messages report 
> "oprofile: using timer interrupt.")
> 
> Since my CPU was not currently supported by the kernel I did a very 
> small amount of hacking so that it would return -ENODEV from 
> oprofile_arch_init() and fall back to the timer mode.
> 
> I am happy to report that I had very little trouble cross compiling the 
> oprofile user space programs (from oprofile-0.9.1).
> 
> My problem comes when trying to run the profiler.  I am hoping that 
> someone can help me shed a little light on this problem.
> 
> I successfully do:
> 
> # opcontrol --init
> # opcontrol --start-daemon
> 
> The log file reports:
> # cat /var/lib/oprofile/oprofiled.log
> oprofiled started Fri Dec 31 21:48:39 1999
> kernel pointer size: 4
> 
> Then when I do:
> # opcontrol --start
> 
> oprofiled gets SIGBUS.
> 
> I have attached both strace and gbd to the running oprofiled, and it 
> seems to be blocked in a read from /dev/oprofile/buffer until I run 
> opcontrol --start then it gets SIGBUS (seemingly without returning from 
> the read.
> 
> The parameters passed to the read seem reasonable (i.e. the buffer is 
> entirly contained in memory that is mapped into the oprofiled address 
> space and 8 byte aligned)
> 
> Any Ideas about what might cause this?

Well just to follow up on this, I found the problem.  I would like to 
apologize for blaming oprofile.

It turns out that my bash has a bug in it so that the command 'kill -s 
USR1 pid' ends up sending SIGBUS to the target process.  I expect that 
after I fix bash, that it will work as expected.

David Daney.