[erlang-questions] Segfault with Erlang R22

[Eckard Brauer]

It's a few years ago, but IIRC either "print *c_p" or "print
*((Process*) c_p)". Problem would probably be that the processor
already left the stack frame where c_p is valid.

You can do "info stack" at this point and select the frame with "frame
<#>" to try it again. If you're a little familiar with assembly
language, you can even have a look at "disassemble <address>" or
"disassemble function" to get an idea of where values are at what point
in the instruction/processing flow - sometimes this helps too.

I'd investigate starting with frame 2 here, as all frames below are
already in libpthread.

Hope that helps a bit...

Eckard


Am Fri, 1 Nov 2019 18:22:18 +0000
schrieb "Bekes, Andras G" <Andras.Bekes@REDACTED>:

> Program terminated with signal 11, Segmentation fault.
> #0  process_main (x_reg_array=0x20002, f_reg_array=0x2) at
> x86_64-unknown-linux-gnu/opt/smp/beam_hot.h:5252
> 
> 5252          c_p->seq_trace_lastcnt =
> unsigned_val(SEQ_TRACE_TOKEN_SERIAL(c_p)); Missing separate
> debuginfos, use: debuginfo-install glibc-2.12-1.212.el6_10.3.x86_64
> (gdb) bt
> #0  process_main (x_reg_array=0x20002, f_reg_array=0x2) at
> x86_64-unknown-linux-gnu/opt/smp/beam_hot.h:5252
> #1 0x00000000004641a4 in sched_thread_func (vesdp=0x2b8244840200) at
> beam/erl_process.c:8465
> #2  0x000000000069262a in thr_wrapper (vtwd=<value optimized out>)
> at pthread/ethread.c:118
> #3 0x00002b81f80f7dd5 in _L_unlock_48 () from /lib64/libpthread.so.0
> #4 0x00002b81f80f5eb3 in __find_thread_by_id () from
> /lib64/libpthread.so.0
> #5  0x0000000000000000 in ?? ()
> (gdb)
> 
> I am not sure how to " print the c_p parameter via its raw value
> (print *(Process*)0x.....)". Where should I take the value 0x.....
> from?
> 
> -----Original Message-----
> From: Mikael Pettersson [mailto:mikpelinux@REDACTED]
> Sent: Thursday, October 24, 2019 7:10 PM
> To: Bekes, Andras G (IST)
> Cc: Erlang Questions
> Subject: Re: [erlang-questions] Segfault with Erlang R22
> 
> On Thu, Oct 24, 2019 at 4:57 PM Bekes, Andras G
> <Andras.Bekes@REDACTED> wrote:
>  [...]  
> 
> I'd try to get a backtrace (bt command in gdb) from the crashed
> thread, then maybe print
> the c_p parameter via its raw value (print *(Process*)0x.....) if gdb
> insists that the value
> is optimized out.
> 
> /Mikael
> 
>  [...]  
>  [...]  
>  [...]  
> 


-- 
Wir haften nicht für die korrekte Funktion der in dieser eMail
enthaltenen Viren. We are not liable for correct function of the
viruses in this email! :)