On Sun, Dec 17, 2017 at 1:33 PM, John Reiser <jrei...@bitwagon.com> 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. https://pastebin.com/biwrRZ3U 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
