Implement tagged var liveness analysis on RTL #1
Assignees
Comments
ghost
assigned
cstavr
pushed a commit
that referenced
this issue
Feb 7, 2013
This patch fixes a few problems of the SSH shell server that affect the interoperability with SSH clients in widespread use. First problem is that, whenever a channel_request message is received with want_reply=true, the reply ends up being sent to the servers channel id, not the clients channel id. This causes the client to terminate the connection. The easiest solution to the problem appears to be a new function in ssh_connection_manager.erl that translates the servers channel id before sending the reply (in the same manner as other functions do it). Second problem is in ssh_cli.erl. When an SSH client sends a window_change request between PTY allocation and starting the shell (which appears to happen with some clients), ssh_cli.erl crashes because #state.buf is yet 'undefined'. Allocating an empty buffer at PTY allocation time solves the problem. Affected SSH clients: - all clients based on SSH-2.0-TrileadSSH2Java_213 (problem #1) - SSH Term Pro (problem #2)
cstavr
pushed a commit
that referenced
this issue
Feb 7, 2013
When using the async thread pool and compressed files, when
an efile driver port instance is shutdown, the efile_drv
stop callback closes the file descriptor (a gzFile instance
actually) - this is dangerous if at the same time there's
an async thread performing an operation against the file,
for example calling invoke_read(), which can result in a
segmentation fault, or calling invoke_close() which double
closes the gzFile and this in turn causes 2 consecutive calls
to driver_free() against same gzFile instance (resulting in
later unexpected crashes in erl_bestfit_alloc.c for example).
The following test program makes the emulator crash when using
the async thread pool:
-module(t2).
-export([t/1]).
t(N) ->
file:delete("foo.bar"),
% Use of 'compressed' option, for creating/writing the file,
% is irrelevant. It only matters when opening it later for
% reads - a non-compressed file open with the 'compressed'
% option goes through an internal gzFile handle (instead of
% a plain integer fd), just like a compressed file.
%{ok, Fd} = file:open("foo.bar", [raw, write, binary]),
{ok, Fd} = file:open("foo.bar", [raw, write, binary, compressed]),
ok = file:write(Fd, <<"qwerty">>),
ok = file:close(Fd),
Pid = spawn_link(fun() ->
process_flag(trap_exit, true),
loop(N)
end),
Ref = erlang:monitor(process, Pid),
receive
{'DOWN', Ref, _, _, _} ->
ok
end.
loop(0) ->
ok;
loop(N) ->
Server = self(),
Pid = spawn(fun() ->
{ok, Fd} = file:open("foo.bar", [read, raw, binary, compressed]),
Server ! continue,
% Comment the file:read/2 call to make the file:close/1 call much
% more likely to crash or end up causing efile_drv to close twice
% the fd (gzFile), which will make the emulator crash later in the
% best fit allocator (erl_bestfit_alloc.c).
_ = file:read(Fd, 5),
file:close(Fd)
end),
receive continue -> ok end,
exit(Pid, shutdown),
loop(N - 1).
Running this test when using the async thread pool:
shell> erl +A 4
Erlang R15B03 (erts-5.9.3.1) [source] [64-bit] [smp:4:4] [async-threads:4] [hipe] [kernel-poll:false]
Eshell V5.9.3.1 (abort with ^G)
1> c(t2).
{ok,t2}
2> t2:t(500000).
Segmentation fault (core dumped)
When not using the async thread pool, there are no issues:
shell> erl
Erlang R15B03 (erts-5.9.3.1) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]
Eshell V5.9.3.1 (abort with ^G)
1> c(t2).
{ok,t2}
2> t2:t(500000).
ok
3>
An example stack trace when the crash happens because there's
an ongoing read operation is:
Thread 1 (Thread 0x7f021cf2c700 (LWP 10687)):
#0 updatewindow (strm=0x2691bf8, out=5) at zlib/inflate.c:338
#1 0x00000000005a2ba0 in inflate (strm=0x2691bf8, flush=0) at zlib/inflate.c:1141
#2 0x000000000055c46a in erts_gzread (file=0x2691bf8, buf=0x7f0215b29e80, len=5) at drivers/common/gzio.c:523
#3 0x00000000005849ef in invoke_read (data=0x26b2228) at drivers/common/efile_drv.c:1114
erlang#4 0x000000000050adcb in async_main (arg=0x7f021bf5cf40) at beam/erl_async.c:488
erlang#5 0x00000000005c21a0 in thr_wrapper (vtwd=0x7fff69c6ff10) at pthread/ethread.c:106
erlang#6 0x00007f021c573e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
erlang#7 0x00007f021c097cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6
erlang#8 0x0000000000000000 in ?? ()
And when there's an ongoing close operation when the driver
is stopped:
Thread 1 (Thread 0x7fe5f5654700 (LWP 747)):
#0 0x0000000000459b64 in bf_unlink_free_block (block=0x10b2a70, allctr=<optimized out>, flags=<optimized out>) at beam/erl_bestfit_alloc.c:792
#1 bf_unlink_free_block (flags=0, block=0x10b2a70, allctr=0x873380) at beam/erl_bestfit_alloc.c:822
#2 bf_get_free_block (allctr=0x873380, size=<optimized out>, cand_blk=<optimized out>, cand_size=<optimized out>, flags=0) at beam/erl_bestfit_alloc.c:869
#3 0x000000000044f0dd in mbc_alloc_block (alcu_flgsp=<synthetic pointer>, blk_szp=<synthetic pointer>, size=200, allctr=0x873380) at beam/erl_alloc_util.c:1198
erlang#4 mbc_alloc (allctr=0x873380, size=200) at beam/erl_alloc_util.c:1345
erlang#5 0x000000000045449b in do_erts_alcu_alloc (size=200, extra=0x873380, type=165) at beam/erl_alloc_util.c:3442
erlang#6 erts_alcu_alloc_thr_pref (type=165, extra=<optimized out>, size=192) at beam/erl_alloc_util.c:3520
erlang#7 0x000000000055c0bf in gz_open (mode=0x5d98b2 "rb", path=0x1103418 "foo.bar") at drivers/common/gzio.c:164
erlang#8 erts_gzopen (path=0x1103418 "foo.bar", mode=0x5d98b2 "rb") at drivers/common/gzio.c:307
erlang#9 0x0000000000584e47 in invoke_open (data=0x1103330) at drivers/common/efile_drv.c:1857
erlang#10 0x000000000050adcb in async_main (arg=0x7fe5f698af80) at beam/erl_async.c:488
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Implement a liveness analysis on RTL variables (only tagged) in order to reduce LLVM stack usage. Each RTL tagged var is mapped explicitly to a stack slot (with 'alloca') because it should be tracked by the Garbage Collector (marked with 'gcroot'). A trivial liveness analysis algorithm might significantly improve the performance of ErLLVM (especially in the cases of small recursive functions).
The text was updated successfully, but these errors were encountered: