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.

Sign up for GitHub

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

Jump to bottom

More memory leaks found with address sanitizer #382

Closed
vanc opened this issue Sep 24, 2019 · 23 comments · Fixed by #442
Closed

More memory leaks found with address sanitizer #382

vanc opened this issue Sep 24, 2019 · 23 comments · Fixed by #442
Labels
bug

Comments

@vanc
Copy link

vanc commented Sep 24, 2019

This can be considered a continuation from issue #379. I didn't report all issues as I didn't know #379 was resolved so quickly. Thank you guys!

The first one was related to signal handling. It was from test-signal.lua.

=================================================================
==6844==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 128 byte(s) in 1 object(s) allocated from:
#0 0x4e8196 in realloc /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:165
#1 0x7f14b2dbbbe0 in maybe_resize /home/lua-projects/libuv/src/unix/core.c:850:14
#2 0x7f14b2dbbbe0 in uv__io_start /home/lua-projects/libuv/src/unix/core.c:889
#3 0x7f14b2dded06 in uv__signal_loop_once_init /home/lua-projects/libuv/src/unix/signal.c:273:3
#4 0x7f14b2dded06 in uv_signal_init /home/lua-projects/libuv/src/unix/signal.c:320
#5 0x7f14b2dd4af2 in uv_loop_init /home/lua-projects/libuv/src/unix/loop.c:72:9
#6 0x7f14b2d82b3f in luaopen_luv /home/lua-projects/luv/luv.c:674:11
#7 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/lj_vm.S:809

SUMMARY: AddressSanitizer: 128 byte(s) leaked in 1 allocation(s).
"exit" { signal = 0, code = 1, pid = 6844 }
Uncaught Error: ./tests/test-signal.lua:25: assertion failed!

After finish all tests, more leaks were dumped out.

ok 98 work - test threadpool
#2 failed tests

=================================================================
==6710==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 312 byte(s) in 1 object(s) allocated from:
#0 0x4e7d07 in malloc /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
#1 0x7f52a138d084 in luv_newuserdata /home/lua-projects/lua-modules/luv/src/handle.c:20:18
#2 0x7f52a138d084 in luv_new_tty /home/lua-projects/lua-modules/luv/src/tty.c:32
#3 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/lj_vm.S:809

Direct leak of 256 byte(s) in 1 object(s) allocated from:
#0 0x4e8196 in realloc /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:165
#1 0x7f52a13bbbe0 in maybe_resize /home/lua-projects/libuv/src/unix/core.c:850:14
#2 0x7f52a13bbbe0 in uv__io_start /home/lua-projects/libuv/src/unix/core.c:889
#3 0x7f52a13e72bf in uv_read_start /home/lua-projects/libuv/src/unix/stream.c:1581:3
#4 0x7f52a1389a77 in luv_read_start /home/lua-projects/lua-modules/luv/src/stream.c:130:9
#5 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/lj_vm.S:809

Direct leak of 96 byte(s) in 3 object(s) allocated from:
#0 0x4e7d07 in malloc /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
#1 0x7f52a13a6c1c in luv_setup_req /home/lua-projects/lua-modules/luv/src/lreq.c:34:22
#2 0x7f52a139c7a4 in luv_fs_opendir /home/lua-projects/lua-modules/luv/src/fs.c:788:15
#3 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/lj_vm.S:809

Direct leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x4e7d07 in malloc /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
#1 0x7f52a13c154d in uv__fs_opendir /home/lua-projects/libuv/src/unix/fs.c:451:9
#2 0x7f52a13c154d in uv__fs_work /home/lua-projects/libuv/src/unix/fs.c:1421
#3 0x7f52a13b1ee1 in worker /home/lua-projects/libuv/src/threadpool.c:122:5
#4 0x7f52a51426da in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da)

Direct leak of 46 byte(s) in 2 object(s) allocated from:
#0 0x4e7d07 in malloc /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
#1 0x7f52a13ad3ff in uv__malloc /home/lua-projects/libuv/src/uv-common.c:77:12
#2 0x7f52a13ad3ff in uv__strdup /home/lua-projects/libuv/src/uv-common.c:57
#3 0x7f52a13ad3ff in uv__unknown_err_code /home/lua-projects/libuv/src/uv-common.c:159
#4 0x7f52a13ad3ff in uv_err_name /home/lua-projects/libuv/src/uv-common.c:182
#5 0x7f52a13a247d in luv_error /home/lua-projects/lua-modules/luv/src/util.c:44:32
#6 0x7f52a13a247d in luv_os_setenv /home/lua-projects/lua-modules/luv/src/misc.c:395
#7 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/lj_vm.S:809

