<div dir="ltr">The crash occurred again, this time I ran a locally compiled gdb on the build environment pointing to the beam.smp file from the build used to generate the release. This worked better..<div>Here's a link for the bt full output</div><div><br></div><div><a href="https://gist.github.com/spawnthink/4af73b8e5d6b7f58ec4c#file-btfull-log">https://gist.github.com/spawnthink/4af73b8e5d6b7f58ec4c#file-btfull-log</a></div><div><br></div><div>Any hints would be appreciated<br><div><br></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Best Regards,<br>- Ahmed Omar<div><span style="color:rgb(51,51,51);font-family:proxima-nova-1,proxima-nova-2,Tahoma,Helvetica,Verdana,sans-serif;font-size:14px;line-height:18px"><a href="http://about.me/spawn.think/" target="_blank">http://about.me/spawn.think/</a></span></div></div></div></div>
<br><div class="gmail_quote">On Wed, Sep 9, 2015 at 2:52 PM, Lukas Larsson <span dir="ltr"><<a href="mailto:garazdawi@gmail.com" target="_blank">garazdawi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Wed, Sep 9, 2015 at 2:19 PM, Ahmed Omar <span dir="ltr"><<a href="mailto:spawn.think@gmail.com" target="_blank">spawn.think@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>###<br></div><div><div>[Thread debugging using libthread_db enabled]</div><div>Using host libthread_db library "/lib64/libthread_db.so.1".</div><span><div>Core was generated by `/var/lib/ejabberd/erts-5.10.4/bin/beam.smp -K true -A 128 -P 2500000 -Q 500000'.</div></span><div>Program terminated with signal SIGSEGV, Segmentation fault.</div><div>#0  0x000000000044d299 in bf_get_free_block ()</div><div>[Current thread is 1 (Thread 0x7fe077fbc700 (LWP 24141))]</div></div><div><div>(gdb) bt full</div><div>#0  0x000000000044d299 in bf_get_free_block ()</div><span><div>No symbol table info available.</div></span><div>#1  0x0000000000442fa6 in mbc_alloc ()</div><span><div>No symbol table info available.</div></span><div>#2  0x0000000000448803 in erts_alcu_alloc_thr_pref ()</div><span><div>No symbol table info available.</div></span><div>#3  0x0000000000509508 in erts_alloc ()</div><span><div>No symbol table info available.</div></span><div>#4  0x00000000005096de in erts_bs_append ()</div><span><div>No symbol table info available.</div></span><div>#5  0x000000000053c1f8 in process_main ()</div><span><div>No symbol table info available.</div></span><div>#6  0x000000000049da8b in sched_thread_func ()</div><span><div>No symbol table info available.</div></span><div>#7  0x00000000005bd146 in thr_wrapper ()</div><span><div>No symbol table info available.</div></span><div>#8  0x00000039a80079d1 in start_thread () from /lib64/libpthread.so.0</div><span><div>No symbol table info available.</div></span><div>#9  0x00000039a78e88fd in clone () from /lib64/libc.so.6</div><span><div>No symbol table info available.</div></span></div><div>###</div><div><br></div><div>I'll keep digging ...</div></div><div class="gmail_extra"><br></div></blockquote><div><br></div></div></div><div>It looks like you have a memory corruption issue. Normally when something goes wrong in the memory allocators, it is because a badly written nif/linked-in driver has written outside the buffer it requested by calling driver/enif_alloc. I would take a deep long look at any native code that you have running and see if you can find any such bugs. If you can reproduce the error, I would attempt to run the same scenario in valgrind as it is quite good at spotting these types of errors. </div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Lukas</div></font></span></div></div></div>
</blockquote></div><br></div>