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=HTML_MESSAGE, 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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 8BB32BC37 for ; Fri, 7 Aug 2009 18:30:07 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYBACvze0rLOwFrkWdsb2JhbACCKC2XbAEBAQEJCwoHEwS2DoQWBQ X-IronPort-AV: E=Sophos;i="4.43,342,1246831200"; d="scan'208,217";a="44448539" Received: from outbound.icp-qv1-irony-out2.iinet.net.au ([203.59.1.107]) by mail4-smtp-sop.national.inria.fr with ESMTP; 07 Aug 2009 18:30:04 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMEAKPze0p8qHif/2dsb2JhbACCKC3OHIQWBQ X-IronPort-AV: E=Sophos;i="4.43,342,1246809600"; d="scan'208,217";a="548283082" Received: from unknown (HELO ivanz27oq2f1va) ([124.168.120.159]) by outbound.icp-qv1-irony-out2.iinet.net.au with ESMTP; 08 Aug 2009 00:30:00 +0800 From: "ivan chollet" To: Subject: ocaml sefault in bytecode: unanswered questions Date: Fri, 7 Aug 2009 18:29:54 +0200 Message-ID: <000701ca177c$4c9ecea0$e5dc6be0$@chollet@free.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01CA178D.10279EA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoXfEu3RBzQg3kVSMiIjlUJu288oQ== Content-Language: fr X-Spam: no; 0.00; ocaml:01 bytecode:01 ocaml:01 bytecode:01 gdb:01 gdb:01 lib:01 lib:01 libc:01 libc:01 usr:01 stublibs:01 dllunix:01 usr:01 stublibs:01 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01CA178D.10279EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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? - 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) - 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. ------=_NextPart_000_0008_01CA178D.10279EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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?

-          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 :=3D = 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)

-          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.

------=_NextPart_000_0008_01CA178D.10279EA0--