Direct leak of 46 byte(s) in 2 object(s) allocated from:
#0 0x4e7d07 in malloc /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
#1 0x7f52a13ae50f in uv__malloc /home/lua-projects/libuv/src/uv-common.c:77:12
#2 0x7f52a13ae50f in uv__strdup /home/lua-projects/libuv/src/uv-common.c:57
#3 0x7f52a13ae50f in uv__unknown_err_code /home/lua-projects/libuv/src/uv-common.c:159
#4 0x7f52a13ae50f in uv_strerror /home/lua-projects/libuv/src/uv-common.c:205
#5 0x7f52a13a2487 in luv_error /home/lua-projects/lua-modules/luv/src/util.c:44:53
#6 0x7f52a13a2487 in luv_os_setenv /home/lua-projects/lua-modules/luv/src/misc.c:395
#7 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/lj_vm.S:809

Direct leak of 46 byte(s) in 2 object(s) allocated from:
#0 0x4e7d07 in malloc /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
#1 0x7f52a13ad3ff in uv__malloc /home/lua-projects/libuv/src/uv-common.c:77:12
#2 0x7f52a13ad3ff in uv__strdup /home/lua-projects/libuv/src/uv-common.c:57
#3 0x7f52a13ad3ff in uv__unknown_err_code /home/lua-projects/libuv/src/uv-common.c:159
#4 0x7f52a13ad3ff in uv_err_name /home/lua-projects/libuv/src/uv-common.c:182
#5 0x7f52a13a24a5 in luv_error /home/lua-projects/lua-modules/luv/src/util.c:45:3
#6 0x7f52a13a24a5 in luv_os_setenv /home/lua-projects/lua-modules/luv/src/misc.c:395
#7 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/lj_vm.S:809

Direct leak of 2 byte(s) in 1 object(s) allocated from:
#0 0x4e7d07 in malloc /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
#1 0x7f52a13ac452 in uv__malloc /home/lua-projects/libuv/src/uv-common.c:77:12
#2 0x7f52a13ac452 in uv__strdup /home/lua-projects/libuv/src/uv-common.c:57
#3 0x7f52a13c6fcf in uv_fs_opendir /home/lua-projects/libuv/src/unix/fs.c:1700:3
#4 0x7f52a139c87b in luv_fs_opendir /home/lua-projects/lua-modules/luv/src/fs.c:794:3
#5 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/lj_vm.S:809

Indirect leak of 32816 byte(s) in 1 object(s) allocated from:
#0 0x4e7d07 in malloc /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
#1 0x7f52a54399b5 in __alloc_dir /build/glibc-OTsEL5/glibc-2.27/dirent/../sysdeps/posix/opendir.c:216
#2 0x7f52a54399b5 in opendir_tail /build/glibc-OTsEL5/glibc-2.27/dirent/../sysdeps/posix/opendir.c:136
#3 0x7f52a54399b5 in opendir /build/glibc-OTsEL5/glibc-2.27/dirent/../sysdeps/posix/opendir.c:190

Indirect leak of 800 byte(s) in 1 object(s) allocated from:
#0 0x4e7d07 in malloc /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
#1 0x7f52a13a97fa in push_fs_result /home/lua-projects/lua-modules/luv/src/fs.c:308:22
#2 0x7f52a13a9238 in luv_fs_cb /home/lua-projects/lua-modules/luv/src/fs.c:364:15
#3 0x7f52a13b14c3 in uv__work_done /home/lua-projects/libuv/src/threadpool.c:313:5
#4 0x7f52a13b8c6e in uv__async_io /home/lua-projects/libuv/src/unix/async.c:147:5
#5 0x7f52a13ccecc in uv__io_poll /home/lua-projects/libuv/src/unix/linux-core.c:384:11
#6 0x7f52a13b9a37 in uv_run /home/lua-projects/libuv/src/unix/core.c:373:5
#7 0x7f52a13849ec in luv_run /home/lua-projects/lua-modules/luv/src/loop.c:34:13
#8 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/lj_vm.S:809

