[erlang-questions] segfault erts-5.10.4 (R16B03-1)

[Ahmed Omar]

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..
Here's a link for the bt full output

https://gist.github.com/spawnthink/4af73b8e5d6b7f58ec4c#file-btfull-log

Any hints would be appreciated


Best Regards,
- Ahmed Omar
http://about.me/spawn.think/

On Wed, Sep 9, 2015 at 2:52 PM, Lukas Larsson <garazdawi@REDACTED> wrote:

> On Wed, Sep 9, 2015 at 2:19 PM, Ahmed Omar <spawn.think@REDACTED> wrote:
>
>> ###
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib64/libthread_db.so.1".
>> Core was generated by `/var/lib/ejabberd/erts-5.10.4/bin/beam.smp -K true
>> -A 128 -P 2500000 -Q 500000'.
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0  0x000000000044d299 in bf_get_free_block ()
>> [Current thread is 1 (Thread 0x7fe077fbc700 (LWP 24141))]
>> (gdb) bt full
>> #0  0x000000000044d299 in bf_get_free_block ()
>> No symbol table info available.
>> #1  0x0000000000442fa6 in mbc_alloc ()
>> No symbol table info available.
>> #2  0x0000000000448803 in erts_alcu_alloc_thr_pref ()
>> No symbol table info available.
>> #3  0x0000000000509508 in erts_alloc ()
>> No symbol table info available.
>> #4  0x00000000005096de in erts_bs_append ()
>> No symbol table info available.
>> #5  0x000000000053c1f8 in process_main ()
>> No symbol table info available.
>> #6  0x000000000049da8b in sched_thread_func ()
>> No symbol table info available.
>> #7  0x00000000005bd146 in thr_wrapper ()
>> No symbol table info available.
>> #8  0x00000039a80079d1 in start_thread () from /lib64/libpthread.so.0
>> No symbol table info available.
>> #9  0x00000039a78e88fd in clone () from /lib64/libc.so.6
>> No symbol table info available.
>> ###
>>
>> I'll keep digging ...
>>
>>
> 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.
>
> Lukas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150921/c055bde3/attachment.htm>