As per summary, Miguel Freitas reverted this patch just last night before the release because ti introduces (for him at least) a crash while using tomsmocomp deinterlace plugin; I couldn't reproduce the crash (but I'm on AMD64) and I didn't get any other report but his on Gentoo's bugzilla or otherwise. Can someone take a look to that part? The patch is still available on 1.1.3's patchset.
can we get more details on this crash? like, command line/files to reproduce it, or at least some gdb info about the coredump (bt, x/8i $pc, i r, etc.
If I had I would have tried debugging it myself :/
<solar> Flameeyes: we need more details on bug 164425 also. <Flameeyes> solar, I would like to have more of them too <solar> then lets add the patch back to it till he can provide proper details <solar> those textrels end up propogating into everything all over and takes a long time to get the bogus bugs sorted out <Flameeyes> solar, I'll try to reproduce it in the next day or so, I didn't get any warning about it being disabled so I was surprised by that <solar> Flameeyes: know the guys email? <Flameeyes> "Miguel Freitas" <mfreitas@gmail.com>
Mailed Miguel the following. To: mfreitas@gmail.com Subject: TEXTREL patch reverted in xine-lib Date: Mon, 29 Jan 2007 13:01:09 -0800 Miguel, Hi you ended up reverting a textrel patch in xine-lib without any prior notice. Our small group has a strong interest is seeing this properly fixed. So could you please provide details, debug output and a test case so we can reproduce the crash and provide an updated fix. We are using https://bugs.gentoo.org/show_bug.cgi?id=164425 to track this issue. Thanks in advance.
(In reply to comment #4) Miguel replied the following. Hi Ned, On 1/29/07, Ned Ludd <solar@gentoo.org> wrote: > Hi you ended up reverting a textrel patch in xine-lib without any prior > notice. well, actually i would rephrase this from a different perspective... i reverted a patch that was committed to xine-lib cvs without any prior notice ;-) the patch caused immediate segfault, which led me to think it was not even tested. the problem was reported in december in our mailing list and also reported in our bugtracker. https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1635393&group_id=9655 > Our small group has a strong interest is seeing this properly > fixed. So could you please provide details, debug output and a test case > so we can reproduce the crash and provide an updated fix. > > We are using > https://bugs.gentoo.org/show_bug.cgi?id=164425 > to track this issue. I have nothing against this patch, although i don't know exactly what it is meant to solve. I know pax team is committed to providing high quality security patches, so i believe you may just have missed some basic info. first, afaict, the patch was committed without any prior notice. most of the assembly code in deinterlacer plugin comes from the tvtime project, so i believe you should first try patching it upstream. then just let us know to resync with tvtime or say "tvtime has already accepted this patch, here is the patch for xine" or something. then about testing the patch. you should play some interlaced media (eg. a lot of dvds are interlaced), then under xine-ui select (right button)->video->postprocess->chain reaction->tvtime, method: TomsMoComp. crash is immediate (confirmed both i586 and x64). regards, Miguel
Actually, I did ask for comment on that patch for a while on xine-devel, posted it once, maybe twice, and the only reported problem was (allegedly) a failure to play a not-better-identified QuickTime media with win32codecs; no backtrace nor pointer to the media was provided though. I committed it after also Debian and Ubuntu packaging started using the same patch, Pardus used it for a while too, and I didn't get any other report of failure. The SF.net tracker does not provide a backtrace, and as I said I cannot reproduce it, *but* there's one thing that might explain why I can't reproduce it here: all the media I have is in PAL format, no NTSC, so it might be related to that (the A/V sync problem was related to that and I couldn't reproduce it either). And if I knew there was a release going to happen, I would have prepared the patching again. Another possibility is that the problem is GCC related, here I've been using 4.1 for all this time. Plus I don't remember any TEXTREL related to tvtime (that I actually use and keep an eye upon for a while now).
(In reply to comment #6) > Plus I don't remember any TEXTREL related to tvtime (that I actually use and > keep an eye upon for a while now). tvtime doesn't produce libraries, only executables so no wonder that textrels don't show up in there (on a hardened system with enforced PIE they would, i think).
I remember I had another report in the past about PIE and tvtime, so I suppose at least one user who could have reported it there was/there is. If I didn't think of this I wouldn't have said it in the first place :)
At least xine-lib-1.1.6 doesn't seem to contain any DT_TEXTREL's anymore ..
Considering I didn't touch that code after Miguel's revert, this comes as a surprise to me..
(In reply to comment #9) > At least xine-lib-1.1.6 doesn't seem to contain any DT_TEXTREL's anymore .. (In reply to comment #10) > Considering I didn't touch that code after Miguel's revert, this comes as a > surprise to me.. I wonder why that didn't show up when emerging ... # qlist xine-lib | xargs scanelf -lqt TEXTREL TEXTREL /usr/lib/libxvidcore.so.4.1 TEXTREL /usr/lib/xine/plugins/1.1.6/post/xineplug_post_tvtime.so # emerge -pqv xine-lib [ebuild R ] media-libs/xine-lib-1.1.6 USE="X a52 aac alsa arts dts dvd flac mad opengl vorbis win32codecs xinerama xv -aalib (-altivec) -debug -directfb -dxr3 -esd -fbcon -gnome -gtk -imagemagick -ipv6 -jack -libcaca -mmap -mng -modplug -musepack -nls -oss -pulseaudio -real -samba -sdl -speex -theora -truetype -v4l -vcd -vidix -wavpack -xcb -xvmc"
(In reply to comment #11) > (In reply to comment #9) > > At least xine-lib-1.1.6 doesn't seem to contain any DT_TEXTREL's anymore .. > > (In reply to comment #10) > > Considering I didn't touch that code after Miguel's revert, this comes as a > > surprise to me.. > > I wonder why that didn't show up when emerging ... > > # qlist xine-lib | xargs scanelf -lqt TEXTREL > TEXTREL /usr/lib/libxvidcore.so.4.1 > TEXTREL /usr/lib/xine/plugins/1.1.6/post/xineplug_post_tvtime.so And even that isn't right ... # qlist -ae xine-lib | scanelf -f - -qt TEXTREL /usr/lib/xine/plugins/1.1.6/post/xineplug_post_tvtime.so
Created attachment 156135 [details, diff] textrel fix for xineplug_post_tvtime.so (tomsmocomp) hi folks, it's been a while but i had some time today and fixed up the patch for latest xine-lib (i think i also found the earlier crash bug too), so please give it a try. since i didn't and won't deal with gcc 2.x compatibility (inline asm parameter limit), you probably won't get this accepted upstream and will have to maintain it in gentoo.
Well, xine upstream is now.. me, and I give shit about gcc 2.x ;) Especially since FFmpeg doesn't support that anymore, and xine has an hard dep on FFmpeg. So yeah most likely I'll merge this upstream :)
Created attachment 158957 [details, diff] textrel fix for xineplug_post_tvtime.so (tomsmocomp) just a simple forward port, even the old patch applies cleanly.
is this fixed? should the bug be closed?
Don't think so. Don't see the patch in portage and still seeing TEXTREL in /usr/lib/xine/plugins/1.24/post/xineplug_post_tvtime.so as of media-libs/xine-lib-1.1.15-r1. Will test that the patch still works w/ current and report back if somebody doesn't beat me to it.
Created attachment 165923 [details, diff] textrel fix for xineplug_post_tvtime.so (tomsmocomp) old patch applies cleanly.
just a heads up, the .15 patch still applies cleanly, i won't bother you with another useless attachement ;). Diego/anyone, can this go anywhere now please (portage or upstream)?
A little note: xine-lib 1.1.16.3 still creates TEXTRELs in tvtime and patch from comment 18 still works to fix that (I'm on x86, if that matters).
(In reply to comment #20) > A little note: xine-lib 1.1.16.3 still creates TEXTRELs in tvtime > and patch from comment 18 still works to fix that (I'm on x86, > if that matters). > Anoter little note: xine-lib 1.1.16.3-r1 still creates TEXTRELs in its tvtime so and the patch from comment #18 still works. Big credit still goes to PaXTeam and a request is still pending to push it into portage. If it look too intrusive, it can be made to be conditional to USE hardened... Dw.
Created attachment 202598 [details, diff] proposed change to the current xine-lib ebuild Please push it into production
Created attachment 202602 [details, diff] patch conditional on hardened use flag
Added in =media-libs/xine-lib-1.1.16.3-r2. Sorry this bug was handled so slowly and thank you very much PaX Team, Attila Tóth and testers.
The patch is not applied: >>> Emerging (1 of 1) media-libs/xine-lib-1.1.16.3-r2 * xine-lib-1.1.15-textrel-fix.patch RMD160 SHA1 SHA256 size ;-) ... [ ok ] * xine-lib-1.1.16.3.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking xine-lib-1.1.15-textrel-fix.patch to /var/tmp/portage/media-libs/xine-lib-1.1.16.3-r2/work unpack xine-lib-1.1.15-textrel-fix.patch: file format not recognized. Ignoring. >>> Unpacking xine-lib-1.1.16.3.tar.bz2 to /var/tmp/portage/media-libs/xine-lib-1.1.16.3-r2/work * Applying xine-lib-1.1.16.3-libmpcdecsv7.patch ... [ ok ] * Applying xine-lib-1.1.15-textrel-fix.patch ... [ ok ] * Running eautoreconf in '/var/tmp/portage/media-libs/xine-lib-1.1.16.3-r2/work/xine-lib-1.1.16.3' ... * Running aclocal -I m4 ...
(In reply to comment #25) > The patch is not applied: Wrong. > * Applying xine-lib-1.1.15-textrel-fix.patch ... > [ ok ] See the [ok] ?
(In reply to comment #26) > (In reply to comment #25) > > The patch is not applied: > > Wrong. > > > * Applying xine-lib-1.1.15-textrel-fix.patch ... > > [ ok ] > > See the [ok] ? > Right. Sorry for the noise.
