Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

double free of mutex in caml_finalize_channel #7486

Closed
vicuna opened this issue Feb 17, 2017 · 2 comments
Closed

double free of mutex in caml_finalize_channel #7486

vicuna opened this issue Feb 17, 2017 · 2 comments
Milestone

Comments

@vicuna
Copy link

vicuna commented Feb 17, 2017

Original bug ID: 7486
Reporter: aalekseyev
Status: resolved (set by @xavierleroy on 2017-02-17T13:27:55Z)
Resolution: fixed
Priority: normal
Severity: crash
Version: 4.03.0
Target version: 4.05.0 +dev/beta1/beta2/beta3/rc1
Fixed in version: 4.05.0 +dev/beta1/beta2/beta3/rc1
Category: standard library
Related to: #7457

Bug description

There is a possibility of double free of an io channel mutex in caml_finalize_channel.

In particular, this code frees the mutex every time the last channel reference gets finalized:

CAMLexport void caml_finalize_channel(value vchan)
{
struct channel * chan = Channel(vchan);
if (--chan->refcount > 0) return;
if (caml_channel_mutex_free != NULL) (*caml_channel_mutex_free)(chan);

This can happen multiple times because a channel can be brought back from the dead by caml_ml_out_channels_list.

A possible fix would be to set the "mutex" field to NULL (maybe in the body of caml_channel_mutex_free)

Steps to reproduce

cat > bug.ml <<EOF

let _t () = Thread.create (fun () -> ()) ()

let () =
let fd, fd2 = Unix.pipe () in
Unix.close fd2;
let chan = Unix.out_channel_of_descr fd in
match Printf.fprintf chan "%s%!" (String.make 60000 'x') with
| exception _exn -> Unix.close fd
| () -> assert false

let () =
for _x = 1 to 2 do
let () = Pervasives.flush_all () in
let () = Gc.full_major () in
()
done

EOF

PATH=/j/office/app/ocaml/builds/4.03.0-4+j2+fp-cent6_20161104_134704GMT/bin:"$PATH"

ocamlopt.opt -I +threads -o bug.cmx -c -impl bug.ml
ocamlopt.opt -ccopt -Wl unix.cmxa -I +threads threads.cmxa ./bug.cmx -o bug.exe
./bug.exe

Additional information

*** glibc detected *** ./bug.exe: double free or corruption (fasttop): 0x000000000116e760 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3bfbc75f3e]
/lib64/libc.so.6[0x3bfbc78d8d]
./bug.exe[0x4433e3]
./bug.exe[0x455379]
./bug.exe[0x44f46e]
./bug.exe(caml_gc_full_major+0x1a)[0x45baba]
./bug.exe[0x414d36]
./bug.exe[0x4120d9]
./bug.exe[0x46254a]
./bug.exe[0x44a575]
./bug.exe[0x44a5cc]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x3bfbc1ed1d]
./bug.exe[0x411e69]
======= Memory map: ========
00400000-0047b000 r-xp 00000000 fd:04 14466668 /home/aalekseyev/tmp/bug.exe
0067b000-006a0000 rw-p 0007b000 fd:04 14466668 /home/aalekseyev/tmp/bug.exe
006a0000-006ad000 rw-p 00000000 00:00 0
0115e000-01203000 rw-p 00000000 00:00 0 [heap]
3bfb400000-3bfb420000 r-xp 00000000 fd:00 131236 /lib64/ld-2.12.so
3bfb61f000-3bfb620000 r--p 0001f000 fd:00 131236 /lib64/ld-2.12.so
3bfb620000-3bfb621000 rw-p 00020000 fd:00 131236 /lib64/ld-2.12.so
3bfb621000-3bfb622000 rw-p 00000000 00:00 0
3bfbc00000-3bfbd8a000 r-xp 00000000 fd:00 131241 /lib64/libc-2.12.so
3bfbd8a000-3bfbf8a000 ---p 0018a000 fd:00 131241 /lib64/libc-2.12.so
3bfbf8a000-3bfbf8e000 r--p 0018a000 fd:00 131241 /lib64/libc-2.12.so
3bfbf8e000-3bfbf90000 rw-p 0018e000 fd:00 131241 /lib64/libc-2.12.so
3bfbf90000-3bfbf94000 rw-p 00000000 00:00 0
3bfc000000-3bfc083000 r-xp 00000000 fd:00 131242 /lib64/libm-2.12.so
3bfc083000-3bfc282000 ---p 00083000 fd:00 131242 /lib64/libm-2.12.so
3bfc282000-3bfc283000 r--p 00082000 fd:00 131242 /lib64/libm-2.12.so
3bfc283000-3bfc284000 rw-p 00083000 fd:00 131242 /lib64/libm-2.12.so
3bfc400000-3bfc402000 r-xp 00000000 fd:00 131247 /lib64/libdl-2.12.so
3bfc402000-3bfc602000 ---p 00002000 fd:00 131247 /lib64/libdl-2.12.so
3bfc602000-3bfc603000 r--p 00002000 fd:00 131247 /lib64/libdl-2.12.so
3bfc603000-3bfc604000 rw-p 00003000 fd:00 131247 /lib64/libdl-2.12.so
3bfc800000-3bfc817000 r-xp 00000000 fd:00 131246 /lib64/libpthread-2.12.so
3bfc817000-3bfca17000 ---p 00017000 fd:00 131246 /lib64/libpthread-2.12.so
3bfca17000-3bfca18000 r--p 00017000 fd:00 131246 /lib64/libpthread-2.12.so
3bfca18000-3bfca19000 rw-p 00018000 fd:00 131246 /lib64/libpthread-2.12.so
3bfca19000-3bfca1d000 rw-p 00000000 00:00 0
3bff000000-3bff016000 r-xp 00000000 fd:00 131277 /lib64/libgcc_s-4.4.7-20120601.so.1
3bff016000-3bff215000 ---p 00016000 fd:00 131277 /lib64/libgcc_s-4.4.7-20120601.so.1
3bff215000-3bff216000 rw-p 00015000 fd:00 131277 /lib64/libgcc_s-4.4.7-20120601.so.1
7f2d90000000-7f2d90021000 rw-p 00000000 00:00 0
7f2d90021000-7f2d94000000 ---p 00000000 00:00 0
7f2d941cd000-7f2d954d8000 rw-p 00000000 00:00 0
7f2d9550d000-7f2d9550e000 rw-p 00000000 00:00 0
7ffd33eaa000-7ffd33ebf000 rw-p 00000000 00:00 0 [stack]
7ffd33ed3000-7ffd33ed4000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
./reproduce: line 26: 1967 Aborted ./bug.exe

@vicuna
Copy link
Author

vicuna commented Feb 17, 2017

Comment author: @xavierleroy

This is essentially the same bug as #7457, and the fix suggested in this PR is the one that was implemented for #7457. You can check by testing the soon-to-be-announced beta version for 4.05: the problem should go away.

@vicuna vicuna closed this as completed Feb 17, 2017
@vicuna
Copy link
Author

vicuna commented Feb 17, 2017

Comment author: aalekseyev

Ah, good. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant