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
Ok I'll make hlua_not_dumpable volatile instead of applying compiler barriers. śr., 24 mar 2021 o 10:00 Willy Tarreau <[email protected]> napisał(a): > On Wed, Mar 24, 2021 at 09:52:22AM +0100, Willy Tarreau wrote: > > So yes, it looks like gcc decides that a function called "malloc" will > > never use your program's global variables but that "blablalloc" may. I > > have no explanation to this except "optimization craziness" resulting > > in breaking valid code, since it means that if I provide my own malloc > > function it might not work. Pfff.... > > And that's exactly it! > > https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins > > By default a number of functions including malloc, strchr etc are mapped > to builtins so it figures it knows better how these work and how to > optimize > around. Once built with -fno-builtin-malloc no more probmlem. So the > volatile > is the way to go to respect the risk of a signal hitting it. > > I found an old report of gcc-4.5 breaking chromium and tcmalloc because of > this, which put me on the track: > > https://github.com/gperftools/gperftools/issues/239 > > Willy >
