Closed GoogleCodeExporter closed 9 years ago
I pressed enter in the browser and it submitted :/.
What steps will reproduce the problem?
llvm-lua llvm-lua/tests/coroutine.lua
What is the expected output? What do you see instead?
No abort
What version of the product are you using? On what operating system?
llvm-lua trunk with clang + llvm trunk on ArchLinux x86_64
Please provide any additional information below.
llvm-lua/build/build> valgrind llvm-lua ../../llvm-lua/tests/coroutine.lua
==14895== Memcheck, a memory error detector
==14895== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==14895== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==14895== Command: llvm-lua ../../llvm-lua/tests/coroutine.lua
==14895==
==14895== Warning: client switching stacks? SP change: 0x7fefff920 -->
0x6aa0188
==14895== to suppress, use: --max-stackframe=34231154584 or greater
yield
==14895== Warning: client switching stacks? SP change: 0x6a9fe28 -->
0x7fefff920
==14895== to suppress, use: --max-stackframe=34231155448 or greater
==14895== Warning: client switching stacks? SP change: 0x7fefff700 -->
0x6a9fe28
==14895== to suppress, use: --max-stackframe=34231154904 or greater
==14895== further instances of this message will not be shown.
getfenv(0)
getfenv(1)
getfenv(loadstring)
==14895== Invalid read of size 8
==14895== at 0x9E0370: llvm::BasicBlock::dropAllReferences() (in
/usr/bin/llvm-lua)
==14895== by 0xA0BF9F: llvm::Function::dropAllReferences() (in
/usr/bin/llvm-lua)
==14895== by 0xA0C0B5: llvm::Function::~Function() (in /usr/bin/llvm-lua)
==14895== by 0x4E46FB0: luaF_freeproto (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E47302: sweeplist (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E51DC9: singlestep (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E5233F: luaC_step (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E46695: lua_call (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E5B5DE: luaB_print (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4D47E2: luaD_precall_c (in /usr/bin/llvm-lua)
==14895== by 0x4D4F7A: luaD_precall (in /usr/bin/llvm-lua)
==14895== by 0x4E5E543: vm_OP_CALL (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== Address 0x6a90c90 is 64 bytes inside a block of size 80 alloc'd
==14895== at 0x4C2461C: operator new(unsigned long) (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14895== by 0x4E3D63D: LLVMCompiler::compile(lua_State*, Proto*) (in
/usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E415C5: LLVMCompiler::compileAll(lua_State*, Proto*) (in
/usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4D4011: ??? (in /usr/bin/llvm-lua)
==14895== by 0x4D4B76: luaD_rawrunprotected (in /usr/bin/llvm-lua)
==14895== by 0x4D4BEF: luaD_pcall (in /usr/bin/llvm-lua)
==14895== by 0x4D4CC8: luaD_protectedparser (in /usr/bin/llvm-lua)
==14895== by 0x4E5B982: lua_load (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E5B9BB: luaL_loadbuffer (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E5BA4F: luaB_loadstring (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4D47E2: luaD_precall_c (in /usr/bin/llvm-lua)
==14895== by 0x4D4F7A: luaD_precall (in /usr/bin/llvm-lua)
==14895==
==14895== Invalid read of size 8
==14895== at 0x9E0380: llvm::BasicBlock::dropAllReferences() (in
/usr/bin/llvm-lua)
==14895== by 0xA0BF9F: llvm::Function::dropAllReferences() (in
/usr/bin/llvm-lua)
==14895== by 0xA0C0B5: llvm::Function::~Function() (in /usr/bin/llvm-lua)
==14895== by 0x4E46FB0: luaF_freeproto (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E47302: sweeplist (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E51DC9: singlestep (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E5233F: luaC_step (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E46695: lua_call (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E5B5DE: luaB_print (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4D47E2: luaD_precall_c (in /usr/bin/llvm-lua)
==14895== by 0x4D4F7A: luaD_precall (in /usr/bin/llvm-lua)
==14895== by 0x4E5E543: vm_OP_CALL (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== Address 0x28 is not stack'd, malloc'd or (recently) free'd
==14895==
==14895==
==14895== Process terminating with default action of signal 11 (SIGSEGV)
==14895== Access not within mapped region at address 0x28
==14895== at 0x9E0380: llvm::BasicBlock::dropAllReferences() (in
/usr/bin/llvm-lua)
==14895== by 0xA0BF9F: llvm::Function::dropAllReferences() (in
/usr/bin/llvm-lua)
==14895== by 0xA0C0B5: llvm::Function::~Function() (in /usr/bin/llvm-lua)
==14895== by 0x4E46FB0: luaF_freeproto (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E47302: sweeplist (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E51DC9: singlestep (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E5233F: luaC_step (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E46695: lua_call (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4E5B5DE: luaB_print (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== by 0x4D47E2: luaD_precall_c (in /usr/bin/llvm-lua)
==14895== by 0x4D4F7A: luaD_precall (in /usr/bin/llvm-lua)
==14895== by 0x4E5E543: vm_OP_CALL (in /usr/lib/libllvm-lua.so.1.1.0)
==14895== If you believe this happened as a result of a stack
==14895== overflow in your program's main thread (unlikely but
==14895== possible), you can try to increase the size of the
==14895== main thread stack using the --main-stacksize= flag.
==14895== The main thread stack size used in this run was 8388608.
==14895==
==14895== HEAP SUMMARY:
==14895== in use at exit: 1,448,256 bytes in 8,202 blocks
==14895== total heap usage: 45,239 allocs, 37,037 frees, 14,081,610 bytes
allocated
==14895==
==14895== LEAK SUMMARY:
==14895== definitely lost: 0 bytes in 0 blocks
==14895== indirectly lost: 0 bytes in 0 blocks
==14895== possibly lost: 1,336,239 bytes in 7,237 blocks
==14895== still reachable: 112,017 bytes in 965 blocks
==14895== suppressed: 0 bytes in 0 blocks
==14895== Rerun with --leak-check=full to see details of leaked memory
==14895==
==14895== For counts of detected and suppressed errors, rerun with: -v
==14895== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 7 from 7)
[1] 14895 segmentation fault valgrind llvm-lua
../../llvm-lua/tests/coroutine.lua
Original comment by tcmreast...@gmail.com
on 18 Dec 2009 at 6:43
This bug was caused by the call to 'loadstring' from a coroutine.
Coroutines have very small C-stacks to keep them lightweight, but that stack is
not large enough for the LLVM codegen backend that is used by the JIT compiler.
To fix this bug the JIT compiler will detect if it is called from a coroutine
and not JIT compile the Lua code.
Original comment by rjakabo...@gmail.com
on 3 Jun 2012 at 9:23
Original issue reported on code.google.com by
tcmreast...@gmail.com
on 18 Dec 2009 at 6:40