caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Sylvain Le Gall <sylvain@le-gall.net>
To: caml-list@inria.fr
Subject: Re: ocaml sefault in bytecode: unanswered questions
Date: Sat, 8 Aug 2009 09:37:54 +0000 (UTC)	[thread overview]
Message-ID: <slrnh7qhri.rtu.sylvain@gallu.homelinux.org> (raw)
In-Reply-To: <16043.1656208404$1249662628@news.gmane.org>

On 07-08-2009, ivan chollet <ivan.chollet@free.fr> wrote:
>
> This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols
> found)...
>
> Not very informative. So here are my questions:

I suppose you are running freebsd ? Which version of freebsd, of ocaml ? 

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

gdb is not the perfect tool to debug ocaml program. You should give a
try to ocamldebug which is a better option for bytecode (see below for
options). Bytecode is more informative when coming to reporting
backtrace (at least with old version of ocaml). 

Compile every program with "-g" option (just like gcc). 

If you have compiled everything with "-g" option, you can also use the
environment variable OCAMLRUNPARAM="b" to get a backtrace for your
exception, at runtime.

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

Some part of the bytecode are just standard C, everything can cause a
segfault just as C. These errors are not very common but it is possible
that some case are not well handled on freebsd. Most probably a porting
issue.

Marshal module can easily trigger a segfault when you map the loaded data
to a type which doesn't match the dumped data.

Example: 
List.length (Marshal.from_string (Marshal.to_string 1234 []) 0);;

Here the integer value is marshalled and then unmarshalled as a list ->
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)
>

Could you provide a minimal example code for this error ? I don't think
this should generate a segfault.


Regards
Sylvain Le Gall


       reply	other threads:[~2009-08-08  9:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <16043.1656208404$1249662628@news.gmane.org>
2009-08-08  9:37 ` Sylvain Le Gall [this message]
     [not found] <23185.6251172305$1249751407@news.gmane.org>
2009-08-08 21:14 ` Sylvain Le Gall
2009-08-08 17:09 ivan chollet
  -- strict thread matches above, loose matches on Subject: below --
2009-08-07 16:29 ivan chollet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=slrnh7qhri.rtu.sylvain@gallu.homelinux.org \
    --to=sylvain@le-gall.net \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).