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

[Mikael Pettersson]

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.

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.)