From: Julia Lawall <julia.lawall@lip6.fr>
To: Josh Berdine <josh@berdine.net>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] segmentation fault
Date: Mon, 19 Jun 2017 23:19:14 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1706192317110.2076@hadrien> (raw)
In-Reply-To: <jk60ig4lvbvfv5.fsf@fb.com>
[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]
On Mon, 19 Jun 2017, Josh Berdine wrote:
> On Mon, Jun 19 2017, Julia Lawall wrote:
>
> > On Mon, 19 Jun 2017, David MENTRÉ wrote:
> >
> >> Hello Julia,
> >>
> >> Le 2017-06-18 à 21:41, Julia Lawall a écrit :
> >> > Over several
> >> > runs on two different laptops, the backtraces have nothing obvious in
> >> > common. The bytecode version does not seem to stack overflow. Adding
> >> > Gc.print_stat() at a periodic quiescent point in the execution did not
> >> > show a memory leak.
> >>
> >> A similar issue related to random crash in native code version was asked
> >> by Alexey Egorov on this list 9 days ago. Daniel Bünzli advised to him
> >> to frequently call Gc.full_major () to have a crash closer to the real
> >> issue.
> >
> > OK, I will try this.
>
> Are you using Windows? I have only experienced segfaults from stack
> overflow on Windows.
No, Linux.
>
> >> In the case of Alexey, it was a non tail-recursive call that triggered a
> >> stack overflow and that is not detected in OCaml native code. Apparently
> >> this kind of issue is fixed in next to come OCaml 4.06.0.
> >
> > Why would something like this not be deterministic? In my case, it can
> > happen after seconds or after tens of minutes.
>
> This sounds like an interaction with the GC to me.
This was my thought as well. Also, of the four cores I have, two are in
the Gc. But two are not.
> >> Of course, your issue might be entirely different. But frequently
> >> calling Gc.full_major () seems a sensible starting point to me.
> >>
> >> Otherwise you have the usual suspects: are you using C bidings? Threads?
> >
> > There are no threads. The software may use C bindings. I don't think
> > they are involved in the failing execution, but I'm not 100% sure.
>
> I have found running under valgrind to be helpful in this sort of
> situation, though it is slow and some valid code can trigger many
> warnings.
OK, I'll try that.
thanks,
julia
>
> Cheers, Josh
>
next prev parent reply other threads:[~2017-06-19 21:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-18 19:41 Julia Lawall
2017-06-19 20:15 ` David MENTRÉ
2017-06-19 20:58 ` Julia Lawall
2017-06-19 21:15 ` Josh Berdine
2017-06-19 21:19 ` Julia Lawall [this message]
2017-06-20 1:01 ` Francois BERENGER
2017-06-20 6:34 ` Julia Lawall
2017-06-21 14:20 ` Markus Weißmann
2017-06-23 17:03 ` SP
2017-06-23 17:25 ` Julia Lawall
2017-06-29 15:19 ` Damien Doligez
2017-06-29 15:26 ` Julia Lawall
2017-06-29 23:16 ` Julia Lawall
2017-06-30 10:55 ` Julia Lawall
2017-06-30 14:06 ` SP
2017-07-01 18:37 ` Julia Lawall
-- strict thread matches above, loose matches on Subject: below --
2008-06-03 3:09 Segmentation fault Jacques Le Normand
2008-06-03 14:08 ` [Caml-list] " Berke Durak
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=alpine.DEB.2.20.1706192317110.2076@hadrien \
--to=julia.lawall@lip6.fr \
--cc=caml-list@inria.fr \
--cc=josh@berdine.net \
/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