From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.4 required=5.0 tests=AWL,MSGID_MULTIPLE_AT autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id D7C3BBC37 for ; Sat, 8 Aug 2009 11:17:56 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooCAC7ffErLOwFri2dsb2JhbACPSYsBAQEBCgsKBxEGoW2SNYQXBYIn X-IronPort-AV: E=Sophos;i="4.43,345,1246831200"; d="scan'208";a="34171844" Received: from outbound.icp-qv1-irony-out2.iinet.net.au ([203.59.1.107]) by mail1-smtp-roc.national.inria.fr with ESMTP; 08 Aug 2009 11:17:55 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQEAC7ffEp8qHif/2dsb2JhbACPSa0ukjWEFwWCJw X-IronPort-AV: E=Sophos;i="4.43,345,1246809600"; d="scan'208";a="548441487" Received: from unknown (HELO ivanz27oq2f1va) ([124.168.120.159]) by outbound.icp-qv1-irony-out2.iinet.net.au with ESMTP; 08 Aug 2009 17:17:50 +0800 From: "ivan chollet" To: "'Cedric Auger'" , Subject: RE: [Caml-list] ocaml sefault in bytecode: unanswered questions Date: Sat, 8 Aug 2009 11:17:42 +0200 Message-ID: <000301ca1809$1658efa0$430acee0$@chollet@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoXi6/ASknlXTl0Sp+1IHurBAyOtQANQ75gABINkwA= Content-Language: fr X-Spam: no; 0.00; ocaml:01 bytecode:01 segfaults:01 ocaml:01 bytecode:01 runtime:01 segfault:01 segfaults:01 iter:01 myfun:01 myfun:01 segfault:01 runtime:01 lri:01 gdb:01 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 =93let l =3D !myref in List.iter = myfun l=94 (where myfun modifies !myref) wouldn't produce segfault.=20 Why? It would mean that doing "let l =3D !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=92t 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]=20 Sent: vendredi 7 ao=FBt 2009 20:20 To: ivan chollet Subject: Re: [Caml-list] ocaml sefault in bytecode: unanswered questions ivan chollet a =E9crit : > > Hello guys, > > I would like to ask a question about ocaml error handling. Actually=20 > many questions that I=92ve never dared asking on the official mailing=20 > list. I=92ve had a few problems sparsely with OCaml bytecode programs=20 > throwing a core dump. When analyzing these core dumps, gdb says it=92s = a=20 > =93Segmentation fault=94. Here is an example of this: > > This GDB was configured as "i386-marcel-freebsd"...(no debugging=20 > 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=20 > 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=20 > 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=20 > 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?=20 > Should I compile in bytecode or native? Is there any special gdb=20 > =93trick=94 that gives you more information? Is there any special = =93trick=94=20 > while compiling the ocaml runtime to make it throw more information? > > - Then, my main question is actually: in bytecode, what can produce=20 > segfaults? My ocaml code is completely standard, excepted that I use=20 > the Marshal module. So my question is rather: outside the Marshal=20 > module, what can cause segfault? > About any binding can cause segfaults, if the binded library is not=20 'safe', what library did you use? For Marshall I am not expert; but I know it will likely produce=20 segfaults if you are not careful, was the marshall producucer compiled=20 with the same version as the marshall user? (I am not sure to be very=20 clear...) and check the types produced and those used > > - Slightly unrelated question: I have been able to generate segfaults=20 > by running ocaml code that: 1) iterates recursively through a list=20 > reference 2) changes the reference while still iterating on it. For=20 > example, you just do a =93List.iter myfun !myref=94, and within the=20 > function myfun, you do stuff like =93myref :=3D List.filter=20 > somefilterfunction !myref=94. It is not good to program like this, but = > for some reason I thought ocaml would not segfault on that. Is this=20 > expected behavior? If it=92s not, I=92ll be happy to provide some = simple=20 > source code that illustrates it. (nevermind I have actually cleaned=20 > 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=20 rather =93let l =3D !myref in List.iter myfun l=94 > > - About ocaml bytecode interpreter and ocaml native compiler: it seems = > to me, looking at the ocaml source tree, that these two parts are=20 > completely unrelated (I=92m talking about the byterun and the=20 > asmrun/asmcomp directories), meaning that they don=92t share any = source=20 > code. Is that correct? > > Anyway guys, thanks for reading this, if you did, don=92t 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 > =20 --=20 C=E9dric AUGER Univ Paris-Sud, Laboratoire LRI, UMR 8623, F-91405, Orsay