Indirect leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x4e7d07 in malloc /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
#1 0x7f52a13a4a06 in luv_setup_handle /home/lua-projects/lua-modules/luv/src/lhandle.c:31:25
#2 0x7f52a138d0e4 in luv_new_tty /home/lua-projects/lua-modules/luv/src/tty.c:38:18
#3 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/lj_vm.S:809

SUMMARY: AddressSanitizer: 34508 byte(s) leaked in 16 allocation(s).
@vanc
Copy link
Author

vanc commented Sep 24, 2019

This was tested against the current HEAD revision cf89aea.

@squeek502 squeek502 added the bug label Sep 24, 2019
@squeek502
Copy link
Member

Out of curiosity, how did you go about building/testing with AddressSanitizer?

@zhaozg
Copy link
Member

zhaozg commented Sep 25, 2019

@squeek502 do you have any idea? handle or req relatived not do correct gc?

@squeek502
Copy link
Member

Not sure yet, would like to get AddressSanitizer set up in the same way that @vanc has it to test things.

@squeek502
Copy link
Member

@vanc I think a few of these have been/will be addressed by #387 / #389

Could you please detail your process for compiling/running with AddressSanitizer so I can run the same thing you are?

@vanc
Copy link
Author

vanc commented Oct 7, 2019

@squeek502 Yes, I can confirm some of the leaks are now gone.

The only remaining leaks are:

=================================================================
==28591==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 312 byte(s) in 1 object(s) allocated from:
#0 0x4e7d07 in malloc /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
#1 0x7f442dd8d404 in luv_newuserdata /home//home/lua-projects/luv/src/handle.c:20:18
#2 0x7f442dd8d404 in luv_new_tty /home//home/lua-projects/luv/src/tty.c:32
#3 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/../../../../x86_64_clang_san-address_opt3_tst_nopie_ossl11_objs/share/src/luajit/src/lj_vm.S:809

Direct leak of 128 byte(s) in 1 object(s) allocated from:
#0 0x4e8196 in realloc /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:165
#1 0x7f442ddbbd30 in maybe_resize /home/lua-projects/libuv/src/unix/core.c:850:14
#2 0x7f442ddbbd30 in uv__io_start /home/lua-projects/libuv/src/unix/core.c:889
#3 0x7f442dddee56 in uv__signal_loop_once_init /home/lua-projects/libuv/src/unix/signal.c:273:3
#4 0x7f442dddee56 in uv_signal_init /home/lua-projects/libuv/src/unix/signal.c:320
#5 0x7f442ddd4c42 in uv_loop_init /home/lua-projects/libuv/src/unix/loop.c:72:9
#6 0x7f442dd82def in luaopen_luv /home//home/lua-projects/luv/../../../../x86_64_clang_san-address_opt3_nopie_ossl11_objs/share/src/lua-modules/luv/luv_so.c:693:11
#7 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/../../../../x86_64_clang_san-address_opt3_tst_nopie_ossl11_objs/share/src/luajit/src/lj_vm.S:809

Indirect leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x4e7d07 in malloc /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
#1 0x7f442dda4766 in luv_setup_handle /home//home/lua-projects/luv/src/lhandle.c:31:25
#2 0x7f442dd8d464 in luv_new_tty /home//home/lua-projects/luv/src/tty.c:38:18
#3 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/../../../../x86_64_clang_san-address_opt3_tst_nopie_ossl11_objs/share/src/luajit/src/lj_vm.S:809

SUMMARY: AddressSanitizer: 472 byte(s) leaked in 3 allocation(s).

@vanc
Copy link
Author

vanc commented Oct 7, 2019

Could you please detail your process for compiling/running with AddressSanitizer so I can run the same thing you are?

I used my own Makefiles which contain references to other non-open source code. I cannot share it without modification at the moment. I tried to hack the current cmake based one and couldn't make it work. The tricky part was that LuaJIT must be compiled with the sanitizer options and luv.so should use the same source code and compile with the same sanitizer options.

