On Sun, Dec 17, 2017 at 1:33 PM, John Reiser <jreiser@xxxxxxxxxxxx> wrote:
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.
Library /usr/lib64/libGLX.so.0.0.0
Package libglvnd-glx
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.
As far as a BZ ticket I'm not sure I can follow this well enough to explain but I'll try :)
Thanks,
Richard
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
