<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 05/25/2010 07:05 PM, Mikael Pettersson wrote:
<blockquote cite="mid:19451.44811.595873.338827@pilspetsen.it.uu.se"
type="cite">
<pre wrap="">Eric Liang wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 05/24/2010 09:14 PM, Mikael Pettersson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Liang Yupeng wrote:
=20
</pre>
<blockquote type="cite">
<pre wrap="">Thanks for your reply, Mikael. Yes, it is beam.smp and 64-bit one.
=20
</pre>
</blockquote>
<pre wrap="">I have some doubts about that, see below.
=20
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">3. what tools (esp. gcc version) was this built with?
=20
</pre>
</blockquote>
<pre wrap="">I install erlang by the command apt-get:
=20
</pre>
</blockquote>
<pre wrap="">...
=20
</pre>
<blockquote type="cite">
<pre wrap="">Is this OK? Should I install a new beam-vm by source to get some debug=
</pre>
</blockquote>
</blockquote>
<pre wrap=""> info?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> =20
</pre>
</blockquote>
<pre wrap="">Run `strings -a /path/to/beam | fgrep GCC | sort -u'
(where /path/to/beam is the path to the beam executable).
=20
</pre>
</blockquote>
<pre wrap="">
sunny@dev-3:~$ strings -a /usr/lib/erlang/erts-5.7.2/bin/beam |
fgrep GCC | sort -u
sunny@dev-3:~$ strings -a /usr/lib/erlang/erts-5.7.2/bin/beam.smp |
fgrep GCC | sort -u
sunny@dev-3:~$
You see, neither beam nor beam.smp contains the string like GCC. :(
</pre>
</blockquote>
<pre wrap="">
That means your distro removed useful metadata from your binaries.
</pre>
<blockquote type="cite">
<pre wrap=""> sunny@dev-3:~/commands$ objdump -D
/usr/lib/erlang/erts-5.7.2/bin/beam > beam.objdump
sunny@dev-3:~/commands$ cat beam.objdump | grep -C 10 437e10
437ddd: e9 35 ff ff ff jmpq 437d17
<erts_gfalc_init+0x317>
437de2: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
437de8: 48 2d 20 e2 00 00 sub $0xe220,%rax
437dee: 31 d2 xor %edx,%edx
437df0: 48 f7 b7 10 03 00 00 divq 0x310(%rdi)
437df7: 05 c0 00 00 00 add $0xc0,%eax
437dfc: e9 16 ff ff ff jmpq 437d17
<erts_gfalc_init+0x317>
437e01: 66 66 66 66 66 66 2e nopw %cs:0x0(%rax,%rax,1)
437e08: 0f 1f 84 00 00 00 00
437e0f: 00
437e10: 4c 8b 06 mov (%rsi),%r8
437e13: 49 83 e0 f8 and $0xfffffffffffffff8,%r8
437e17: 49 81 f8 1f 02 00 00 cmp $0x21f,%r8
437e1e: 77 40 ja 437e60
<erts_gfalc_init+0x460>
437e20: 49 8d 50 e0 lea -0x20(%r8),%rdx
437e24: 48 c1 ea 03 shr $0x3,%rdx
437e28: 4c 8b 4e 08 mov 0x8(%rsi),%r9
437e2c: 4d 85 c9 test %r9,%r9
437e2f: 74 4f je 437e80
<erts_gfalc_init+0x480>
437e31: 48 8b 46 10 mov 0x10(%rsi),%rax
437e35: 49 89 41 10 mov %rax,0x10(%r9)
</pre>
</blockquote>
<pre wrap="">
Again, this shows that your distro butchered the symbol table in
your Erlang executable (beam). In reality erts_gfalc_init is only
two instructions long and subsequent instructions belong to other named
functions in erts/emulator/beam/erl_goodfit_alloc.c, but here they
are incorrectly labeled as erts_gfalc_init+0x???.
Anyway, I did a build from source with gcc-4.4.4 and matched the
object code above to what I got, and it seems that unlink_free_block()
in erl_goodfit_alloc.c was called with a NULL `block' parameter.
This could be from the call at the end of get_free_block(), or via
the ->unlink_free_block callback in erl_alloc_util.c. We really
need a call stack dump at the point of the crash.
</pre>
</blockquote>
Thanks for your work, Mikael.<br>
<br>
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.<br>
<br>
I'm now working on get the debug-info of that package in apt-get
sources, but it also stalled. However, I've asked this in ubuntu's
mailling-list, it should be worked out soon( I'll reply this mail then).<br>
<br>
<blockquote cite="mid:19451.44811.595873.338827@pilspetsen.it.uu.se"
type="cite">
<pre wrap="">
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.)
</pre>
</blockquote>
I've make a core dump 4 seconds before it crash, as mentioned above,
because don't get the right symbols, it just with some quesion-marks:<br>
<blockquote>Core was generated by `/usr/lib/erlang/erts-5.7.2/bin/beam'.<br>
#0 0x00007f0a28ecd5a9 in ?? ()<br>
(gdb) whe<br>
#0 0x00007f0a28ecd5a9 in ?? ()<br>
#1 0x0000000000000000 in ?? ()<br>
(gdb) <br>
</blockquote>
yes, I've not get the core when it crashed. Maybe my OS setting on core
dump needs to be fixed, or maybe the beam which started by epmd does
not generate core? Anyway, this also needs to be worked out.<br>
<br>
Look back the initial error:<br>
<blockquote>segfault at 0 ip 0000000000437e10 sp 00007fffce250948 error
4 in beam[400000+174000]<br>
</blockquote>
Would you mind tell me what's the meaning of -ip-/-sp-, and what does
-error 4- means? Thanks in advance. Also, any other suggestions would
be appreciated.<br>
<br>
Thanks,<br>
Eric<br>
</body>
</html>