|
Bugzilla – Full Text Bug Listing |
| Summary: | missing debuginfo for mesa vdpau subpackage | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Olaf Hering <ohering> |
| Component: | X.Org | Assignee: | E-mail List <xorg-maintainer-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <xorg-maintainer-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | mls, ohering, sndirsch |
| Version: | Leap 42.1 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Possible patch. | ||
The required debuginfo is available in TW. (In reply to Olaf Hering from comment #0) > Current leap with updates. > > First the beef: > vlc crashes, gdb thankfully reports all required -debuginfo packages, zypper > installs them. > But finally libvdpau_r600-debuginfo-11.0.8-134.1.x86_64 is missing. > > Looks like libvdpau_r600.rpm is built without -g, or the debuginfo is not > packaged for some reason? No. This is probably because libvdpau_<i> for <i>={noveau, r300, r600, radeonsi} are all a hard link to libvdpau_gallium. Things should be packaged differently probably: We can only preserve the hard links if we put all libs into a single package. With this we may even get hard-linked debuginfos. @Stefan: Could you look into this? Looking into this I however found something rather strange in the buildservice log: [ 1025s] + /usr/lib/rpm/find-debuginfo.sh /home/abuild/rpmbuild/BUILD/mesa-11.1.0 [ 1025s] extracting debug info from /home/abuild/rpmbuild/BUILDROOT/Mesa-11.1.0-130.1.x86_64/usr/lib64/d3d/d3dadapter9.so.1.0.0 [ 1026s] file /home/abuild/rpmbuild/BUILDROOT/Mesa-11.1.0-130.1.x86_64/usr/lib64/dri/i915_dri.so has 4 other hard links [ 1026s] extracting debug info from /home/abuild/rpmbuild/BUILDROOT/Mesa-11.1.0-130.1.x86_64/usr/lib64/dri/i915_dri.so [ 1027s] file /home/abuild/rpmbuild/BUILDROOT/Mesa-11.1.0-130.1.x86_64/usr/lib64/dri/kms_swrast_dri.so has 6 other hard links [ 1027s] extracting debug info from /home/abuild/rpmbuild/BUILDROOT/Mesa-11.1.0-130.1.x86_64/usr/lib64/dri/kms_swrast_dri.so [..] [ 1036s] extracting debug info from /home/abuild/rpmbuild/BUILDROOT/Mesa-11.1.0-130.1.x86_64/usr/lib64/vdpau/libvdpau_nouveau.so.1.0.0 [ 1039s] cpio: glibc-2.22/csu: Cannot stat: No such file or directory [ 1039s] cpio: glibc-2.22/include/stdlib.h: Cannot stat: No such file or directory [ 1039s] cpio: glibc-2.22/stdlib: Cannot stat: No such file or directory [ 1039s] cpio: glibc-2.22/stdlib/atexit.c: Cannot stat: No such file or directory [ 1039s] cpio: glibc-2.22/sysdeps/x86_64/crti.S: Cannot stat: No such file or directory [ 1039s] cpio: glibc-2.22/sysdeps/x86_64/crtn.S: Cannot stat: No such file or directory [ 1040s] cpio: src/glsl/glcpp/glcpp-lex.l: Cannot stat: No such file or directory [ 1040s] cpio: src/glsl/glcpp/glcpp-parse.y: Cannot stat: No such file or directory [ 1040s] cpio: src/glsl/glsl_lexer.ll: Cannot stat: No such file or directory [ 1040s] cpio: src/glsl/glsl_parser.yy: Cannot stat: No such file or directory [ 1040s] cpio: src/mesa/program/program_lexer.l: Cannot stat: No such file or directory [ 1040s] cpio: src/mesa/program/program_parse.y: Cannot stat: No such file or directory [ 1040s] 89854 blocks Not sure why this happens. @Michael, do you hae an idea what's happening here? > Name : libvdpau_r600 > Source RPM : Mesa-11.0.8-134.1.src.rpm > > > Now the noise: > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffad087700 (LWP 12869)] > dri_flush (cPriv=0x100000000, dPriv=0x7fffa817bea0, flags=1, ^^^^^ This is a pointer. However the value is strange. It sort of looks like it is some sort of canary. Ultimately it's the same pointer (ie context) as the GLX context. At first glance you may want to put a watchpoint on __glX_tls_Context and see who wedges it. > reason=__DRI2_THROTTLE_SWAPBUFFER) at dri_drawable.c:444 > 444 struct dri_context *ctx = dri_context(cPriv); > Missing separate debuginfos, use: zypper install > libvdpau_r600-debuginfo-11.0.8-134.1.x86_64 > (gdb) up > #1 0x00007fffe86a8bae in dri2SwapBuffers (pdraw=0x7fffa817ac70, > target_msc=0, divisor=0, remainder=0, flush=0) at dri2_glx.c:851 > 851 dri2Flush(psc, ctx, priv, flags, __DRI2_THROTTLE_SWAPBUFFER); > (gdb) l > 846 } else { > 847 __DRIcontext *ctx = dri2GetCurrentContext(); ^^^^^ This one. > 848 unsigned flags = __DRI2_FLUSH_DRAWABLE; > 849 if (flush) > 850 flags |= __DRI2_FLUSH_CONTEXT; > 851 dri2Flush(psc, ctx, priv, flags, __DRI2_THROTTLE_SWAPBUFFER); ^^^ ||| > 852 > 853 ret = dri2XcbSwapBuffers(pdraw->psc->dpy, pdraw, > 854 target_msc, divisor, remainder); > 855 } > (gdb) p priv > $1 = (struct dri2_drawable *) 0x7fffa817ac70 Nope, not this one.(In reply to Olaf Hering from comment #1) > The required debuginfo is available in TW. (In reply to Olaf Hering from comment #1) > The required debuginfo is available in TW. Where do you see this? If you mean those "Cannot stat" warnings, they are perfectly normal. Just ignore them. (In reply to Egbert Eich from comment #2) > > 847 __DRIcontext *ctx = dri2GetCurrentContext(); > ^^^^^ > This one. This was optimized away, I will see what I find. > (In reply to Olaf Hering from comment #1) > > The required debuginfo is available in TW. > Where do you see this? TW crashes the same way, but its gdb does not complain about missing debuginfo. (In reply to Michael Schröder from comment #3) > If you mean those "Cannot stat" warnings, they are perfectly normal. Just > ignore them. Ah, ok, thanks for the reply! (In reply to Olaf Hering from comment #4) > (In reply to Egbert Eich from comment #2) > > > > 847 __DRIcontext *ctx = dri2GetCurrentContext(); > > ^^^^^ > > This one. > > This was optimized away, I will see what I find. Sure. But I did indicate how it could be debugged. > > (In reply to Olaf Hering from comment #1) > > > The required debuginfo is available in TW. > > Where do you see this? > > TW crashes the same way, but its gdb does not complain about missing > debuginfo. I checked factory and did not see any debuginfo package for this. Olaf, this is an issue happening in a library that can only be debugged in connection with the application using the library. I don't really feel inclined in getting involved in VLC, therefore you will have to bear with me and look into this yourself. It could be that this issue occurs due to the wrong use of libGL or is triggered by the way VLC calls the library. Once you know more, please feel free to get back to me, I will try to help you. Currently we have the Mesa packaging issue which I asked stefan to look after. Once this is done, we can either close this ticket and communicate thru some other channel or reassign it to you with me in Cc. (In reply to Egbert Eich from comment #5) > (In reply to Olaf Hering from comment #4) > > (In reply to Egbert Eich from comment #2) > > > > > > 847 __DRIcontext *ctx = dri2GetCurrentContext(); > > > ^^^^^ > > > This one. > > > > This was optimized away, I will see what I find. > Sure. But I did indicate how it could be debugged. dri2Ctx is dummyContext and ->driContext is 0x100000000 This is from an audio visualizer, the other ones available appear to work. You could try and catch this in dri2GetCurrentContext() however I'm not sure if this is a valid solution.
The remark in ./src/glx/glxcurrent.c even suggests that this is required and the test for NULL is bogus:
Thus:
dri2GetCurrentContext()
{
struct glx_context *gc = __glXGetCurrentContext();
struct dri2_context *dri2Ctx = (struct dri2_context *)gc;
- return dri2Ctx ? dri2Ctx->driContext : NULL;
+ return (gc != dummyContext) ? dri2Ctx->driContext : NULL;
}
If I find a few minutes I will create a test package for you.
(In reply to Egbert Eich from comment #2) > No. This is probably because libvdpau_<i> for <i>={noveau, r300, r600, > radeonsi} > are all a hard link to libvdpau_gallium. Things should be packaged > differently probably: > We can only preserve the hard links if we put all libs into a single package. > With this we may even get hard-linked debuginfos. > > @Stefan: Could you look into this? Egbert, you're right. These libs have the same size and same content. -rwxr-xr-x 1 sndirsch suse 4396016 23. Okt 07:21 libvdpau_nouveau.so.1.0.0 -rwxr-xr-x 1 sndirsch suse 4396016 23. Okt 07:21 libvdpau_r300.so.1.0.0 -rwxr-xr-x 1 sndirsch suse 4396016 23. Okt 07:21 libvdpau_r600.so.1.0.0 -rwxr-xr-x 1 sndirsch suse 4396016 23. Okt 07:21 libvdpau_radeonsi.so.1.0.0 1e6b5b8c972983ae177e1ccce9b8d20b libvdpau_nouveau.so.1.0.0 1e6b5b8c972983ae177e1ccce9b8d20b libvdpau_r300.so.1.0.0 1e6b5b8c972983ae177e1ccce9b8d20b libvdpau_r600.so.1.0.0 1e6b5b8c972983ae177e1ccce9b8d20b libvdpau_radeonsi.so.1.0.0 The reason for splitting them up is (or at least was) that they are not all considered to have the same stability, i.e. some are rather robust and some are (or were) considered in experimental state. In leap there is a debuginfo package for libvdpau_nouveau, but not for libvdpau_r300/libvdpau_r600/libvdpau_radeonsi. Indeed this appears to be the hard link issue. [ 294s] file /home/abuild/rpmbuild/BUILDROOT/Mesa-11.0.2-0.x86_64/usr/lib64/dri/i915_dri.so has 4 other hard links [ 294s] extracting debug info from /home/abuild/rpmbuild/BUILDROOT/Mesa-11.0.2-0.x86_64/usr/lib64/dri/i915_dri.so No issue, since all these dri libs in the same package. [ 295s] file /home/abuild/rpmbuild/BUILDROOT/Mesa-11.0.2-0.x86_64/usr/lib64/dri/kms_swrast_dri.so has 6 other hard links [ 295s] extracting debug info from /home/abuild/rpmbuild/BUILDROOT/Mesa-11.0.2-0.x86_64/usr/lib64/dri/kms_swrast_dri.so No issue, since all these dri libs in the same package. [ 296s] file /home/abuild/rpmbuild/BUILDROOT/Mesa-11.0.2-0.x86_64/usr/lib64/libXvMCnouveau.so.1.0.0 has 1 other hard links [ 296s] extracting debug info from /home/abuild/rpmbuild/BUILDROOT/Mesa-11.0.2-0.x86_64/usr/lib64/libXvMCnouveau.so.1.0.0 Two different subpackages (libXvMC_nouveau vs. libXvMC_r600). libXvMC_r600 is not being generated. [ 298s] file /home/abuild/rpmbuild/BUILDROOT/Mesa-11.0.2-0.x86_64/usr/lib64/vdpau/libvdpau_nouveau.so.1.0.0 has 3 other hard links [ 298s] extracting debug info from /home/abuild/rpmbuild/BUILDROOT/Mesa-11.0.2-0.x86_64/usr/lib64/vdpau/libvdpau_nouveau.so.1.0.0 libvdpau_r300/libvdpau_r600/libvdpau_radeonsi are not being generated. See above. Is there a generic approach to address that issue? I guess the best thing to try is replacing the hard links with copies. I'll try that first. Created attachment 662499 [details]
Possible patch.
There's a test package for Leap-42.1 with this fix available in my home on OBS: home:eeich:boo962609.
(In reply to Egbert Eich from comment #9) > Created attachment 662499 [details] Thanks. Tested OK in TW. I see the crash in 13.2/Leap/TW but not in 13.1. (In reply to Olaf Hering from comment #10) > (In reply to Egbert Eich from comment #9) > > Created attachment 662499 [details] > > Thanks. Tested OK in TW. I see the crash in 13.2/Leap/TW but not in 13.1. The test package was for Leap 42.1 - did you install it on TW? Can you test it on Leap 42.1 as well? I would go and backport the fix to all but I'd need your test result for Leap 42.1 as well. Thanks. Actually, NEEDINFO to reporter. (In reply to Stefan Dirsch from comment #8) > Is there a generic approach to address that issue? I guess the best thing to > try is replacing the hard links with copies. I'll try that first. Worked out fine. Done for obs://X11:XOrg and upcoming factory/TW. https://build.opensuse.org/request/show/355034 (In reply to Egbert Eich from comment #11) > The test package was for Leap 42.1 - did you install it on TW? No, I just built my own earlier for TW. The pkg for Leap works as well. This is an autogenerated message for OBS integration: This bug (962609) was mentioned in https://build.opensuse.org/request/show/355068 Factory / Mesa https://build.opensuse.org/request/show/355070 42.1+13.2 / Mesa Fix submitted: 13.2 and Leap 42.1: MR ID#355070 Factory: SR ID#355068 Both issue is FIXED. openSUSE-RU-2016:0281-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 962609 CVE References: Sources used: openSUSE Leap 42.1 (src): Mesa-11.0.8-137.1 openSUSE 13.2 (src): Mesa-10.3.7-91.12.1 SUSE-RU-2016:1210-1: An update that has three recommended fixes can now be installed. Category: recommended (low) Bug References: 945444,962609,970725 CVE References: Sources used: SUSE Linux Enterprise Workstation Extension 12-SP1 (src): Mesa-10.0.2-97.1, libGLw-7.11.2-14.1 SUSE Linux Enterprise Workstation Extension 12 (src): Mesa-10.0.2-97.1, libGLw-7.11.2-14.1 SUSE Linux Enterprise Software Development Kit 12-SP1 (src): Mesa-10.0.2-97.1, libGLw-7.11.2-14.1 SUSE Linux Enterprise Software Development Kit 12 (src): Mesa-10.0.2-97.1, libGLw-7.11.2-14.1 SUSE Linux Enterprise Server 12-SP1 (src): Mesa-10.0.2-97.1 SUSE Linux Enterprise Server 12 (src): Mesa-10.0.2-97.1 SUSE Linux Enterprise Desktop 12-SP1 (src): Mesa-10.0.2-97.1, libGLw-7.11.2-14.1 SUSE Linux Enterprise Desktop 12 (src): Mesa-10.0.2-97.1, libGLw-7.11.2-14.1 |
Current leap with updates. First the beef: vlc crashes, gdb thankfully reports all required -debuginfo packages, zypper installs them. But finally libvdpau_r600-debuginfo-11.0.8-134.1.x86_64 is missing. Looks like libvdpau_r600.rpm is built without -g, or the debuginfo is not packaged for some reason? Name : libvdpau_r600 Source RPM : Mesa-11.0.8-134.1.src.rpm Now the noise: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffad087700 (LWP 12869)] dri_flush (cPriv=0x100000000, dPriv=0x7fffa817bea0, flags=1, reason=__DRI2_THROTTLE_SWAPBUFFER) at dri_drawable.c:444 444 struct dri_context *ctx = dri_context(cPriv); Missing separate debuginfos, use: zypper install libvdpau_r600-debuginfo-11.0.8-134.1.x86_64 (gdb) up #1 0x00007fffe86a8bae in dri2SwapBuffers (pdraw=0x7fffa817ac70, target_msc=0, divisor=0, remainder=0, flush=0) at dri2_glx.c:851 851 dri2Flush(psc, ctx, priv, flags, __DRI2_THROTTLE_SWAPBUFFER); (gdb) l 846 } else { 847 __DRIcontext *ctx = dri2GetCurrentContext(); 848 unsigned flags = __DRI2_FLUSH_DRAWABLE; 849 if (flush) 850 flags |= __DRI2_FLUSH_CONTEXT; 851 dri2Flush(psc, ctx, priv, flags, __DRI2_THROTTLE_SWAPBUFFER); 852 853 ret = dri2XcbSwapBuffers(pdraw->psc->dpy, pdraw, 854 target_msc, divisor, remainder); 855 } (gdb) p priv $1 = (struct dri2_drawable *) 0x7fffa817ac70 (gdb) bt #0 dri_flush (cPriv=0x100000000, dPriv=0x7fffa817bea0, flags=1, reason=__DRI2_THROTTLE_SWAPBUFFER) at dri_drawable.c:444 #1 0x00007fffe86a8bae in dri2SwapBuffers (pdraw=0x7fffa817ac70, target_msc=0, divisor=0, remainder=0, flush=0) at dri2_glx.c:851 #2 0x00007fff9def48fb in vlc_gl_Swap (gl=0x7fffa808a128) at ../../include/vlc_opengl.h:87 #3 Thread (p_data=0x7fffa0002858) at glspectrum.c:552 #4 0x00007ffff79a60a4 in start_thread (arg=0x7fffad087700) at pthread_create.c:309 #5 0x00007ffff74d804d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 (gdb)