On Wed, Mar 24, 2021 at 08:55:33AM +0100, Maciej Zdeb wrote: > After reading I wasn't sure anymore I even tested properly patched package. > :)
Hehe, I know that this happens quite a lot when starting to play with different binaries. > Fortunately I have a core file so I verified if hlua_not_dumpable > variable exists. I don't know how it is possible that hlua_not_dumpable is > 0 in this state (bt), if Christopher theory about lacking compiler barriers > is wrong. > > (gdb) p hlua_not_dumpable > $1 = 0 > > (gdb) bt > #0 __lll_lock_wait_private () at > ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95 > #1 0x00007f52fb16c34b in __GI___libc_malloc (bytes=bytes@entry=41) at > malloc.c:3063 > #2 0x000055d94949e9a9 in hlua_alloc (ud=0x55d9498e90d0 > <hlua_global_allocator>, ptr=<optimized out>, osize=4, nsize=41) at > src/hlua.c:8210 > #3 0x000055d949622271 in luaM_realloc_ () > #4 0x000055d949621dbe in luaC_newobj () > #5 0x000055d949626f4d in internshrstr () > #6 0x000055d9496271fc in luaS_new () > #7 0x000055d94961bd03 in lua_pushstring () > #8 0x000055d94962d48a in luaL_traceback () > #9 0x000055d9495a1b62 in ha_task_dump (buf=buf@entry=0x7f5247c7f628, > task=0x7f5234057ba0, pfx=pfx@entry=0x55d949672f19 ' ' <repeats 13 times>) > at src/debug.c:227 > #10 0x000055d9495a1fd7 in ha_thread_dump (buf=0x7f5247c7f628, > thr=<optimized out>, calling_tid=7) at src/debug.c:91 > #11 0x000055d9495a2236 in debug_handler (sig=<optimized out>, si=<optimized > out>, arg=<optimized out>) at src/debug.c:847 > #12 <signal handler called> > #13 _int_malloc (av=av@entry=0x7f5234000020, bytes=bytes@entry=56) at > malloc.c:4100 > #14 0x00007f52fb16c35d in __GI___libc_malloc (bytes=bytes@entry=56) at > malloc.c:3065 > #15 0x000055d94949e9a9 in hlua_alloc (ud=0x55d9498e90d0 > <hlua_global_allocator>, ptr=<optimized out>, osize=5, nsize=56) at > src/hlua.c:8210 This is particularly strange. Could you please disassemble hlua_alloc ? (dis hlua_alloc) ? You should find something like this: 0x00000000004476c3 <+147>: add DWORD PTR fs:0xfffffffffffdd678,0x1 0x00000000004476cc <+156>: lock add QWORD PTR [rip+0x25df8b],0x1 # 0x6a5660 <_.44806> 0x00000000004476d5 <+165>: lock add QWORD PTR [rip+0x25df8b],rbx # 0x6a5668 <_.44806+8> 0x00000000004476dd <+173>: mov rdi,rbx 0x00000000004476e0 <+176>: call 0x4248b0 <malloc@plt> 0x00000000004476e5 <+181>: sub DWORD PTR fs:0xfffffffffffdd678,0x1 0x00000000004476ee <+190>: test rax,rax 0x00000000004476f1 <+193>: jne 0x44769d <hlua_alloc+109> The "add DWORD..." is the ++, and the "sub DWORD..." is the --, both of them around the function call. If the variable had been declared static I would have agreed with the possibility of reordering. But here it's global and it's not legal to move it when you don't know if the called function will make use of it. Otherwise global variables cannot be used anymore! By the way, in your case above it should even equal 2. That's rather strange. One thing you can test is simply to declare it volatile. If it changes anything, it will mean that gcc has some specific assumptions on this malloc function (i.e. it decides it will never read your global variables) :-/ Willy
