Bug 962609 - missing debuginfo for mesa vdpau subpackage
missing debuginfo for mesa vdpau subpackage
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: X.Org
Leap 42.1
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-19 14:57 UTC by Olaf Hering
Modified: 2016-05-03 23:08 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Possible patch. (998 bytes, patch)
2016-01-20 14:37 UTC, Egbert Eich
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Olaf Hering 2016-01-19 14:57:53 UTC
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)
Comment 1 Olaf Hering 2016-01-19 15:25:55 UTC
The required debuginfo is available in TW.
Comment 2 Egbert Eich 2016-01-19 20:42:57 UTC
(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?
Comment 3 Michael Schröder 2016-01-20 09:33:25 UTC
If you mean those "Cannot stat" warnings, they are perfectly normal. Just ignore them.
Comment 4 Olaf Hering 2016-01-20 09:45:07 UTC
(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.
Comment 5 Egbert Eich 2016-01-20 10:15:27 UTC
(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.
Comment 6 Olaf Hering 2016-01-20 11:30:13 UTC
(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.
Comment 7 Egbert Eich 2016-01-20 12:32:30 UTC
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.
Comment 8 Stefan Dirsch 2016-01-20 14:15:37 UTC
(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.
Comment 9 Egbert Eich 2016-01-20 14:37:04 UTC
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.
Comment 10 Olaf Hering 2016-01-20 14:49:47 UTC
(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.
Comment 11 Egbert Eich 2016-01-20 15:55:05 UTC
(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.
Comment 12 Egbert Eich 2016-01-20 15:55:34 UTC
Actually, NEEDINFO to reporter.
Comment 13 Stefan Dirsch 2016-01-20 16:08:37 UTC
(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
Comment 14 Olaf Hering 2016-01-20 16:15:36 UTC
(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.
Comment 16 Bernhard Wiedemann 2016-01-20 20:00:12 UTC
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
Comment 17 Egbert Eich 2016-01-20 20:00:59 UTC
Fix submitted:
13.2 and Leap 42.1: MR ID#355070
Factory: SR ID#355068
Comment 19 Egbert Eich 2016-01-20 20:06:31 UTC
Both issue is FIXED.
Comment 20 Swamp Workflow Management 2016-01-29 14:11:45 UTC
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
Comment 21 Swamp Workflow Management 2016-05-03 23:08:14 UTC
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