Re: [Caml-list] segmentation fault

[Francois BERENGER <berenger@bioreg.kyushu-u.ac.jp>]

On 06/20/2017 06:19 AM, Julia Lawall wrote:
> 
> 
> 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.

If this is using parmap, I would suggest disabling parmap and trying a 
sequential version of the program.

I have seen parmap "maskerading" exceptions.
But when you don't use parmap, you can truly see what exception you have
and where it is coming from.

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