@squeek502
Copy link
Member

Could you share just the sanitizer options you're compiling LuaJIT with? That's the part that I've been running into issues with.

@squeek502
Copy link
Member

squeek502 commented Oct 9, 2019 •
edited
Loading

Ok, got something mostly working to test this. Had to use LeakSanitizer instead of AddressSanitizer because of LuaJIT/LuaJIT#517 and I couldn't get suppressions/blacklists to work to avoid it.

Command I'm running from within a luv checkout:

CMAKE_OPTIONS="-DCMAKE_C_COMPILER=clang -DCMAKE_C_FLAGS=-fsanitize=leak" LSAN_OPTIONS="suppressions=$PWD/suppr.supp" make

where suppr.supp contains:

leak:buildvm

(to suppress leaks in the LuaJIT build process during buildvm)

The signal leak is caused by the following:

  • test-signal spawns a child process using uv.exepath() (the ASAN/LSAN compiled LuaJIT) and the child uses os.exit(7) to exit
  • As mentioned in tap: Only call os.exit on failure #389, os.exit bypasses lua_close so the memory is not cleaned up properly and causes the leak checker to detect leaks
  • LSAN changes the exit code so the test in test-signal that asserts the exit code fails

Not really sure how best to solve this problem, since as far as I can tell its a false-positive, but I'm not really sure how to go about getting this test to pass while ASAN/LSAN is running.

@squeek502 squeek502 mentioned this issue Oct 9, 2019
Merged
@squeek502
Copy link
Member

squeek502 commented Oct 9, 2019 •
edited
Loading

@vanc Try running the branch of #394 (EDIT: now merged into master) when you get a chance. I was able to run LeakSanitizer cleanly on it.

@squeek502 squeek502 mentioned this issue Oct 9, 2019
Closed
@vanc
Copy link
Author

vanc commented Oct 16, 2019

Sorry for the late response. I reran the tests with current HEAD revision 778e97e and found more leaks than last time.

Direct leak of 128 byte(s) in 1 object(s) allocated from:
    #0 0x4e8196 in realloc /home/projects/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:165
    #1 0x7f59e18b0c22 in maybe_resize /home/lua-projects/libuv/src/unix/core.c:850:14
    #2 0x7f59e18b0c22 in uv__io_start /home/lua-projects/libuv/src/unix/core.c:889
    #3 0x7f59e18d4a26 in uv__signal_loop_once_init /home/lua-projects/libuv/src/unix/signal.c:273:3
    #4 0x7f59e18d4a26 in uv_signal_init /home/lua-projects/libuv/src/unix/signal.c:320
    #5 0x7f59e18ca352 in uv_loop_init /home/lua-projects/libuv/src/unix/loop.c:72:9
    #6 0x7f59e1879a2f in luaopen_luv /home/lua-projects/lua-modules/luv/../../../../x86_64_clang_san-address_dbg_opt3_nopie_ossl11_objs/share/src/lua-modules/luv/luv_so.c:693:11
    #7 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/../../../../x86_64_clang_san-address_opt3_tst_nopie_ossl11_objs/share/src/luajit/src/lj_vm.S:809

Direct leak of 120 byte(s) in 1 object(s) allocated from:
    #0 0x4e7d07 in malloc /home/projects/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
    #1 0x7f59e187cc3f in luv_newuserdata /home/lua-projects/lua-modules/luv/src/handle.c:20:18
    #2 0x7f59e187cc3f in luv_new_check /home/lua-projects/lua-modules/luv/src/check.c:27
    #3 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/../../../../x86_64_clang_san-address_opt3_tst_nopie_ossl11_objs/share/src/luajit/src/lj_vm.S:809

Indirect leak of 312 byte(s) in 1 object(s) allocated from:
    #0 0x4e7d07 in malloc /home/projects/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
    #1 0x7f59e1882da4 in luv_newuserdata /home/lua-projects/lua-modules/luv/src/handle.c:20:18
    #2 0x7f59e1882da4 in luv_new_tty /home/lua-projects/lua-modules/luv/src/tty.c:32
    #3 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/../../../../x86_64_clang_san-address_opt3_tst_nopie_ossl11_objs/share/src/luajit/src/lj_vm.S:809

