From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA00149; Sun, 13 Oct 2002 22:02:13 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA00599 for ; Sun, 13 Oct 2002 22:02:12 +0200 (MET DST) Received: from jhuml4.jhu.edu (jhuml4.jhu.edu [128.220.2.67]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g9DK2BD10034 for ; Sun, 13 Oct 2002 22:02:11 +0200 (MET DST) Received: from jhuml4.jhu.edu (jhuml4.jhu.edu [128.220.2.67]) by jhuml4.jhu.edu (PMDF V6.1 #47563) with SMTP id <0H3X002SARNM6X@jhuml4.jhu.edu> for caml-list@inria.fr; Sun, 13 Oct 2002 16:02:10 -0400 (EDT) Received: from jhuml4.jhu.edu ([128.220.2.67]) by jhuml4.jhu.edu (NAVGW 2.5.1.18) with SMTP id M2002101316020929774 for ; Sun, 13 Oct 2002 16:02:09 -0400 Received: from jhu.edu (goedel.cog.jhu.edu [128.220.29.8]) by jhuml4.jhu.edu (PMDF V6.1 #47563) with ESMTP id <0H3X002S7RNM6X@jhuml4.jhu.edu> for caml-list@inria.fr; Sun, 13 Oct 2002 16:02:10 -0400 (EDT) Date: Sun, 13 Oct 2002 16:02:09 -0400 From: John Hale Subject: [Caml-list] the same signal handling problem on powerpc To: caml-list@inria.fr Message-id: MIME-version: 1.0 (Apple Message framework v546) X-Mailer: Apple Mail (2.546) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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