[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