ERL-1254: Segmentation fault (core dumped)

[OTP-Maintainer]

Original reporter: sdl.web@gmail.com
Affected version: OTP-23.0
Fixed in version: OTP-23.0.2
Component: erts
Migrated from: https://bugs.erlang.org/browse/ERL-1254

---

BEAM for OTP 23 can segfault on centos 7. I attached the core file and the corresponding beam.smp. Sorry I haven't found a simple recipe to reproduce this.

[OTP-Maintainer]

sverker said:

Core dump analysis:

A connection _attempt_ from the crashed node  (devel@127.0.0.1) toward a node with name 'emacs-1864@tasmania' has been made, and a message or other signal has been buffered waiting to be sent when the connection has been established. The call stack of the crash is Erlang process 'net_kernel' calling  erts_internal:abort_pending_connection/2 to abort the ongoing connection attempt due to some error. When doing this, it tries to deallocate the buffered signal which fails with a SEGV crash as the buffered signal has been corrupted in memory. I can't see however where the corruption comes from.

One way forward is for you to try reproduce this with an debug compiled beam and hope for an earlier nicer crash dump.

Build with
{noformat}
> export ERL_TOP=<otp-src-dir>
> cd $ERL_TOP/erts/emulator
> make debug
{noformat}
Copy beam.debug.smp and erl_child_setup.debug to installation
{noformat}
> cp $ERL_TOP/bin/*/beam.debug.smp        <install-dir>/erts-*/bin/
> cp $ERL_TOP/bin/*/erl_child_setup.debug <install-dir>/erts-*/bin/
{noformat}
Run with
{noformat}
> erl -emu_type debug
Erlang/OTP 22 [erts-10.7.2] [source-6929c3d] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe] [type-assertions] [debug-compiled] [lock-checking{noformat}

[OTP-Maintainer]

sdl.web@gmail.com said:

Using the debug emulator. On crash the terminal prints:
{code:java}
beam/external.c:3752:store_in_vec() Assertion failed: ctx->vlen <= ctx->debug_vlen
                                                                                                      Aborted (core dumped)
{code}
But there is no erl_crash.dump only a core file which I have uploaded to this bug.

[OTP-Maintainer]

sverker said:

The debug build just adds more runtime checks, aborting with core dump if failed. So this is what I expected.

However, my gdb fails to view the call stack from the crashing thread.

 
{noformat}
> gdb beam.debug.smp core.14043

:

(gdb) backtrace
#0 0x00007facc6131387 in ?? ()
#1 0x00007facc6132a78 in ?? ()
#2 0x0000000000000020 in ?? ()
#3 0x0000000000000000 in ?? ()
{noformat}
Can you check if you get the same thing?

[OTP-Maintainer]

sdl.web@gmail.com said:

Here is what I get on centos 7 with its stock gdb:
{code:java}
(gdb) backtrace 
#0  0x00007facc6131387 in raise () from /lib64/libc.so.6
#1  0x00007facc6132a78 in abort () from /lib64/libc.so.6
#2  0x00000000006c8ccc in erl_assert_error (expr=0x84e99d "ctx->vlen <= ctx->debug_vlen", func=0x84fde1 <__func__.23924> "store_in_vec", file=0x84d090 "beam/external.c", 
    line=3752) at sys/unix/sys.c:954
#3  0x00000000005c2017 in store_in_vec (ctx=0x7fac840fc2e8, ep=0x7fac85a0700f "R\227\357ͫ\227\357ͫ\315d\002", ohbin=0x0, ohpb=18446744073709551576, ohp=0x0, ohsz=0)
    at beam/external.c:3752
#4  0x00000000005c1a83 in enc_term_int (ctx=0x7fac840fc2e8, acmp=0x0, obj=18446744073709551611, ep=0x7fac85a0700f "R\227\357ͫ\227\357ͫ\315d\002", dflags=4297394092, 
    off_heap=0x0, reds=0x7fac840fc288, res=0x7fac840fc2a8) at beam/external.c:3637
#5  0x00000000005b5e0d in erts_encode_dist_ext (term=140378745862818, ext=0x7fac840fc2a8, flags=4297394092, acmp=0x0, ctx=0x7fac840fc2e8, fragmentsp=0x7fac840fc2c8, 
    reds=0x7fac840fc288) at beam/external.c:723
#6  0x00000000005d1e99 in erts_dsig_send (ctx=0x7fac840fc1f0) at beam/dist.c:3064
#7  0x00000000005cc45d in erts_dsig_send_reg_msg (ctx=0x7fac840fc1f0, remote_name=176075, full_to=140378745863802, message=140378745862818) at beam/dist.c:1523
#8  0x0000000000565b13 in remote_send (p=0x7fac857c1d70, dep=0x7fac860c1998, to=176075, node=586251, full_to=140378745863802, msg=140378745862818, return_term=28875, 
    ctxpp=0x7fac840fc4d0, connect=1, suspend=0) at beam/bif.c:1894
#9  0x00000000005665c3 in do_send (p=0x7fac857c1d70, to=140378745863802, msg=140378745862818, return_term=28875, refp=0x7fac840fc4d8, dist_ctx=0x7fac840fc4d0, connect=1, 
    suspend=0) at beam/bif.c:2119
#10 0x0000000000566967 in send_3 (A__p=0x7fac857c1d70, BIF__ARGS=0x7fac85b80200, A__I=0x7fac85dfca70) at beam/bif.c:2186
#11 0x000000000044cbf9 in process_main (x_reg_array=0x7fac85b80200, f_reg_array=0x7fac85b82280) at x86_64-unknown-linux-gnu/debug/smp/beam_hot.h:331
#12 0x000000000048f706 in sched_thread_func (vesdp=0x7fac84d414c0) at beam/erl_process.c:8509
#13 0x00000000007a0fe3 in thr_wrapper (vtwd=0x7ffedcb328b0) at pthread/ethread.c:118
#14 0x00007facc66d8ea5 in start_thread () from /lib64/libpthread.so.0
#15 0x00007facc61f98dd in clone () from /lib64/libc.so.6

{code}

[OTP-Maintainer]

sverker said:

Proposed fix: [https://github.com/erlang/otp/pull/2640]

 

[OTP-Maintainer]

sdl.web@gmail.com said:

With the patch applied I can no longer crash the vm. Thanks for the fix.