Le 24/03/2021 à 10:16, Willy Tarreau a écrit :
On Wed, Mar 24, 2021 at 10:11:19AM +0100, Maciej Zdeb wrote:
Wow, that's it! :)
0x000055d94949e965 <+53>: addl $0x1,%fs:0xfffffffffffdd688
0x000055d94949e96e <+62>: callq 0x55d9494782c0 <realloc@plt>
0x000055d94949e973 <+67>: subl $0x1,%fs:0xfffffffffffdd688
[...]
0x000055d94949e99f <+111>: ja 0x55d94949e9b0 <hlua_alloc+128>
0x000055d94949e9a1 <+113>: mov %rbx,%rdi
0x000055d94949e9a4 <+116>: callq 0x55d949477d50 <malloc@plt>
0x000055d94949e9a9 <+121>: test %rax,%rax
[...]
0x000055d94949e9c1 <+145>: addl $0x1,%fs:0xfffffffffffdd688
0x000055d94949e9ca <+154>: callq 0x55d949477b50 <free@plt>
0x000055d94949e9cf <+159>: subl $0x1,%fs:0xfffffffffffdd688
Cool!
Ok I'll make hlua_not_dumpable volatile instead of applying compiler
barriers.
Yes, it's safer for the long term as nobody will have to think about
it anymore. We'll have to integrate this one as well.
Thanks Guys, I will push a fix to make the variable volatile.
However, reading the other trace Maciej sent (bussy_thread_peers.txt), it seems
possible to stop a memory allocation from other places. Thus, I guess we must
find a more global way to prevent the lua stack dump.
--
Christopher Faulet
