Dump of assembler code for function __GI__dl_catch_error:
0x00007ffff6136100 <+0>:push %rbx
0x00007ffff6136101 <+1>:sub $0x140,%rsp
0x00007ffff6136108 <+8>:lea 0x4c(%rsp),%rax
0x00007ffff613610d <+13>:mov %rdi,0x10(%rsp)
0x00007ffff6136112 <+18>:mov %rsi,0x8(%rsp)
0x00007ffff6136117 <+23>:mov %rdi,0x20(%rsp)
0x00007ffff613611c <+28>:lea 0x50(%rsp),%rdi
0x00007ffff6136121 <+33>:mov %rcx,0x30(%rsp)
0x00007ffff6136126 <+38>:mov %rax,0x68(%rsp)
0x00007ffff613612b <+43>:mov 0x279c56(%rip),%rax # 0x7ffff63afd88
0x00007ffff6136132 <+50>:movq 0x10(%rsp),%xmm0
0x00007ffff6136138 <+56>:mov %r8,0x38(%rsp)
0x00007ffff613613d <+61>:movhps 0x8(%rsp),%xmm0
0x00007ffff6136142 <+66>:mov %rdx,0x28(%rsp)
0x00007ffff6136147 <+71>:mov %rdx,0x60(%rsp)
0x00007ffff613614c <+76>:mov %fs:(%rax),%rsi
0x00007ffff6136150 <+80>:mov %rdi,%fs:(%rax)
0x00007ffff6136154 <+84>:lea 0x70(%rsp),%rdi
0x00007ffff6136159 <+89>:mov %fs:0x28,%rbx
0x00007ffff6136162 <+98>:mov %rbx,0x138(%rsp)
0x00007ffff613616a <+106>:xor %ebx,%ebx
=> 0x00007ffff613616c <+108>:movaps %xmm0,0x50(%rsp)
That looks OK (16-byte alignment of %rsp is maintained because the "push %rbx"
was preceded by a 'call' from a place where %rsp should have been 16-byte aligned,
and the "sub $0x140,%rsp" keeps 16-byte alignment),
although the compiler could produce better code by storing the first two
arguments directly into the local "struct catch" instead of spilling them
onto the stack, fetching them back (movq and movhps) and storing from
the 16-byte register %xmm0 (movaps).
Anyway, the focus now shifts to the backtrace from https://pastebin.com/LCDQpB5d :
#0 __GI__dl_catch_error
#1 0x00007ffff63b76a5 in _dlerror_run at dlerror.c:163
#2 0x00007ffff63b701f in __dlclose at dlclose.c:46
#3 0x00007ffff47f9bee in CleanupVendorNameEntry at libglxmapping.c:321
#4 0x00007ffff47fc161 in __glXMappingTeardown at libglxmapping.c:1061
#5 0x00007ffff47f4dd7 in __glXFini at libglx.c:2099
#6 0x00007ffff7de74b3 in _dl_fini at dl-fini.c:235
#7 0x00007ffff601bfc8 in __run_exit_handlers at exit.c:83
Which .so and .rpm contains the compiled libglxmapping.c ?
The strategy is to disassemble each routine in the traceback,
looking for somewhere that fails to keep %rsp as a multiple of 16.
At this point I suggest to file a bugzilla report against the compiler
for not keeping %rsp 16-byte aligned. Include the traceback and
the register info from the gdb session at SIGSEGV, and the identities
(.so name, build-id, .rpm name) of the shared libraries that were loaded
at the time of SIGSEGV.
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
