[erlang-bugs] segv in 64-bit SMP emulator (R12B-5) in erts_ddll_proc_dead
Chris Newcombe
chris.newcombe@REDACTED
Mon Apr 13 22:39:28 CEST 2009
I'm testing this linked-in driver (JSON parser/encoder)
http://github.com/davisp/eep0018/tree/master
The problem occurs with the 64-bit SMP emulator. I'm building and running
on Red Hat Enterprise Linux 5 (gcc version 4.1.2 20070626 (Red Hat
4.1.2-14)) -- see full details at end of email.
If I use the linked-in driver from more than one process at a time, it
frequently causes beam to segv with:
> 0 erts_ddll_proc_dead PC=0x0044eff3, FP=0x41f5a0e0
[/rhel5pdi/cnewcom/Erlang/erlang/erts-5.6.5/bin/beam.smp]
1 continue_exit_process PC=0x004a92d4, FP=0x41f5a190
[/rhel5pdi/cnewcom/Erlang/erlang/erts-5.6.5/bin/beam.smp]
2 erts_do_exit_process PC=0x004a9137, FP=0x41f5a1c0
[/rhel5pdi/cnewcom/Erlang/erlang/erts-5.6.5/bin/beam.smp]
3 process_main PC=0x00538b40, FP=0x41f5c0d0
[/rhel5pdi/cnewcom/Erlang/erlang/erts-5.6.5/bin/beam.smp]
4 exit_sched_thr PC=0x004a3082, FP=0x41f5c0f0
[/rhel5pdi/cnewcom/Erlang/erlang/erts-5.6.5/bin/beam.smp]
5 reinit_mutexes PC=0x005cafe9, FP=0x41f5c120
[/rhel5pdi/cnewcom/Erlang/erlang/erts-5.6.5/bin/beam.smp]
(I haven't yet built the emulator with -g, so I don't have any more
information than that, sorry)
I suspect the problem occurs because my test code was calling
erl_ddll:load_driver() from every process that ever needs to use the
driver. (I know that's not optimum; this was only a test hack, not
production code.)
The problem seems to disappear if I switch to the non-SMP emulator (I can't
rule it out, but it hasn't occured in a long test-run).
The problem also seems to disappear if I use the 32-bit SMP emulator
(however, in that case I'm running on a different OS and compiler (gcc
version 3.2.3 20030502 (Red Hat Linux 3.2.3-47)
My code looked like:
112 safe_json_to_term(JsonTextBin) ->
113
114 %% As ErlangFastJSON currently returns an untagged message and
115 %% does a non-selective receive, it can return entirely the
wrong
116 %% response. So we need to use a temporary process for now.
117
118 CallerPid = self(),
119
120 WorkerPid = spawn_link(
121 fun() ->
122
123 eep0018:start_driver(code:priv_dir(fast_json)),
124
125 JsonTerm = eep0018:json_to_term(JsonTextBin),
126
127 CallerPid ! {self(), JsonTerm}
128 end),
129
130 JsonTerm = receive {WorkerPid, T} -> T end,
131
132 %% TODO: json_to_term does not currently return the 'left over'
tail.
133
134 {ok, JsonTerm, []}.
The erlang code in the driver looks like:
json_to_term(Json) when is_binary(Json) ->
% The null byte is important for bare literals. Without it
% yajl will throw a fit because it doesn't think it's finished
% parsing correctly.
[] = erlang:port_control(drv_port(), 1, <<Json/binary, 0:8>>),
receive
Term ->
Term
end.
start_driver(LibDir) ->
case erl_ddll:load_driver(LibDir, "eep0018_drv") of
ok ->
ok;
{error, already_loaded} ->
ok;
%ok = erl_ddll:reload_driver(LibDir, "eep0018_drv");
{error, Error} ->
exit(erl_ddll:format_error(Error))
end.
drv_port() ->
case get(eep0018_drv_port) of
undefined ->
Port = open_port({spawn, "eep0018_drv"}, [binary]),
put(eep0018_drv_port, Port),
Port;
Port ->
Port
end.
Here's more details about the OS/compiler on which the problem occurs.
% cat /etc/redhat-release
Red Hat Enterprise Linux Client release 5.1 (Tikanga)
% gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
Kernel:
% uname -a
Linux 2.6.18-53.1.14.el5 #1 SMP Tue Feb 19 07:18:46 EST 2008 x86_64 x86_64
x86_64 GNU/Linux
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20090413/005684a4/attachment.htm>
More information about the erlang-bugs
mailing list