<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>For what it's worth here's a gdb with symbols:<div><br></div><div>







<p class="p1"><span class="s1">(gdb) bt</span></p>
<p class="p1"><span class="s1">#0  sweep_off_heap (p=0x7faeb8fc5488, fullsweep=-1295963664) at beam/erl_gc.c:2353</span></p>
<p class="p1"><span class="s1">#1  0x00000000004b77d1 in do_minor (p=0x7faeb8fc5488, new_sz=<optimized out>, objv=<optimized out>, nobj=<optimized out>) at beam/erl_gc.c:1166</span></p>
<p class="p1"><span class="s1">#2  0x00000000004b8479 in minor_collection (recl=<optimized out>, nobj=<optimized out>, objv=<optimized out>, need=<optimized out>, p=<optimized out>) at beam/erl_gc.c:876</span></p>
<p class="p1"><span class="s1">#3  erts_garbage_collect (p=0x7faeb8fc5488, need=<optimized out>, objv=<optimized out>, nobj=<optimized out>) at beam/erl_gc.c:450</span></p>
<p class="p1"><span class="s1">#4  0x00000000004e1374 in process_main () at beam/beam_emu.c:1858</span></p>
<p class="p1"><span class="s1">#5  0x000000000048071d in sched_thread_func (vesdp=<optimized out>) at beam/erl_process.c:7719</span></p>
<p class="p1"><span class="s1">#6  0x0000000000549f89 in thr_wrapper (vtwd=<optimized out>) at pthread/ethread.c:106</span></p>
<p class="p1"><span class="s1">#7  0x00007faeba32ba30 in ?? ()</span></p>
<p class="p1"><span class="s1">#8  0x0000000000000000 in ?? ()</span></p><p class="p1"><span class="s1"><br></span></p><br><div><hr id="stopSpelling">From: mattevans123@hotmail.com<br>To: garazdawi@gmail.com<br>Date: Sun, 29 May 2016 21:32:58 -0400<br>CC: erlang-questions@erlang.org; erlang-bugs@erlang.org<br>Subject: Re: [erlang-questions] [erlang-bugs] beam core file R17<br><br>

<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}

.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}

--></style>
<div dir="ltr"><br>Thanks,<div><br></div><div>Fortunately our latest release has moved all the NIF logic to a separate CNODE based process. I am leaning towards the NIF as the cause since the VM itself has proven to be very stable.</div><div><br></div><div><br><div><hr id="ecxstopSpelling">Date: Sun, 29 May 2016 21:23:15 +0200<br>Subject: Re: [erlang-bugs] beam core file R17<br>From: garazdawi@gmail.com<br>To: mattevans123@hotmail.com<br>CC: erlang-questions@erlang.org<br><br><div dir="ltr">sweep_off_heap is run when collecting refc binaries (among other things), so if you by mistake have decremented the reference count of a binary in a nif too much, this error will happen when the GC is inspecting the binary. I'd recommend looking for something like that in any nifs you have.<br><div class="ecxgmail_extra"><br><div class="ecxgmail_quote">On Sun, May 29, 2016 at 6:04 PM, Matthew Evans <span dir="ltr"><<a href="mailto:mattevans123@hotmail.com" target="_blank">mattevans123@hotmail.com</a>></span> wrote:<br><blockquote class="ecxgmail_quote" style="border-left:1px #ccc solid;padding-left:1ex;">Thanks, this software does use nifs<br>
<br>
Sent from my iPhone<br>
<div class="ecxHOEnZb"><div class="h5"><br>
> On May 29, 2016, at 11:56 AM, Mikael Pettersson <<a href="mailto:mikpelinux@gmail.com">mikpelinux@gmail.com</a>> wrote:<br>
><br>
> Matthew Evans writes:<br>
>> Hi,<br>
>> This core was found on a live system (R17):<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> 10:16:38:# erl<br>
>> Erlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]<br>
>><br>
>><br>
>> Eshell V6.2  (abort with ^G)<br>
>> 1><br>
>><br>
>> ........<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> May 28 22:18:56 [info   ] plexxi kernel: [1235119.885465] beam.smp[2267] general protection ip:4b698a sp:7faeb6a7d650 error:0 in beam.smp[400000+1ac000]<br>
>> warning: Can't read pathname for load map: Input/output error.[Thread debugging using libthread_db enabled]Using host libthread_db library "/lib/libthread_db.so.1".Core was generated by `/usr/lib/erlang/erts-6.2/bin/beam.smp -K true -A 24 -P 350000 -- -root /usr/lib'.Program terminated with signal 11, Segmentation fault.#0  0x00000000004b698a in sweep_off_heap ()(gdb) bt#0  0x00000000004b698a in sweep_off_heap ()#1  0x00000000004b77d1 in do_minor ()#2  0x00000000004b8479 in erts_garbage_collect ()#3  0x00000000004e1374 in process_main ()#4  0x000000000048071d in sched_thread_func ()#5  0x0000000000549f89 in thr_wrapper ()#6  0x00007faeba32ba30 in start_thread () from /lib/libpthread.so.0#7  0x00007faeb9e8a53d in clone () from /lib/libc.so.6<br>
><br>
> It looks like your beam.smp binary lacks debugging information, so we only know the general<br>
> area where it crashed (sweep_off_heap() as called from do_minor()).  Crashes here would usually<br>
> be due to memory corruption, which could be caused by:<br>
> - a bug in the VM<br>
> - a bug in a NIF<br>
> - a bug in HiPE<br>
> - a bug in the C compiler used to compile the VM (I've seen that happen at least 3 times)<br>
> - a HW error (though you'd then also find e.g. machine check events logged)<br>
><br>
> If you want to debug this, you should first ensure that your beam.smp gets built and installed<br>
> with full debugging information (just attach gdb, bt, and list to verify).  You should also try<br>
> without NIFs or native code, if those are used and you can configure them not to be.<br>
_______________________________________________<br>
erlang-bugs mailing list<br>
<a href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-bugs" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>
</div></div></blockquote></div><br></div></div></div></div>                                         </div>
<br>_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions</div></div>                                       </div></body>
</html>