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
>