caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: John Hale <hale@jhu.edu>
To: caml-list@inria.fr
Subject: [Caml-list] the same signal handling problem on powerpc
Date: Sun, 13 Oct 2002 16:02:09 -0400	[thread overview]
Message-ID: <A7BDC366-DEE6-11D6-A260-00039311FF84@jhu.edu> (raw)

Let me first say how much fun programming in Caml is.

Having said that, I believe I'm experiencing the same signal handling 
problem Winfried Dreckmann brought up
http://caml.inria.fr/archives/200206/msg00039.html

Namely, I have a program that uses signals, works fine in bytecode, but 
crashes with "bus error"
in native code. i can't reproduce the problem with a small subpart. 
FWIW, my program doesn't use the C interface.
It crashes whether I use an interval timer or Unix.alarm, regardless of 
the timer being virtual or real.
Also, one alarm works fine, it's always receipt of the second alarm 
that causes a bad access at the signal handler.

This is with ocaml-3.06 on Mac OS X 10.2.1, PowerPC.  The problem goes 
away on Linux running on intel.

Here is a small example that exemplifies the kind of signal handling 
going on in the [larger] malfunctioning
program -- but *it itself does not crash*.  The key idea is that I'd 
like the mutable variable "measured_lately"
to be updated by the signal handler so that when the function "dostuff" 
checks it, it properly reflects delivery of
an alarm signal. That should be doable by either re-requesting 
Unix.alarm each time a SIGALRM is handled,
or with a self-reloading interval timer.

Since Winfried's problem was also on PowerPC (but with linux) I'm 
guessing there is something about
the specialization to PowerPC that has gone awry. anybody else 
experiencing this?

-john

> let rec dostuff measured_lately i =
>       if i=0 then () else (Unix.sleep (Random.int 10);
> 			   if (not !measured_lately) then
> 			     begin
> 			       print_string ((string_of_int i)^"\n");
> 			       flush stdout;
> 			       measured_lately := true;
> 			       dostuff measured_lately (i-1)
> 			     end
> 			   else dostuff measured_lately (i-1))
>
> let alarming_bug () =
>   begin
>     let measured_lately = ref true in
>     Sys.set_signal Sys.sigalrm (Sys.Signal_handle
> 				  (function x -> if x = Sys.sigalrm
> 				  then (measured_lately := false;
> 				    ignore (Unix.alarm 5)) else ()));
>     ignore (Unix.alarm 5);
>     dostuff measured_lately 3;
>     ignore (Unix.alarm 0)
>   end;;
>
> List.iter alarming_bug [();()];;

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


             reply	other threads:[~2002-10-13 20:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-13 20:02 John Hale [this message]
2002-10-13 21:37 ` Damien Doligez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=A7BDC366-DEE6-11D6-A260-00039311FF84@jhu.edu \
    --to=hale@jhu.edu \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).