Use after free in cord_start and obuf_dup #4614

Gerold103 · 2019-11-06T13:04:41Z

Tarantool version: 1.10, probably newer too.
OS version: Mac, 10.14.4, Mojave
Bug description:
I built tarantool with enabled ASAN and run box/function1.test.lua.
Here is what ASAN detects:

Starting instance box...
Run console at unix/:/Users/gerold/Work/Repositories/tarantool/test/var/001_box/box.control
started
mkdir /Users/gerold/Work/Repositories/tarantool/test/var/001_box/box
2019-11-06 16:03:08.381 [73415] main/101/box C> Tarantool 1.10.4-27-ge9078b55b
2019-11-06 16:03:08.382 [73415] main/101/box C> log level 5
2019-11-06 16:03:08.382 [73415] main/101/box I> mapping 117440512 bytes for memtx tuple arena...
2019-11-06 16:03:08.382 [73415] main/101/box I> mapping 134217728 bytes for vinyl tuple arena...
2019-11-06 16:03:08.391 [73415] main/101/box I> instance uuid 6dd01a50-8319-4b70-8db9-009f2474d3cf
2019-11-06 16:03:08.391 [73415] iproto/101/main I> binary: bound to unix/:/Users/gerold/Work/Repositories/tarantool/test/var/001_box/box.socket-iproto
2019-11-06 16:03:08.391 [73415] main/101/box I> initializing an empty data directory
2019-11-06 16:03:08.420 [73415] main/101/box I> assigned id 1 to replica 6dd01a50-8319-4b70-8db9-009f2474d3cf
2019-11-06 16:03:08.420 [73415] main/101/box I> cluster uuid 896a221c-47f2-400f-a5cb-3542d785163b
2019-11-06 16:03:08.423 [73415] snapshot/101/main I> saving snapshot `/Users/gerold/Work/Repositories/tarantool/test/var/001_box/box/00000000000000000000.snap.inprogress'
2019-11-06 16:03:08.425 [73415] snapshot/101/main I> done
2019-11-06 16:03:08.425 [73415] main/101/box I> ready to accept requests
2019-11-06 16:03:08.426 [73415] main/108/checkpoint_daemon I> started
2019-11-06 16:03:08.426 [73415] main/108/checkpoint_daemon I> scheduled the next snapshot at Wed Nov  6 17:38:51 2019
2019-11-06 16:03:08.427 [73415] main/113/console/unix/:/Users/gerold/Work I> started
2019-11-06 16:03:08.427 [73415] main C> entering the event loop
2019-11-06 16:03:08.542 [73415] main/105/main I> -- function1 -  called --
=================================================================
==73415==ERROR: AddressSanitizer: stack-use-after-scope on address 0x000114eff420 at pc 0x000110b9fe12 bp 0x00011c4fe360 sp 0x00011c4fdb10
READ of size 3 at 0x000114eff420 thread T3
    #0 0x110b9fe11 in __asan_memcpy (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x5ee11)
    tarantool/tarantool#1 0x10e3b0171 in obuf_dup obuf.c:161
    tarantool/tarantool#2 0x10e1b8805 in xlog_write_row xlog.c:1324
    tarantool/tarantool#3 0x10db67a1c in xlog_write_entry wal.c:216
    tarantool/tarantool#4 0x10db66558 in wal_write_to_disk wal.c:828
    tarantool/tarantool#5 0x10dc16e25 in cmsg_deliver cbus.c:353
    tarantool/tarantool#6 0x10dc199e1 in cbus_process cbus.c:635
    tarantool/tarantool#7 0x10dc19fe4 in cbus_loop cbus.c:642
    tarantool/tarantool#8 0x10db60612 in wal_writer_f wal.c:897
    tarantool/tarantool#9 0x10d865549 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) fiber.h:666
    tarantool/tarantool#10 0x10dc0275f in fiber_loop fiber.c:694
    tarantool/tarantool#11 0x10e3ec92d in coro_init coro.c:110

Address 0x000114eff420 is a wild pointer.
SUMMARY: AddressSanitizer: stack-use-after-scope (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x5ee11) in __asan_memcpy
Shadow bytes around the buggy address:
  0x1000229dfe30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000229dfe40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000229dfe50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000229dfe60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000229dfe70: f1 f1 f1 f1 00 f2 f2 f2 f8 f8 f2 f2 f8 f2 f2 f2
=>0x1000229dfe80: f8 f2 f2 f2[f8]f8 f3 f3 00 00 00 00 00 00 00 00
  0x1000229dfe90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000229dfea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000229dfeb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000229dfec0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f3 f3 f3
  0x1000229dfed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
Thread T3 created by T0 here:
    #0 0x110b9a78d in wrap_pthread_create (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x5978d)
    tarantool/tarantool#1 0x10dc05c4e in cord_start fiber.c:1173
    tarantool/tarantool#2 0x10dc0818d in cord_costart fiber.c:1363
    tarantool/tarantool#3 0x10db5fe8a in wal_init wal.c:412
    tarantool/tarantool#4 0x10dafd95d in box_cfg_xc() box.cc:2116
    tarantool/tarantool#5 0x10dafd52c in box_cfg box.cc:2201
    tarantool/tarantool#6 0x10d862f76 in load_cfg main.cc:524
    tarantool/tarantool#7 0x10db73100 in lbox_cfg_load(lua_State*) cfg.cc:61
    tarantool/tarantool#8 0x10dca794c in lj_BC_FUNCC (tarantool:x86_64+0x10044a94c)

==73415==ABORTING
ok - function1

This is where the test is stopped:

c:call('function1.args', { 15 })
---
- [[15, 'hello']]
...
box.schema.func.drop("function1.args")
---
...
box.schema.func.create('function1.multi_inc', {language = "C"})
---
...
box.schema.user.grant('guest', 'execute', 'function', 'function1.multi_inc')
---
...
c:call('function1.multi_inc')
---
- []
...
box.space.test:select{}
---
- []
...
c:call('function1.multi_inc', { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 })
box.space.test:select{}
[Lost current connection]
c:call('function1.multi_inc', { 2, 4, 6, 8, 10 })
[Lost current connection]
box.space.test:select{}
[Lost current connection]
c:call('function1.multi_inc', { 0, 2, 4 })

Probably they are false-positive, but it needs to be checked.

The text was updated successfully, but these errors were encountered:

avtikhon · 2019-11-08T20:25:13Z

Test reproducer:

build_path = os.getenv("BUILDDIR")
package.cpath = build_path..'/test/box/?.so;'..build_path..'/test/box/?.dylib;'..package.cpath
net = require('net.box')
c = net.connect(os.getenv("LISTEN"))

box.schema.func.create('function1', {language = "C"})
box.schema.user.grant('guest', 'execute', 'function', 'function1')
_ = box.schema.space.create('test')
_ = box.space.test:create_index('primary')
box.schema.user.grant('guest', 'read,write', 'space', 'test')

c:call('function1')
box.schema.func.drop("function1")

box.schema.func.create('function1.multi_inc', {language = "C"})
box.schema.user.grant('guest', 'execute', 'function', 'function1.multi_inc')

c:call('function1.multi_inc')
box.space.test:select{}
c:call('function1.multi_inc', { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 })

cyrillos · 2020-05-18T15:20:22Z

been trying to trigger the issue on linux platform but without a luck. seems it is highly macos bound. gonna try it there...

Totktonada · 2021-04-06T21:02:12Z

Don't know how, but the test name and the OS (Mac OS) suggests that it may be relevant to tarantool/tarantool-qa#234.

(chekky picked from commit 6b08248) x64/LJ_GC64: Fix fallback case of asm_fuseloadk64(). Contributed by Peter Cawley. Code generation under LJ_GC64 missed an update to the mcode area boundaries after a 64-bit constant encoding. This lead to a corruption of the constant later on. The constant can be encoded in one of the following ways: a. If the address of the constant fits into 32-bit one, then encode it as a 32-bit displacement (the only option for non-GC64 mode). b. If the offset of the constant slot from the dispatch table (pinned to r14 that is not changed while trace execution) fits into 32-bit, then encode this as a 32-bit displacement relative to r14. c. If the offset of the constant slot from the mcode (i.e. rip) fits into 32-bit, then encode this as a 32-bit displacement relative to rip (considering long mode specifics and RID_RIP hack). d. If none of the conditions above are valid, compiler materializes this 64-bit constant right at the trace bottom and encodes this the same way it does for the previous case. As a result the problem appears with 4Gb distance from the currently allocated mcode to the dispatch pointer, which may happen in real life in case of long running instance. Sergey Ostanevich: * added the description and the test for the problem Fixes tarantool/tarantool#4095 Fixes tarantool/tarantool#4199 Fixes tarantool/tarantool#4614 --- Branch: https://github.com/tarantool/luajit/tree/sergos/gh-4095-gc64-const-fusion Tarantool branch: https://github.com/tarantool/luajit/tree/tarantool/gh-4095-gc64-const-fusion

(chekky picked from commit 6b08248) x64/LJ_GC64: Fix fallback case of asm_fuseloadk64(). Contributed by Peter Cawley. Code generation under LJ_GC64 missed an update to the mcode area boundaries after a 64-bit constant encoding. This lead to a corruption of the constant later on. The constant can be encoded in one of the following ways: a. If the address of the constant fits into 32-bit one, then encode it as a 32-bit displacement (the only option for non-GC64 mode). b. If the offset of the constant slot from the dispatch table (pinned to r14 that is not changed while trace execution) fits into 32-bit, then encode this as a 32-bit displacement relative to r14. c. If the offset of the constant slot from the mcode (i.e. rip) fits into 32-bit, then encode this as a 32-bit displacement relative to rip (considering long mode specifics and RID_RIP hack). d. If none of the conditions above are valid, compiler materializes this 64-bit constant right at the trace bottom and encodes this the same way it does for the previous case. As a result the problem appears with 4Gb distance from the currently allocated mcode to the dispatch pointer, which may happen in real life in case of long running instance. Sergey Ostanevich: * added the description and the test for the problem Fixes tarantool/tarantool#4095 Fixes tarantool/tarantool#4199 Fixes tarantool/tarantool#4614 --- Branch: https://github.com/tarantool/luajit/tree/sergos/gh-4095-gc64-const-fusion Tarantool branch: https://github.com/tarantool/tarantool/tree/sergos/gh-4095-gc64-const-fusion

(chekky picked from commit 6b08248) x64/LJ_GC64: Fix fallback case of asm_fuseloadk64(). Contributed by Peter Cawley. Code generation under LJ_GC64 missed an update to the mcode area boundaries after a 64-bit constant encoding. This lead to a corruption of the constant later on. The constant can be encoded in one of the following ways: a. If the address of the constant fits into 32-bit one, then encode it as a 32-bit displacement (the only option for non-GC64 mode). b. If the offset of the constant slot from the dispatch table (pinned to r14 that is not changed while trace execution) fits into 32-bit, then encode this as a 32-bit displacement relative to r14. c. If the offset of the constant slot from the mcode (i.e. rip) fits into 32-bit, then encode this as a 32-bit displacement relative to rip (considering long mode specifics and RID_RIP hack). d. If none of the conditions above are valid, compiler materializes this 64-bit constant right at the trace bottom and encodes this the same way it does for the previous case. As a result the problem appears with 4Gb distance from the currently allocated mcode to the dispatch pointer, which may happen in real life in case of long running instance. Sergey Ostanevich: * added the description and the test for the problem Fixes tarantool/tarantool#4095 Fixes tarantool/tarantool#4199 Fixes tarantool/tarantool#4614 --- Branch: https://github.com/tarantool/luajit/tree/sergos/gh-4095-gc64-const-fusion Tarantool branch: https://github.com/tarantool/luajit/tree/tarantool/gh-4095-gc64-const-fusion

(chekky picked from commit 6b08248) x64/LJ_GC64: Fix fallback case of asm_fuseloadk64(). Contributed by Peter Cawley. Code generation under LJ_GC64 missed an update to the mcode area boundaries after a 64-bit constant encoding. This lead to a corruption of the constant later on. The constant can be encoded in one of the following ways: a. If the address of the constant fits into 32-bit one, then encode it as a 32-bit displacement (the only option for non-GC64 mode). b. If the offset of the constant slot from the dispatch table (pinned to r14 that is not changed while trace execution) fits into 32-bit, then encode this as a 32-bit displacement relative to r14. c. If the offset of the constant slot from the mcode (i.e. rip) fits into 32-bit, then encode this as a 32-bit displacement relative to rip (considering long mode specifics and RID_RIP hack). d. If none of the conditions above are valid, compiler materializes this 64-bit constant right at the trace bottom and encodes this the same way it does for the previous case. As a result the problem appears with 2Gb distance from the currently allocated mcode to the dispatch pointer, which may happen in real life in case of long running instance. Sergey Ostanevich: * added the description and the test for the problem Fixes tarantool/tarantool#4095 Fixes tarantool/tarantool#4199 Fixes tarantool/tarantool#4614 --- Branch: https://github.com/tarantool/luajit/tree/sergos/gh-4095-gc64-const-fusion Tarantool branch: https://github.com/tarantool/luajit/tree/tarantool/gh-4095-gc64-const-fusion

(chekky picked from commit 6b08248) x64/LJ_GC64: Fix fallback case of asm_fuseloadk64(). Contributed by Peter Cawley. Code generation under LJ_GC64 missed an update to the mcode area boundaries after a 64-bit constant encoding. It can lead to a corruption of the constant value after next trace code generation. The constant can be encoded in one of the following ways: a. If the address of the constant fits into 32-bit one, then encode it as a 32-bit displacement (the only option for non-GC64 mode). b. If the offset of the constant slot from the dispatch table (pinned to r14 that is not changed while trace execution) fits into 32-bit, then encode this as a 32-bit displacement relative to r14. c. If the offset of the constant slot from the mcode (i.e. rip) fits into 32-bit, then encode this as a 32-bit displacement relative to rip (considering long mode specifics and RID_RIP hack). d. If none of the conditions above are valid, compiler materializes this 64-bit constant right at the trace bottom and encodes this the same way it does for the previous case. The mentioned problem appears only with 2Gb distance from the currently allocated mcode to the dispatch pointer, which may happen in real life in case of long running instance. Sergey Ostanevich: * added the description and the test for the problem Fixes tarantool/tarantool#4095 Fixes tarantool/tarantool#4199 Fixes tarantool/tarantool#4614 --- Branch: https://github.com/tarantool/luajit/tree/sergos/gh-4095-gc64-const-fusion Tarantool branch: https://github.com/tarantool/luajit/tree/tarantool/gh-4095-gc64-const-fusion

(chekky picked from commit 6b08248) x64/LJ_GC64: Fix fallback case of asm_fuseloadk64(). Contributed by Peter Cawley. Code generation under LJ_GC64 missed an update to the mcode area boundaries after a 64-bit constant encoding. It can lead to a corruption of the constant value after next trace code generation. The constant can be encoded in one of the following ways: a. If the address of the constant fits into 32-bit one, then encode it as a 32-bit displacement (the only option for non-GC64 mode). b. If the offset of the constant slot from the dispatch table (pinned to r14 that is not changed while trace execution) fits into 32-bit, then encode this as a 32-bit displacement relative to r14. c. If the offset of the constant slot from the mcode (i.e. rip) fits into 32-bit, then encode this as a 32-bit displacement relative to rip (considering long mode specifics and RID_RIP hack). d. If none of the conditions above are valid, compiler materializes this 64-bit constant right at the trace bottom and encodes this the same way it does for the previous case. The mentioned problem appears only with 2Gb distance from the currently allocated mcode to the dispatch pointer, which may happen in real life in case of long running instance. Sergey Ostanevich: * added the description and the test for the problem Fixes tarantool/tarantool#4095 Fixes tarantool/tarantool#4199 Fixes tarantool/tarantool#4614

Contributed by Peter Cawley. (chekky picked from commit 6b08248) Code generation under LJ_GC64 missed an update to the mcode area boundaries after a 64-bit constant encoding. It can lead to a corruption of the constant value after next trace code generation. The constant can be encoded in one of the following ways: a. If the address of the constant fits into 32-bit one, then encode it as a 32-bit displacement (the only option for non-GC64 mode). b. If the offset of the constant slot from the dispatch table (pinned to r14 that is not changed while trace execution) fits into 32-bit, then encode this as a 32-bit displacement relative to r14. c. If the offset of the constant slot from the mcode (i.e. rip) fits into 32-bit, then encode this as a 32-bit displacement relative to rip (considering long mode specifics and RID_RIP hack). d. If none of the conditions above are valid, compiler materializes this 64-bit constant right at the trace bottom and encodes this the same way it does for the previous case. The mentioned problem appears only with 2Gb distance from the currently allocated mcode to the dispatch pointer, which may happen in real life in case of long running instance. Sergey Ostanevich: * added the description and the test for the problem Fixes tarantool/tarantool#4095 Fixes tarantool/tarantool#4199 Fixes tarantool/tarantool#4614

Contributed by Peter Cawley. (cherry picked from commit 6b08248) Code generation under LJ_GC64 misses to update the mcode area boundaries after a 64-bit constant encoding. It can lead to a corruption of the constant value as a result of the next trace code generation. The constant can be encoded in one of the following ways: a. If the address of the constant fits into 32-bit one, then encode it as a 32-bit displacement (the only option for non-GC64 mode). b. If the offset of the constant slot from the dispatch table (pinned to r14 that is not changed while trace execution) fits into 32-bit, then encode this as a 32-bit displacement relative to r14. c. If the offset of the constant slot from the mcode (i.e. rip) fits into 32-bit, then encode this as a 32-bit displacement relative to rip (considering long mode specifics and RID_RIP hack). d. If none of the conditions above are valid, compiler materializes this 64-bit constant right at the trace bottom and encodes this the same way it does for the previous case. The aforementioned problem appears only with 2Gb gap between the currently allocated mcode and the dispatch pointer, which may happen in real life in case of long running instance. Sergey Ostanevich: * added the description and the test for the problem Part of tarantool/tarantool#6548 Resolves tarantool/tarantool#4095 Resolves tarantool/tarantool#4199 Resolves tarantool/tarantool#4614

Contributed by Peter Cawley. (cherry picked from commit 6b08248) Code generation under LJ_GC64 misses to update the mcode area boundaries after a 64-bit constant encoding. It can lead to a corruption of the constant value as a result of the next trace code generation. The constant can be encoded in one of the following ways: a. If the address of the constant fits into 32-bit one, then encode it as a 32-bit displacement (the only option for non-GC64 mode). b. If the offset of the constant slot from the dispatch table (pinned to r14 that is not changed while trace execution) fits into 32-bit, then encode this as a 32-bit displacement relative to r14. c. If the offset of the constant slot from the mcode (i.e. rip) fits into 32-bit, then encode this as a 32-bit displacement relative to rip (considering long mode specifics and RID_RIP hack). d. If none of the conditions above are valid, compiler materializes this 64-bit constant right at the trace bottom and encodes this the same way it does for the previous case. The aforementioned problem appears only with 2Gb gap between the currently allocated mcode and the dispatch pointer, which may happen in real life in case of long running instance. Sergey Ostanevich: * added the description and the test for the problem Part of tarantool/tarantool#6548 Resolves tarantool/tarantool#4095 Resolves tarantool/tarantool#4199 Resolves tarantool/tarantool#4614 Reviewed-by: Sergey Ostanevich <sergos@tarantool.org> Reviewed-by: Igor Munkin <imun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit 4285379)

* test: fix path storage for non-concatable objects * test: set DYLD_LIBRARY_PATH environment variable * x64/LJ_GC64: Fix fallback case of asm_fuseloadk64(). * FFI: Handle zero-fill of struct-of-NYI. * Fix interaction between profiler hooks and finalizers. * Flush and close output file after profiling run. * Fix debug.debug() for non-string errors. * Fix write barrier for lua_setupvalue() and debug.setupvalue(). * Fix FOLD rule for strength reduction of widening. * Fix bytecode dump unpatching. * Fix tonumber("-0") in dual-number mode. * Fix tonumber("-0"). * Give expected results for negative non-base-10 numbers in tonumber(). * Add missing LJ_MAX_JSLOTS check. * Add stricter check for print() vs. tostring() shortcut. Resolves tarantool#6548 Fixes #4095 Fixes #4199 Fixes tarantool#4614 Fixes tarantool#4630 Fixes tarantool#5885 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump

* Avoid conflict between 64 bit lightuserdata and ITERN key. * Reorganize lightuserdata interning code. * test: fix path storage for non-concatable objects * ARM64: Fix assembly of HREFK. * FFI/ARM64: Fix pass-by-value struct calling conventions. * test: set DYLD_LIBRARY_PATH environment variable * x64/LJ_GC64: Fix fallback case of asm_fuseloadk64(). * FFI: Handle zero-fill of struct-of-NYI. * Fix interaction between profiler hooks and finalizers. * Flush and close output file after profiling run. * Fix debug.debug() for non-string errors. * Fix write barrier for lua_setupvalue() and debug.setupvalue(). * Fix FOLD rule for strength reduction of widening. * Fix bytecode dump unpatching. * Fix tonumber("-0") in dual-number mode. * Fix tonumber("-0"). * Give expected results for negative non-base-10 numbers in tonumber(). * Add missing LJ_MAX_JSLOTS check. * Add stricter check for print() vs. tostring() shortcut. Closes tarantool#6548 Fixes #4095 Fixes #4199 Fixes tarantool#4614 Fixes tarantool#4630 Fixes tarantool#5885 Follows up tarantool#2712 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump

* test: fix path storage for non-concatable objects * test: set DYLD_LIBRARY_PATH environment variable * x64/LJ_GC64: Fix fallback case of asm_fuseloadk64(). * FFI: Handle zero-fill of struct-of-NYI. * Fix interaction between profiler hooks and finalizers. * Flush and close output file after profiling run. * Fix debug.debug() for non-string errors. * Fix write barrier for lua_setupvalue() and debug.setupvalue(). * Fix FOLD rule for strength reduction of widening. * Fix bytecode dump unpatching. * Fix tonumber("-0") in dual-number mode. * Fix tonumber("-0"). * Give expected results for negative non-base-10 numbers in tonumber(). * Add missing LJ_MAX_JSLOTS check. * Add stricter check for print() vs. tostring() shortcut. Closes tarantool#6548 Fixes #4095 Fixes #4199 Fixes tarantool#4614 Fixes tarantool#4630 Fixes tarantool#5885 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump

* Avoid conflict between 64 bit lightuserdata and ITERN key. * Reorganize lightuserdata interning code. * test: fix path storage for non-concatable objects * ARM64: Fix assembly of HREFK. * FFI/ARM64: Fix pass-by-value struct calling conventions. * test: set DYLD_LIBRARY_PATH environment variable * x64/LJ_GC64: Fix fallback case of asm_fuseloadk64(). * FFI: Handle zero-fill of struct-of-NYI. * Fix interaction between profiler hooks and finalizers. * Flush and close output file after profiling run. * Fix debug.debug() for non-string errors. * Fix write barrier for lua_setupvalue() and debug.setupvalue(). * Fix FOLD rule for strength reduction of widening. * Fix bytecode dump unpatching. * Fix tonumber("-0") in dual-number mode. * Fix tonumber("-0"). * Give expected results for negative non-base-10 numbers in tonumber(). * Add missing LJ_MAX_JSLOTS check. * Add stricter check for print() vs. tostring() shortcut. Closes tarantool#6548 Fixes #4095 Fixes #4199 Fixes tarantool#4614 Fixes tarantool#4630 Fixes tarantool#5885 Follows up tarantool#2712 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump

* Avoid conflict between 64 bit lightuserdata and ITERN key. * Reorganize lightuserdata interning code. * test: fix path storage for non-concatable objects * ARM64: Fix assembly of HREFK. * FFI/ARM64: Fix pass-by-value struct calling conventions. * test: set DYLD_LIBRARY_PATH environment variable * x64/LJ_GC64: Fix fallback case of asm_fuseloadk64(). * FFI: Handle zero-fill of struct-of-NYI. * Fix interaction between profiler hooks and finalizers. * Flush and close output file after profiling run. * Fix debug.debug() for non-string errors. * Fix write barrier for lua_setupvalue() and debug.setupvalue(). * Fix FOLD rule for strength reduction of widening. * Fix bytecode dump unpatching. * Fix tonumber("-0") in dual-number mode. * Fix tonumber("-0"). * Give expected results for negative non-base-10 numbers in tonumber(). * Add missing LJ_MAX_JSLOTS check. * Add stricter check for print() vs. tostring() shortcut. Closes tarantool#6548 Fixes tarantool#4614 Fixes tarantool#4630 Fixes tarantool#5885 Fixes tarantool/tarantool-qa#234 Fixes tarantool/tarantool-qa#235 Follows up tarantool#2712 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump

* test: fix path storage for non-concatable objects * test: set DYLD_LIBRARY_PATH environment variable * x64/LJ_GC64: Fix fallback case of asm_fuseloadk64(). * FFI: Handle zero-fill of struct-of-NYI. * Fix interaction between profiler hooks and finalizers. * Flush and close output file after profiling run. * Fix debug.debug() for non-string errors. * Fix write barrier for lua_setupvalue() and debug.setupvalue(). * Fix FOLD rule for strength reduction of widening. * Fix bytecode dump unpatching. * Fix tonumber("-0") in dual-number mode. * Fix tonumber("-0"). * Give expected results for negative non-base-10 numbers in tonumber(). * Add missing LJ_MAX_JSLOTS check. * Add stricter check for print() vs. tostring() shortcut. Closes tarantool#6548 Fixes tarantool#4614 Fixes tarantool#4630 Fixes tarantool#5885 Fixes tarantool/tarantool-qa#234 Fixes tarantool/tarantool-qa#235 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump

* Avoid conflict between 64 bit lightuserdata and ITERN key. * Reorganize lightuserdata interning code. * test: fix path storage for non-concatable objects * ARM64: Fix assembly of HREFK. * FFI/ARM64: Fix pass-by-value struct calling conventions. * test: set DYLD_LIBRARY_PATH environment variable * x64/LJ_GC64: Fix fallback case of asm_fuseloadk64(). * FFI: Handle zero-fill of struct-of-NYI. * Fix interaction between profiler hooks and finalizers. * Flush and close output file after profiling run. * Fix debug.debug() for non-string errors. * Fix write barrier for lua_setupvalue() and debug.setupvalue(). * Fix FOLD rule for strength reduction of widening. * Fix bytecode dump unpatching. * Fix tonumber("-0") in dual-number mode. * Fix tonumber("-0"). * Give expected results for negative non-base-10 numbers in tonumber(). * Add missing LJ_MAX_JSLOTS check. * Add stricter check for print() vs. tostring() shortcut. Closes tarantool#6548 Fixes tarantool#4614 Fixes tarantool#4630 Fixes tarantool#5885 Fixes tarantool/tarantool-qa#234 Fixes tarantool/tarantool-qa#235 Follows up tarantool#2712 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump

* Avoid conflict between 64 bit lightuserdata and ITERN key. * Reorganize lightuserdata interning code. * test: fix path storage for non-concatable objects * ARM64: Fix assembly of HREFK. * FFI/ARM64: Fix pass-by-value struct calling conventions. * test: set DYLD_LIBRARY_PATH environment variable * x64/LJ_GC64: Fix fallback case of asm_fuseloadk64(). * FFI: Handle zero-fill of struct-of-NYI. * Fix interaction between profiler hooks and finalizers. * Flush and close output file after profiling run. * Fix debug.debug() for non-string errors. * Fix write barrier for lua_setupvalue() and debug.setupvalue(). * Fix FOLD rule for strength reduction of widening. * Fix bytecode dump unpatching. * Fix tonumber("-0") in dual-number mode. * Fix tonumber("-0"). * Give expected results for negative non-base-10 numbers in tonumber(). * Add missing LJ_MAX_JSLOTS check. * Add stricter check for print() vs. tostring() shortcut. Closes #6548 Fixes #4614 Fixes #4630 Fixes #5885 Fixes tarantool/tarantool-qa#234 Fixes tarantool/tarantool-qa#235 Follows up #2712 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump

* test: fix path storage for non-concatable objects * test: set DYLD_LIBRARY_PATH environment variable * x64/LJ_GC64: Fix fallback case of asm_fuseloadk64(). * FFI: Handle zero-fill of struct-of-NYI. * Fix interaction between profiler hooks and finalizers. * Flush and close output file after profiling run. * Fix debug.debug() for non-string errors. * Fix write barrier for lua_setupvalue() and debug.setupvalue(). * Fix FOLD rule for strength reduction of widening. * Fix bytecode dump unpatching. * Fix tonumber("-0") in dual-number mode. * Fix tonumber("-0"). * Give expected results for negative non-base-10 numbers in tonumber(). * Add missing LJ_MAX_JSLOTS check. * Add stricter check for print() vs. tostring() shortcut. Closes #6548 Fixes #4614 Fixes #4630 Fixes #5885 Fixes tarantool/tarantool-qa#234 Fixes tarantool/tarantool-qa#235 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump

* Avoid conflict between 64 bit lightuserdata and ITERN key. * Reorganize lightuserdata interning code. * test: fix path storage for non-concatable objects * ARM64: Fix assembly of HREFK. * FFI/ARM64: Fix pass-by-value struct calling conventions. * test: set DYLD_LIBRARY_PATH environment variable * x64/LJ_GC64: Fix fallback case of asm_fuseloadk64(). * FFI: Handle zero-fill of struct-of-NYI. * Fix interaction between profiler hooks and finalizers. * Flush and close output file after profiling run. * Fix debug.debug() for non-string errors. * Fix write barrier for lua_setupvalue() and debug.setupvalue(). * Fix FOLD rule for strength reduction of widening. * Fix bytecode dump unpatching. * Fix tonumber("-0") in dual-number mode. * Fix tonumber("-0"). * Give expected results for negative non-base-10 numbers in tonumber(). * Add missing LJ_MAX_JSLOTS check. * Add stricter check for print() vs. tostring() shortcut. Closes tarantool#6548 Fixes tarantool#4614 Fixes tarantool#4630 Fixes tarantool#5885 Fixes tarantool/tarantool-qa#234 Fixes tarantool/tarantool-qa#235 Follows up tarantool#2712 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump

Gerold103 added crash bug Something isn't working labels Nov 6, 2019

kyukhin added this to the 1.10.5 milestone Nov 8, 2019

GeorgyKirichenko assigned MariaHajdic Nov 11, 2019

kyukhin modified the milestones: 1.10.5, 1.10.6 Jan 13, 2020

kyukhin modified the milestones: 1.10.6, 1.10.7 Apr 20, 2020

kyukhin unassigned MariaHajdic Apr 23, 2020

cyrillos self-assigned this Apr 23, 2020

kyukhin modified the milestones: 1.10.7, 1.10.8 Jun 22, 2020

kyukhin modified the milestones: 1.10.8, wishlist Oct 23, 2020

cyrillos removed their assignment Sep 16, 2021

kyukhin added teamL and removed teamL labels Jun 24, 2022

kyukhin removed this from the wishlist milestone Jun 24, 2022

igormunkin closed this as completed in tarantool/luajit@4285379 Jun 29, 2022

This was referenced Jun 29, 2022

[backport/1.10] luajit: bump new version #7330

Merged

luajit: bump new version #7328

Merged

[backport/2.10] luajit: bump new version #7329

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use after free in cord_start and obuf_dup #4614

Use after free in cord_start and obuf_dup #4614

Gerold103 commented Nov 6, 2019

avtikhon commented Nov 8, 2019

cyrillos commented May 18, 2020

Totktonada commented Apr 6, 2021

Use after free in cord_start and obuf_dup #4614

Use after free in cord_start and obuf_dup #4614

Comments

Gerold103 commented Nov 6, 2019

avtikhon commented Nov 8, 2019

cyrillos commented May 18, 2020

Totktonada commented Apr 6, 2021