Indirect leak of 32 byte(s) in 1 object(s) allocated from:
    #0 0x4e7d07 in malloc /home/projects/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
    #1 0x7f59e18990f6 in luv_setup_handle /home/lua-projects/lua-modules/luv/src/lhandle.c:31:25
    #2 0x7f59e187cc91 in luv_new_check /home/lua-projects/lua-modules/luv/src/check.c:33:18
    #3 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/../../../../x86_64_clang_san-address_opt3_tst_nopie_ossl11_objs/share/src/luajit/src/lj_vm.S:809

Indirect leak of 32 byte(s) in 1 object(s) allocated from:
    #0 0x4e7d07 in malloc /home/projects/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146
    #1 0x7f59e18990f6 in luv_setup_handle /home/lua-projects/lua-modules/luv/src/lhandle.c:31:25
    #2 0x7f59e1882e00 in luv_new_tty /home/lua-projects/lua-modules/luv/src/tty.c:38:18
    #3 0x5cb016 in lj_BC_FUNCC /home/lua-projects/luajit/src/../../../../x86_64_clang_san-address_opt3_tst_nopie_ossl11_objs/share/src/luajit/src/lj_vm.S:809

SUMMARY: AddressSanitizer: 624 byte(s) leaked in 5 allocation(s).

@squeek502
Copy link
Member

squeek502 commented Oct 16, 2019 •
edited
Loading

Are any of the tests failing for you when running AddressSanitizer?

@vanc
Copy link
Author

vanc commented Oct 17, 2019

Right, there was one failure in test-leaks.lua.

  ./tests/test-leaks.lua:24: assertion failed!
  stack traceback:
  	[C]: in function 'assert'
  	./tests/test-leaks.lua:24: in function 'bench'
  	./tests/test-leaks.lua:39: in function 'fn'
  	./lib/tap.lua:53: in function <./lib/tap.lua:42>
  	[C]: in function 'xpcall'
  	./lib/tap.lua:42: in function 'run'
  	./lib/tap.lua:138: in function 'tap'
  	tests/run.lua:23: in main chunk
  	[C]: at 0x0051e050

If comment out the "assert" in line 24, there is no more leaks.

@vanc
Copy link
Author

vanc commented Oct 17, 2019

So any errors from a Lua program would cause some resources not properly garbage-collected. Sounds like a bug to me.

@squeek502
Copy link
Member

squeek502 commented Oct 17, 2019 •
edited
Loading

So any errors from a Lua program would cause some resources not properly garbage-collected.

This is only partially true due to how our test runner works. The leaks come from os.exit being called from Lua in our test runner when a test fails. This is the only way to return a non-zero exit code from Lua, but it also bypasses lua_close/garbage collection at shutdown, so it causes leaks. Not much we can do about that as far as I'm aware.

Normal Lua execution/syntax errors wouldn't cause this, only os.exit calls. You can confirm this by commenting out the os.exit here and re-running the tests with ASAN.

@vanc
Copy link
Author

vanc commented Oct 17, 2019

I see. Thanks @squeek502.

@vanc
Copy link
Author

vanc commented Oct 24, 2019

The following patch would avoid exit leak when some unit tests fail.

By passing true to os.exit(), the Lua state would be closed before exit() is called.

--- a/luv/lib/tap.lua
+++ b/luv/lib/tap.lua
@@ -105,7 +105,7 @@ local function run()
   uv.run()
 
   if failed ~= 0 then
-    os.exit(-failed)
+    os.exit(-failed, true)
   end
 end

@squeek502
Copy link
Member

squeek502 commented Oct 24, 2019 •
edited
Loading

Nice, want to make a PR for that? Looks like the second parameter of os.exit was added in Lua 5.2 (and backported to LuaJIT).

squeek502 added a commit to squeek502/luv that referenced this issue Oct 28, 2019
@squeek502
tap: Make os.exit call lua_close on Lua versions that support it
8ca00dc 
Second optional argument to os.exit is a boolean that determines if lua_close should be called while exiting. This was added in PUC Lua 5.2 and backported to LuaJIT.

This allows the tests to provide accurate memory leak information even with failing tests (memory leak info will still be inaccurate with failing tests on PUC Lua 5.1, since PUC Lua 5.1 os.exit bypasses lua_close).

