[erlang-questions] beam[8449]: segfault at 0 ip 0000000000437e10 sp 00007fffce250948 error 4 in beam[400000+174000]

Wed May 26 15:41:35 CEST 2010

On 05/25/2010 07:05 PM, Mikael Pettersson wrote:
> Eric Liang wrote:
>   
>> On 05/24/2010 09:14 PM, Mikael Pettersson wrote:
>>     
>>> Liang Yupeng wrote:
>>>  =20
>>>       
>>>> Thanks for your reply, Mikael. Yes, it is beam.smp and 64-bit one.
>>>>    =20
>>>>         
>>> I have some doubts about that, see below.
>>>
>>>  =20
>>>       
>>>>> 3. what tools (esp. gcc version) was this built with?
>>>>>
>>>>>      =20
>>>>>           
>>>> I install erlang by the command apt-get:
>>>>    =20
>>>>         
>>> ...
>>>  =20
>>>       
>>>> Is this OK? Should I install a new beam-vm by source to get some debug=
>>>>         
>>  info?
>>     
>>>>    =20
>>>>         
>>> Run `strings -a /path/to/beam | fgrep GCC | sort -u'
>>> (where /path/to/beam is the path to the beam executable).
>>>  =20
>>>       
>>     sunny@REDACTED:~$ strings -a /usr/lib/erlang/erts-5.7.2/bin/beam |
>>     fgrep GCC | sort -u
>>     sunny@REDACTED:~$ strings -a /usr/lib/erlang/erts-5.7.2/bin/beam.smp |
>>     fgrep GCC | sort -u
>>     sunny@REDACTED:~$
>>
>> You see, neither beam nor beam.smp contains the string like GCC. :(
>>     
> That means your distro removed useful metadata from your binaries.
>
>   
>>     sunny@REDACTED:~/commands$ objdump -D
>>     /usr/lib/erlang/erts-5.7.2/bin/beam > beam.objdump
>>     sunny@REDACTED:~/commands$ cat beam.objdump | grep -C 10 437e10
>>       437ddd:    e9 35 ff ff ff           jmpq   437d17
>>     <erts_gfalc_init+0x317>
>>       437de2:    66 0f 1f 44 00 00        nopw   0x0(%rax,%rax,1)
>>       437de8:    48 2d 20 e2 00 00        sub    $0xe220,%rax
>>       437dee:    31 d2                    xor    %edx,%edx
>>       437df0:    48 f7 b7 10 03 00 00     divq   0x310(%rdi)
>>       437df7:    05 c0 00 00 00           add    $0xc0,%eax
>>       437dfc:    e9 16 ff ff ff           jmpq   437d17
>>     <erts_gfalc_init+0x317>
>>       437e01:    66 66 66 66 66 66 2e     nopw   %cs:0x0(%rax,%rax,1)
>>       437e08:    0f 1f 84 00 00 00 00
>>       437e0f:    00
>>       437e10:    4c 8b 06                 mov    (%rsi),%r8
>>       437e13:    49 83 e0 f8              and    $0xfffffffffffffff8,%r8
>>       437e17:    49 81 f8 1f 02 00 00     cmp    $0x21f,%r8
>>       437e1e:    77 40                    ja     437e60
>>     <erts_gfalc_init+0x460>
>>       437e20:    49 8d 50 e0              lea    -0x20(%r8),%rdx
>>       437e24:    48 c1 ea 03              shr    $0x3,%rdx
>>       437e28:    4c 8b 4e 08              mov    0x8(%rsi),%r9
>>       437e2c:    4d 85 c9                 test   %r9,%r9
>>       437e2f:    74 4f                    je     437e80
>>     <erts_gfalc_init+0x480>
>>       437e31:    48 8b 46 10              mov    0x10(%rsi),%rax
>>       437e35:    49 89 41 10              mov    %rax,0x10(%r9)
>>     
> Again, this shows that your distro butchered the symbol table in
> your Erlang executable (beam). In reality erts_gfalc_init is only
> two instructions long and subsequent instructions belong to other named
> functions in erts/emulator/beam/erl_goodfit_alloc.c, but here they
> are incorrectly labeled as erts_gfalc_init+0x???.
>
> Anyway, I did a build from source with gcc-4.4.4 and matched the
> object code above to what I got, and it seems that unlink_free_block()
> in erl_goodfit_alloc.c was called with a NULL `block' parameter.
> This could be from the call at the end of get_free_block(), or via
> the ->unlink_free_block callback in erl_alloc_util.c. We really
> need a call stack dump at the point of the crash.
>   
Thanks for your work, Mikael.

I've done a build of the source, but it just can't match the object. How
do you make it? I use the command: apt-get source to get the source, so
it does have the same version with the object.

I'm now working on get the debug-info of that package in apt-get
sources, but it also stalled. However, I've asked this in ubuntu's
mailling-list, it should be worked out soon( I'll reply this mail then).

> You can get a stack dump from the crash by attaching gdb to the
> soon-to-crash beam process. Now instead of being terminated gdb will
> get control of the process and you should be able to print a stack
> trace with bt or where. (This does require that there's a sufficient
> time window from the start of the application to the crash.)
>   
I've make a core dump 4 seconds before it crash,  as mentioned above, 
because don't get the right symbols, it just with some quesion-marks:

    Core was generated by `/usr/lib/erlang/erts-5.7.2/bin/beam'.
    #0  0x00007f0a28ecd5a9 in ?? ()
    (gdb) whe
    #0  0x00007f0a28ecd5a9 in ?? ()
    #1  0x0000000000000000 in ?? ()
    (gdb)

yes, I've not get the core when it crashed. Maybe my OS setting on core
dump needs to be fixed, or maybe the beam which started by epmd does not
generate core? Anyway, this also needs to be worked out.

Look back the initial error:

    segfault at 0 ip 0000000000437e10 sp 00007fffce250948 error 4 in
    beam[400000+174000]

Would you mind tell me what's the meaning of -ip-/-sp-, and what does
-error 4- means? Thanks in advance. Also, any other suggestions would be
appreciated.

Thanks,
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20100526/7a307853/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20100526/7a307853/attachment.bin>