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

Ahmed Omar <>
Tue Sep 8 11:45:58 CEST 2015


Hi Lukas,
Thanks for your reply. I tried with the latest version of gdb (7.10) :

###
(gdb) bt full
#0  0x000000000044d299 in link_free_block (allctr=0x15e32c0, block=0x128)
at beam/erl_goodfit_alloc.c:439
        gfallctr = 0x15e32c0
        blk = 0x128
        sz = 0
        i = <optimized out>
#1  0x00000000015e32c0 in ?? ()
No symbol table info available.
#2  0x0000000000442fa6 in mbc_realloc (allctr=0x7fe0848807a8, p=0x11f,
size=<optimized out>, busy_pcrr_pp=0x8, alcu_flgs=0) at
beam/erl_alloc_util.c:2370
        crr = 0x128
        new_p = <optimized out>
        old_blk_sz = 287
        blk = 0x117
        new_blk = <optimized out>
        cand_blk = <optimized out>
        cand_blk_sz = <optimized out>
        blk_sz = 3748409
        nxt_blk = 0x236
        nxt_blk_sz = 22950592
        is_last_blk = 296
        get_blk_sz = 140602277246336
#3  0x0000000000000000 in ?? ()
No symbol table info available.
###

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

2015-09-08 10:51 GMT+02:00 Lukas Larsson <>:

> Hello,
>
> On Tue, Sep 8, 2015 at 10:33 AM, Ahmed Omar <> wrote:
>
>> Hi,
>> We have been experiencing a segfault on our servers running a custom
>> version of Ejabberd. We managed to get a core file from the last crash
>> This is what we see running gdb on it:
>> ######
>> Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols
>> found)...done.
>> Loaded symbols for /lib64/ld-linux-x86-64.so.2
>> 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 11, Segmentation fault.
>> #0  0x000000000044d299 in link_free_block (allctr=0x15e32c0, block=0x128)
>> at beam/erl_goodfit_alloc.c:439
>> 439 beam/erl_goodfit_alloc.c: No such file or directory.
>> in beam/erl_goodfit_alloc.c
>> ######
>>
>> If we run bt full in gdb we get:
>> ######
>> (gdb) bt full
>> #0  0x000000000044d299 in link_free_block (allctr=0x15e32c0, block=0x128)
>> at beam/erl_goodfit_alloc.c:439
>>         gfallctr = 0x15e32c0
>>         blk = 0x128
>>         sz = 0
>>         i = <value optimized out>
>> #1  0x00000000015e32c0 in ?? ()
>> No symbol table info available.
>> #2  0x0000000000442fa6 in mbc_realloc (allctr=0x7fe0848807a8, p=0x11f,
>> size=Unhandled dwarf expression opcode 0xf3
>> ) at beam/erl_alloc_util.c:2370
>>         crr = 0x128
>>         new_p = <value optimized out>
>>         old_blk_sz = 287
>>         blk = 0x117
>>         new_blk = <value optimized out>
>>         cand_blk = <value optimized out>
>>         cand_blk_sz = <value optimized out>
>>         blk_sz = 3748409
>>         nxt_blk = 0x236
>>         nxt_blk_sz = 22950592
>>         is_last_blk = 296
>>         get_blk_sz = 140602277246336
>> #3  0x0000000000000000 in ?? ()
>> No symbol table info available.
>> #######
>>
>> Is there a way to get more information? maybe which driver made the
>> realloc call?
>>
>
> Something is wrong/missing from this stacktrace. The gdb that you are
> using does not seem to understand the dwarf2 extension (at least that's
> what I guess after googling "Unhandled dwarf expression opcode 0xf3"), and
> can only find two of the frames. Try to install a later version of gdb and
> then do a bt full.
>
>
>>
>> Best Regards,
>> - Ahmed Omar
>> http://about.me/spawn.think/
>>
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150908/9cb8f1da/attachment.html>


More information about the erlang-questions mailing list