<div dir="ltr">Ok, after a bit of learning how to use gdb, I now have a set of backtraces that point to a different piece of code. Also I have figured out the proximate condition for the issue to exist...<div><br></div><div>Now that I have the matching beam file to go with the crash dump, I am consistently seeing the crash in this location:</div><div><br></div><div>```</div><div><div>Program terminated with signal SIGSEGV, Segmentation fault.</div><div>#0  0x00000000004c7f11 in eq (a=<optimized out>, b=<optimized out>) at beam/utils.c:2346</div><div>2346          if (!is_boxed(b) || *boxed_val(b) != *aa)</div><div>[Current thread is 1 (Thread 0x7f6721931700 (LWP 515))]</div><div>(gdb) backtrace</div><div>#0  0x00000000004c7f11 in eq (a=<optimized out>, b=<optimized out>) at beam/utils.c:2346</div><div>#1  0x000000000044a15b in process_main (x_reg_array=0x7f672779c5c0, f_reg_array=0x7f672c07fb82) at beam/beam_emu.c:1568</div><div>#2  0x00000000004f4b88 in sched_thread_func (vesdp=0x7f6723d47980) at beam/erl_process.c:8906</div><div>#3  0x0000000000675945 in thr_wrapper (vtwd=0x7ffdbbd3e4e0) at pthread/ethread.c:118</div><div>#4  0x00007f676acfb494 in start_thread (arg=0x7f6721931700) at pthread_create.c:333</div><div>#5  0x00007f676a835acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97</div></div><div>```</div><div><br></div><div>So the interesting thing is this: I can completely get rid of the crashes by disabling the feature that I have been working on that uses `seq_trace`</div><div><br></div><div>We did a bit of googling and found a very old bug related to `seq_trace` and memory corruption...</div><div><br></div><div>OTP-4222 Match spec 'set_seq_token' corrupts heap<br></div><div><br></div><div><a href="https://github.com/erlang/otp/blame/cf2df1b555072a1413f97259abec38b82513dbdc/lib/kernel/test/seq_trace_SUITE.erl#L512">https://github.com/erlang/otp/blame/cf2df1b555072a1413f97259abec38b82513dbdc/lib/kernel/test/seq_trace_SUITE.erl#L512</a><br></div><div><br></div><div>I'm wondering if this issue still exists, and we are winding up with corrupted memory which then means that the `eq` check just blows up...</div><div><br></div><div><br></div><div>FYI - Sorry I got the beam files mixed up earlier, but also glad that led to a bug fix of it's own!!</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 24, 2018 at 7:37 AM, Vince Foley <span dir="ltr"><<a href="mailto:vincefoley@gmail.com" target="_blank">vincefoley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm using Docker to build and run my release (my company has tons of docker infrastructure)..<div><br></div><div>The official docker image looks like it builds erlang from source with `./otp_build autoconf`<br><div><br></div><div><a href="https://github.com/c0b/docker-erlang-otp/blob/master/20/Dockerfile" target="_blank">https://github.com/c0b/docker-<wbr>erlang-otp/blob/master/20/<wbr>Dockerfile</a><br></div></div><div><a href="https://hub.docker.com/_/erlang/" target="_blank">https://hub.docker.com/_/<wbr>erlang/</a><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 24, 2018 at 7:27 AM, Roger Lipscombe <span dir="ltr"><<a href="mailto:roger@differentpla.net" target="_blank">roger@differentpla.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 24 April 2018 at 14:20, Vince Foley <<a href="mailto:vincefoley@gmail.com" target="_blank">vincefoley@gmail.com</a>> wrote:<br>
> Do you know of any documentation around building "unstripped" erlang<br>
> releases? This is my next step...<br>
<br>
</span>Don't strip them in the first place :)<br>
<br>
We build our Erlang/OTP using kerl, which we then embed into our<br>
release, which is then packaged as a .deb file, using the Debian tools<br>
(debbuild, etc.).<br>
<br>
It's the debbuild step that strips the binaries as they're put in the<br>
.deb file. We simply keep the unstripped beam.smp binary from before<br>
this happens. Do the ESL .deb files (assuming that's how you're<br>
installing Erlang) also contain stripped binaries?<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>