mlprof
Stephen Weeks
MLton@sourcelight.com
Wed, 21 Mar 2001 18:41:03 -0800 (PST)
> I've started in on fixing mlprof to work with the native backend. I don't
> forsee any problems with that, but I am getting strange behavior with
> executables compiled with mlton -p or mlton -p -g.
Here's what I've learned so far. I compiled logic.sml with -p and observed the
same errors as Matthew. Running with strace, I saw the following two system
calls made before the mlton generated code started running.
rt_sigaction(SIGPROF, {0x400e8790, ~[], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0
setitimer(ITIMER_PROF, {it_interval={0, 1}, it_value={0, 1}}, {it_interval={0, 0}, it_value={0, 0}}) = 0
During execution, I saw the following.
--- SIGPROF (Profiling timer expired) ---
sigreturn() = ? (mask now [])
The errors always happen after at least one SIGPROF.
To confirm that it is the SIGPROF stuff that is causing the problem, I prefixed
the following onto logic.sml and compiled -p.
local
open MLton
val t = Time.zeroTime
val _ = Itimer.set {which = Itimer.Prof,
value = t,
interval = t}
in
end
In this case, the following system call happens as soon as the code starts
running.
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
This eliminates the segfault.
Finally, to test whether it MLton's interaction with signals or the specific
signal handling that goes on with profiling, I prefixed logic.sml with the
following code and compiled without -p.
local
fun handler () = TextIO.output (TextIO.stdErr, "got a sigprof\n")
open MLton
structure Handler = Signal.Handler
val _ = Handler.set (Signal.prof, Handler.simple handler)
val t = Time.fromMicroseconds 1
val _ = Itimer.set {which = Itimer.Prof,
value = t,
interval = t}
in
end
With this prefix, the code works fine.
So, I think there is some bad interaction with the specific SIGPROF handling
stuff that is used by -p and code generated by the native backend (i.e. I agree
with Matthew). Signals by themselves seem to work fine.