Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004541OCamlOCaml generalpublic2008-04-24 19:032010-04-20 17:46
Reporterjsk 
Assigned To 
PrioritynormalSeveritycrashReproducibilityalways
StatusclosedResolutionfixed 
Platformx86OSUbuntu LinuxOS Version7.10
Product Version3.10.2 
Target VersionFixed in Version3.12.0+dev 
Summary0004541: Crash when debugging a program that calls Unix.fork()
DescriptionWhen debugging a bytecode program that calls Unix.fork(), ocamlrun
and ocamldebug usually crash immediately after the fork operation.

1. Create a program called "test.ml", containing the following:

        let _ =
            Printf.printf "process %n starting\n" (Unix.getpid ());
            flush stdout;
            let _ = Unix.fork () in
            Printf.printf "process %n ending\n" (Unix.getpid ());

2. Compile the program:

        "ocamlc -custom -g unix.cma test.ml -o test.exe".

3. Start the debugger, specifying the location of "unix.ml" and an
    explicit socket:

        "ocamldebug -I <path-to-unix> -s <socket-name> test.exe"

4. Issue the following commands to ocamldebug:

        "set loadingmode manual"
        "goto 0"

5. Manually load the program (possibly on another machine):

        "CAML_DEBUG_SOCKET=<socket-name> ./test.exe"

6. Repeatedly issue the "step" command to ocamldebug.

At the point just after the call to Unix.fork(), ocamldebug usually
terminates with an error message of the form:

    (ocd) Garbage data from process <n>
    >> Fatal error: Debugcom.do_go
    Uncaught exception: Misc.Fatal_error

Ocamlrun usually also terminates itself at this point.

This appears to be happening because ocamldebug is receiving unexpected
data from ocamlrun, presumably because the forked ocamlrun processes are
competing with one another to send data along the same connection to
ocamldebug.

Occasionally, though, ocamldebug doesn't crash, but continues to report
data from both parent and child ocamlrun processes. Issuing further step
commands to ocamldebug causes the forked processes to repond in a round-
robin style. Presumably this is because the forked ocamlrun processes
are still competing with one another to read data from the same shared
connection to ocamlbug, and are picking up commands alternately, one
after the other.

The current behaviour is making it difficult for us to debug programs
that launch other processes using the traditional "fork-exec" sequence,
since debugged programs have a very good chance of crashing immediately
after they call Unix.fork().

I'm wondering, is it possible to make ocamlrun aware of Unix.fork(),
so that a child ocamlrun process doesn't attempt to communicate with
ocamldebug through the same socket as its parent process?

Thanks for your help

Jonathan
---
Jonathan Knowles
Citrix Systems Research & Development
TagsNo tags attached.
Attached Filespatch file icon fork.patch [^] (7,723 bytes) 2009-10-21 00:33 [Show Content]

- Relationships

-  Notes
(0005141)
bacam (reporter)
2009-10-21 00:32

I've been playing around with ocamldebug support for fork a bit, and I'll attach a patch shortly. It works by closing the connection to one of the processes, and it includes a gdb-like option to pick whether to follow the parent or child process. One small wart is that I've added a stub implementation of the debugging functions to the native code runtime; another option would be to build two versions of the unix library.

The patch was made against 3.11.1, but applies to the trunk version too.
(0005355)
doligez (administrator)
2010-04-20 17:32

I'm integrating the patch into the trunk. It will be in 3.12.0.

- Issue History
Date Modified Username Field Change
2008-04-24 19:03 jsk New Issue
2008-08-04 16:47 doligez Status new => acknowledged
2009-10-21 00:32 bacam Note Added: 0005141
2009-10-21 00:33 bacam File Added: fork.patch
2010-04-20 17:32 doligez Note Added: 0005355
2010-04-20 17:46 doligez Status acknowledged => closed
2010-04-20 17:46 doligez Resolution open => fixed
2010-04-20 17:46 doligez Fixed in Version => 3.12.0+dev


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker