<div dir="ltr">Hi Lukas, <div><br></div><div>You were right, there was a mismatch between beam.smp on development and production (unfortunately, different build servers...)</div><div><br></div><div>I ran the session now with the right beam.smp </div><div><br></div><div>###</div><div><div>[Thread debugging using libthread_db enabled]</div><div>Using host libthread_db library "/lib64/libthread_db.so.1".</div><div>Core was generated by `/var/lib/ejabberd/erts-5.10.4/bin/beam.smp -K true -A 128 -P 2500000 -Q 500000'.</div><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><div>No symbol table info available.</div><div>#1 0x0000000000442fa6 in mbc_alloc ()</div><div>No symbol table info available.</div><div>#2 0x0000000000448803 in erts_alcu_alloc_thr_pref ()</div><div>No symbol table info available.</div><div>#3 0x0000000000509508 in erts_alloc ()</div><div>No symbol table info available.</div><div>#4 0x00000000005096de in erts_bs_append ()</div><div>No symbol table info available.</div><div>#5 0x000000000053c1f8 in process_main ()</div><div>No symbol table info available.</div><div>#6 0x000000000049da8b in sched_thread_func ()</div><div>No symbol table info available.</div><div>#7 0x00000000005bd146 in thr_wrapper ()</div><div>No symbol table info available.</div><div>#8 0x00000039a80079d1 in start_thread () from /lib64/libpthread.so.0</div><div>No symbol table info available.</div><div>#9 0x00000039a78e88fd in clone () from /lib64/libc.so.6</div><div>No symbol table info available.</div></div><div>###</div><div><br></div><div>I'll keep digging ...</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 Tue, Sep 8, 2015 at 4:45 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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Sep 8, 2015 at 4:34 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Ok. I guess etp-ports require a live session then?</div><div>(gdb) etp-ports</div><div>No ports, since system isn't initialised!</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Is there a way to get port or process number from the information I got from bt ?</div><span><div><div>#2 0x0000000000442fa6 in mbc_realloc (allctr=0x7fe0848807a8, p=0x11f,</div><div> size=<optimized out>, busy_pcrr_pp=0x8, alcu_flgs=0)</div></div><div><br></div><div><br></div></span></div></blockquote><div><br></div></span><div>All etp macros work on both core files a live nodes. The only time I've seen that error from etp-ports is when the VM crashed before the internal ports array was initialized.<br></div><div><br></div><div>I'm starting to suspect that there is something wrong with your debugging session. The stack trace that you have printed is corrupt, and it cannot find a working port table. Make extra sure that you are using the same beam.smp to run your gdb session from as generated the core.</div><div><br></div><div>Since the stack is corrupt it is not possible to know what called into the realloc from the stack trace.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Lukas</div><div><br></div><div><br></div><div><br></div></font></span></div></div></div>
</blockquote></div><br></div>