Thanks to @vanc for the fix, see luvit#382 (comment)
This was referenced Oct 28, 2019
Merged
Merged
@zhaozg
Copy link
Member

zhaozg commented Nov 4, 2019

ok, here https://travis-ci.org/luvit/luv/jobs/606661363#L737-L928

It seams that kill process created by uv_spawn some memory not free, maybe lua_State not close

@squeek502
Copy link
Member

squeek502 commented Nov 4, 2019 •
edited
Loading

It's actually the "invalid command" test that is causing that.

  test("invalid command", function (print, p, expect, uv)
    local handle, err
    handle, err = uv.spawn("ksjdfksjdflkjsflksdf", {}, function(exit, code)
      assert(false)
    end)
    assert(handle == nil)
    assert(err)
  end)

It's not failing the build because it's the child PID that's exiting with leaks.

@zhaozg
Copy link
Member

zhaozg commented Nov 4, 2019

ok, there's any way to clean that?

luv/src/process.c

Lines 271 to 276 in 1e9a020

if (ret < 0) {
/* The async callback is required here because luajit GC may reclaim the
* luv handle before libuv is done closing it down.
*/
uv_close((uv_handle_t*)handle, luv_spawn_close_cb);
return luv_error(L, ret);
need more process?

@zhaozg zhaozg mentioned this issue Nov 4, 2019
Closed
@zhaozg
Copy link
Member

zhaozg commented Nov 4, 2019 •
edited
Loading

https://github.com/libuv/libuv/blob/780c08a63efb65aed65da57c36f1c5b10f25cc1d/test/test-spawn.c#L218-L221

@squeek502
Copy link
Member

squeek502 commented Nov 8, 2019 •
edited
Loading

It's hard to know exactly what the problem is here, or what exactly is being detected. One possibility is that it's a false positive caused by how memory is shared between child processes (Valgrind thinks the memory is 'owned' by the child PID when it's actually 'owned' by the parent PID, so when the child PID exits it thinks the child's memory hasn't been cleaned up even though it's actually the parent's memory so it shouldn't be cleaned up). I'm not sure if the memory is shared like this though, and if it is, then it would probably affect more than just the invalid command test case. The thing that leads me to think it might be true, though, is that Valgrind is reporting that a Lua state is being leaked, but there should be no Lua state created by the child process when trying to spawn an invalid process like ksjdfksjdflkjsflksdf.

One possible way to debug this would be to try to reproduce the problem with the Libuv API directly instead of through Luv, since (at least for me) the Lua runtime makes these types of things a bit harder to debug.

squeek502 added a commit to squeek502/luv that referenced this issue Nov 14, 2019
@squeek502
travis: Fix Valgrind detecting false-positive leaks in child when uv_…
beef08a 
…spawn fails

Fixes luvit#382 (comment), see libuv/libuv#727
squeek502 added a commit to squeek502/luv that referenced this issue Nov 14, 2019
@squeek502
travis: Fix Valgrind detecting false-positive leaks in child when uv_…
27a17ae 
…spawn fails

Fixes luvit#382 (comment), see libuv/libuv#727
@squeek502 squeek502 mentioned this issue Nov 14, 2019
Merged
squeek502 added a commit that referenced this issue Nov 14, 2019
@squeek502
travis: Fix Valgrind detecting false-positive leaks in child when uv_…
8e796a8 
…spawn fails (#442)

Fixes #382 (comment), see libuv/libuv#727
zhaozg pushed a commit to zhaozg/luv that referenced this issue Feb 21, 2020
@squeek502 @zhaozg
tap: Make os.exit call lua_close on Lua versions that support it
5bcdd86 
Second optional argument to os.exit is a boolean that determines if lua_close should be called while exiting. This was added in PUC Lua 5.2 and backported to LuaJIT.

This allows the tests to provide accurate memory leak information even with failing tests (memory leak info will still be inaccurate with failing tests on PUC Lua 5.1, since PUC Lua 5.1 os.exit bypasses lua_close).

Thanks to @vanc for the fix, see luvit#382 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

travis: Fix Valgrind detecting false-positive leaks in child when uv_spawn fails squeek502/luv
3 participants
@zhaozg @vanc @squeek502