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
next parent 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