RE: [Caml-list] ocaml sefault in bytecode: unanswered questions

["ivan chollet" <ivan.chollet@free.fr>]

Cedric,

I use the Unix library, can it cause segfaults also? (If yes, I would expect
the ocaml bytecode runtime system to produce a nice stacktrace though)
That's the only library I use, the rest of the code fits into the OCaml core
category and also some use of the Standard modules.
FYI, Marshal can definitely produce segfault, therefore my question was:
apart from the Marshal module, what can produce segfaults?

You basically state that stuff like “let l = !myref in List.iter myfun l”
(where myfun modifies !myref) wouldn't produce segfault. 
Why? It would mean that doing "let l = !myref" creates a brand new OCaml
entity, l, ie a brand new allocation on the heap, and then, messing around
with !myref inside myfun would be of course 100% safe. Is that what OCaml
runtime does?

Nevertheless, I don’t like OCaml runtime producing segfaults. What makes the
debugging process - and therefore the development process - deterministic is
precisely the ability to get the cause of every compile time/runtime error.
OCaml is pretty good at compile time and no doubt the typechecking feature
is useful. In an ideal world, OCaml should also classify runtime errors
nicely or throw nice stacktraces. I guess that was at least the original
design goal of the OCaml team but I may be wrong.

Ivan




-----Original Message-----
From: Cedric Auger [mailto:Cedric.Auger@lri.fr] 
Sent: vendredi 7 août 2009 20:20
To: ivan chollet
Subject: Re: [Caml-list] ocaml sefault in bytecode: unanswered questions

ivan chollet a écrit :
>
> Hello guys,
>
> I would like to ask a question about ocaml error handling. Actually 
> many questions that I’ve never dared asking on the official mailing 
> list. I’ve had a few problems sparsely with OCaml bytecode programs 
> throwing a core dump. When analyzing these core dumps, gdb says it’s a 
> “Segmentation fault”. Here is an example of this:
>
> This GDB was configured as "i386-marcel-freebsd"...(no debugging 
> symbols found)...
>
> Core was generated by `ocamlrun'.
>
> Program terminated with signal 11, Segmentation fault.
>
> Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.
>
> Loaded symbols for /lib/libm.so.5
>
> Reading symbols from /lib/libncurses.so.7...(no debugging symbols 
> found)...done.
>
> Loaded symbols for /lib/libncurses.so.7
>
> Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
>
> Loaded symbols for /lib/libc.so.7
>
> Reading symbols from /usr/local/lib/ocaml/stublibs/dllunix.so...(no 
> debugging symbols found)...done.
>
> Loaded symbols for /usr/local/lib/ocaml/stublibs/dllunix.so
>
> Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols 
> found)...done.
>
> Loaded symbols for /libexec/ld-elf.so.1
>
> #0 0x080606de in caml_interprete ()
>
> Not very informative. So here are my questions:
>
> - What is the best way to produce and analyze core dumps in ocaml? 
> Should I compile in bytecode or native? Is there any special gdb 
> “trick” that gives you more information? Is there any special “trick” 
> while compiling the ocaml runtime to make it throw more information?
>
> - Then, my main question is actually: in bytecode, what can produce 
> segfaults? My ocaml code is completely standard, excepted that I use 
> the Marshal module. So my question is rather: outside the Marshal 
> module, what can cause segfault?
>
About any binding can cause segfaults, if the binded library is not 
'safe', what library did you use?
For Marshall I am not expert; but I know it will likely produce 
segfaults if you are not careful, was the marshall producucer compiled 
with the same version as the marshall user? (I am not sure to be very 
clear...) and check the types produced and those used
>
> - Slightly unrelated question: I have been able to generate segfaults 
> by running ocaml code that: 1) iterates recursively through a list 
> reference 2) changes the reference while still iterating on it. For 
> example, you just do a “List.iter myfun !myref”, and within the 
> function myfun, you do stuff like “myref := List.filter 
> somefilterfunction !myref”. It is not good to program like this, but 
> for some reason I thought ocaml would not segfault on that. Is this 
> expected behavior? If it’s not, I’ll be happy to provide some simple 
> source code that illustrates it. (nevermind I have actually cleaned 
> all my code base from these dirty uses of references)
>
I am not shocked by the segfault (I am a lot more by your code), try 
rather “let l = !myref in List.iter myfun l”
>
> - About ocaml bytecode interpreter and ocaml native compiler: it seems 
> to me, looking at the ocaml source tree, that these two parts are 
> completely unrelated (I’m talking about the byterun and the 
> asmrun/asmcomp directories), meaning that they don’t share any source 
> code. Is that correct?
>
> Anyway guys, thanks for reading this, if you did, don’t know if this 
> makes any sense to you.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>   


-- 
Cédric AUGER

Univ Paris-Sud, Laboratoire LRI, UMR 8623, F-91405, Orsay