|
Bugzilla – Full Text Bug Listing |
| Summary: | Xvfb segfaults | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Dominique Leuenberger <dimstar> |
| Component: | X.Org | Assignee: | Michal Srb <msrb> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <xorg-maintainer-bugs> |
| Severity: | Normal | ||
| Priority: | P3 - Medium | CC: | badshah400 |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
the build of plplt actually launches 'wish', the effect is the same... Most likely another server reset issue. Michal, could you please have a look? (In reply to Egbert Eich from comment #2) > Most likely another server reset issue. > Michal, could you please have a look? I will look at it. This looks like another manifestation of bnc#981975. The GLX extension dynamically loads "/usr/lib64/dri/swrast_dri.so" library. When Xvfb does the internal restart it attempts to dlclose it, but that fails and prints following message to the console: /usr/bin/Xvfb: symbol lookup error: /usr/lib64/libLLVMAMDGPUCodeGen.so.3.8: undefined symbol: _ZN4llvm19MachinePassRegistry6RemoveEPNS_23MachinePassRegistryNodeE This leaves the library in a strange half-unloaded state. Second attempt to dlopen it fails (but gives no error code). When Xvfb restarts for second time, it tries to dlopen the library again and this time it succeeds, however the global variables do not seem to get initialized. Later glxProbeDriver tries to access one of them (galliumsw_driver_extensions) and crashes trying to dereference null pointer from it. As a workaround you can run Xvfb with '-noreset' parameter. The X server's internal reset is meant to do a cleanup between graphical sessions. In your use case (running graphical applications during build of a package) it should be safe to omit it. I verified that this bug is a duplicate of bnc#981975 (bug in the dynamic loader or in llvm libraries). Workaround suggested in that bug fixes this one as well. *** This bug has been marked as a duplicate of bug 981975 *** |
Found while debugging build failure of Leap:42.2/plplot (which is actually not relevant) The build of above mentioned packages uses Xvfb in order to allow for 'GUI' stuff to be laucnhed - the failure of the build triggered me to analyze the situation. Turns out I can reproduce it easily on Tumbleweed: Launch Xvfb: Xvfb :98 >& Xvfb.log & launch three instances of: DISPLAY=:98 glxgears in sequence; (glxgears won't work due to libGL error, but it does not matter) on the 3rd call, Xvfb crashes away with this stack trace (gdb) bt #0 glxProbeDriver (driverName=driverName@entry=0x57d1e6 "swrast", coreExt=coreExt@entry=0x15fe258, coreName=coreName@entry=0x57d1dd "DRI_Core", coreVersion=coreVersion@entry=1, renderExt=renderExt@entry=0x15fe260, renderName=renderName@entry=0x57d1d2 "DRI_SWRast", renderVersion=1) at glxdricommon.c:299 #1 0x00000000004691b3 in __glXDRIscreenProbe (pScreen=0x167bd30) at glxdriswrast.c:464 #2 0x000000000046871a in GlxExtensionInit () at glxext.c:381 #3 0x00000000004244e3 in InitExtensions (argc=argc@entry=2, argv=argv@entry=0x7fffea9c8bf8) at ../../mi/miinitext.c:339 #4 0x0000000000514537 in dix_main (argc=2, argv=0x7fffea9c8bf8, envp=<optimized out>) at main.c:208 #5 0x00007feda4bbe741 in __libc_start_main (main=0x4225d0 <main>, argc=2, argv=0x7fffea9c8bf8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffea9c8be8) at ../csu/libc-start.c:289 #6 0x0000000000422609 in _start () at ../sysdeps/x86_64/start.S:118