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

Mikael Pettersson mikpe@REDACTED
Wed May 26 20:14:23 CEST 2010


Eric Liang wrote:
> 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 did:

> tar zxvf otp_src_R13B03.tar.gz
> cd otp_src_R13B03
> ./configure; make

The binary files of interest are bin/x86_64-unknown-linux-gnu/beam and 
erts/emulator/obj/x86_64-unknown-linux-gnu/opt/plain/erl_goodfit_alloc.o.

> > 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.)
> >  =20
> I've make a core dump 4 seconds before it crash,  as mentioned above,=20
> 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)

A core dump from a time point before the crash is useless. Either get a
core dump from the crash itself (execute `ulimit -c unlimited' in bash
before running the test), or attach gdb, continue the process, and wait
for gdb to receive control when the crash occurs.

> 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?

IP is the Instruction Pointer aka Program Counter. SP is the stack pointer.
The 'error 4' is a low-level error code which is irrelevant for us.


More information about the erlang-questions mailing list