Bug#638741: test results
* Goswin von Brederlow goswin-...@web.de [120629 22:56]: Etienne: Could you please build a patched libao and test zsnes under multiarch to give a second point of reference? Hello, I could install zsnes:i386 on a amd64 system (with a bit pinning as #673770 blocks SDL in testing) using the patched libao and a multi-arch zsnes. But, it segfaults on start (cf attached gdb trace), I believe that it is on libao's side. Have a nice day ! -- Etienne Millon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638741: test results
* Etienne Millon etienne.mil...@gmail.com [120701 16:08]: (cf attached gdb trace) Here it is. -- Etienne Millon $ gdb zsnes GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/zsnes...(no debugging symbols found)...done. (gdb) r Starting program: /usr/bin/zsnes [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. ZSNES v1.51, (c) 1997-2007, ZSNES Team Be sure to check http://www.zsnes.com/ for the latest version. ZSNES is written by the ZSNES Team (See AUTHORS.TXT) ZSNES comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; please read 'LICENSE.TXT' thoroughly before doing so. Use ZSNES -? for command line definitions. Starting Mouse detection. Unable to poll /dev/input/event1. Make sure you have read permissions to it. Unable to poll /dev/input/event6. Make sure you have read permissions to it. Unable to poll /dev/input/event5. Make sure you have read permissions to it. Unable to poll /dev/input/event4. Make sure you have read permissions to it. Unable to poll /dev/input/event3. Make sure you have read permissions to it. Unable to poll /dev/input/event2. Make sure you have read permissions to it. Unable to poll /dev/input/event0. Make sure you have read permissions to it. ManyMouse: 0 mice detected. [New Thread 0xf669fb70 (LWP 13995)] [New Thread 0xf5d46b70 (LWP 14008)] Program received signal SIGSEGV, Segmentation fault. __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:52 52 ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S: No such file or directory. (gdb) bt #0 __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:52 #1 0xf7e7ed2a in _sanitize_matrix (maxchannels=2, matrix=0x5 Address 0x5 out of bounds, device=error reading variable: Unhandled dwarf expression opcode 0xfa, device=error reading variable: Unhandled dwarf expression opcode 0xfa) at audio_out.c:633 #2 0xf7e80a02 in _open_device (driver_id=optimized out, format=0xd318, options=0x0, file=0x0) at audio_out.c:989 #3 0x082faf8f in ?? () #4 0x082fe4df in ?? () #5 0x082fba24 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) q A debugging session is active. Inferior 1 [process 13992] will be killed. Quit anyway? (y or n) y
Bug#638741: test results
On Sun, Jul 01, 2012 at 04:11:59PM +0200, Etienne Millon wrote: * Etienne Millon etienne.mil...@gmail.com [120701 16:08]: (cf attached gdb trace) Here it is. Well, it's exploded from an access inside libao ... Program received signal SIGSEGV, Segmentation fault. __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:52 52 ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S: No such file or directory. (gdb) bt #0 __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:52 #1 0xf7e7ed2a in _sanitize_matrix (maxchannels=2, matrix=0x5 Address 0x5 out of bounds, device=error reading variable: Unhandled dwarf expression opcode 0xfa, ... but this would seem to indicate libao may have been passed an already corrupted data structure. device=error reading variable: Unhandled dwarf expression opcode 0xfa) at audio_out.c:633 #2 0xf7e80a02 in _open_device (driver_id=optimized out, format=0xd318, options=0x0, file=0x0) at audio_out.c:989 #3 0x082faf8f in ?? () #4 0x082fe4df in ?? () #5 0x082fba24 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) ... and this more or less means all bets are off for what we are really seeing here. You might want to build zsnes with debug symbols and inspect what happened prior to calling this if you want to debug it further. Cheers, Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638741: test results
* Ron r...@debian.org [120701 21:44]: ... and this more or less means all bets are off for what we are really seeing here. You might want to build zsnes with debug symbols and inspect what happened prior to calling this if you want to debug it further. You're right. I'll investigate and dump the appropriate data structures. Do you think a strace output could help too ? -- Etienne Millon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638741: test results
On Sun, Jul 01, 2012 at 09:47:41PM +0200, Etienne Millon wrote: * Ron r...@debian.org [120701 21:44]: ... and this more or less means all bets are off for what we are really seeing here. You might want to build zsnes with debug symbols and inspect what happened prior to calling this if you want to debug it further. You're right. I'll investigate and dump the appropriate data structures. Do you think a strace output could help too ? Strace probably won't help a lot here, the problem isn't really tied to interactions with system calls - my first guess would probably be that something in zsnes isn't checking an error return that it should, and continuing to call libao after some earlier operation failed. It could be something entirely different to that too, but tracing the entry to where this fell over should trip over whatever it actually is. Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638741: test results
* Ron r...@debian.org [120701 23:07]: Strace probably won't help a lot here, the problem isn't really tied to interactions with system calls - my first guess would probably be that something in zsnes isn't checking an error return that it should, and continuing to call libao after some earlier operation failed. It could be something entirely different to that too, but tracing the entry to where this fell over should trip over whatever it actually is. It has been filed as #679826, (unrelated to multiarch) -- I'll try again once it has been solved. -- Etienne Millon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638741: test results
Ron r...@debian.org writes: On Fri, Jun 29, 2012 at 07:58:59PM +0200, Goswin von Brederlow wrote: my only concern with the patch was that it breaks other sources providing plugins for libao. As Ron mentioned on irc there are none such sources in debian so this is of no concern. What I said doesn't mean there is no concern, it just means that all the things which you said would need doing - without so much as a casual look at the source or what was really needed - were completely irrelevant here. Please stop making assumptions. I did look at the source and my analysis was spot on. The only error I made was to assume from the concerns raised in the bugreport about plugins being broken that there are other sources that provide plugins for libao. I said *THIS* is of no concern, meaning that other sources, which don't exist, providing plugins break. Since they don't exist they also don't break so clearly they are not a concern. I checked the Ubuntu bugs for libao and they are not reproducable and all concern earlier versions of libao (although that needed some confident guessing) and do not apply to the mutiarch version. A few hours before the freeze is not the time to be indulging in blind guessing games and Works For Me assertions. cf. http://bash.org/?950581 Your first round of guessing what was needed here was wrong, and this round of guessing is based on equally little real and clear evidence. There is a word for certainty based on things you don't really know the full details of, but 'confidence' isn't the one that best describes it. Again you take one phrase of a sentence and apply it to a totaly different part of the sentence so you to totaly misunderstand me. As discussed on irc figuring out the version an Ubuntu bug was reported for and for which it applies is a guessing game. But given the dates and any aditional hints given in the bugreport itself I made a confident guess what version each reporter used, or at least that he didn't use the multiarch version. All that was just to show you that the multiarch patch isn't buggy just because Ubuntu has a number of bugs open for libao4 and doesn't care about closing bugs that have long since been fixed or made irelevant. An issue you raised in defense of not applying the bug. It was to uphold the argument that the patch has been tested by many people, namely all the ubuntu users that use libao4 since it was multiarchified. I would opt for including the patch before the freeze. If it breaks something unexpected then there will be enough time during the freeze to fix or revert it. It is only a freeze, not a release yet. The whole point of the freeze is to *fix* the remaining RC bugs so that we can release - not to cram in last minute untested things that introduce as many more of them as possible right before the 'deadline'. You're months too late for if it breaks something unexpected speculation. That you left reporting the remaining ia32-libs deps until the last day is bad enough, I don't see any good reason to make it unnecessarily worse. There are plenty of other m-a issues that you should be working on fixing before the wheezy+1 cycle begins without adding extra busywork to that. Ron And again you are just spewing nonesens: From: Steve Kowalik stev...@debian.org To: Debian Bug Tracking System sub...@bugs.debian.org Subject: libao4: Multi-Arch support Date: Mon, 22 Aug 2011 00:04:10 +1000 That was 10 month ago. A revised patch came in December, still 6 month for you to do something. Your first response was Fri, 29 Jun 2012 23:27:51 +0930. There is only one person to blame for not applying the patch or raising concerns about it in a timely fashion and that is you. It is your decision to make wether you accept a patch or not but then also take the blame and don't pretend you didn't have any other choice. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638741: test results
Hi, Hope you guys don't mind if I just jump in here and try to cool down the discussion, since it's getting kinda flamy. * Goswin von Brederlow wrote: That was 10 month ago. A revised patch came in December, still 6 month for you to do something. Your first response was Fri, 29 Jun 2012 23:27:51 +0930. There is only one person to blame for not applying the patch or raising concerns about it in a timely fashion and that is you. Ron mentioned he took over the package a few weeks back [0], so this blame shifting isn't really accurate (not to mention it's IMHO a bit too confrontational to be constructive; though I understand you were reacting to a equally confrontational comment from the previous email). To get some distance and perspective I'd suggest referring this to the release-team: if they see the possible downfall as an acceptable trade-off for the multi-arch release goal, then go ahead with the patching, uploading and fixing bugs as they appear. Otherwise leave it be. Cheers [0] http://packages.qa.debian.org/liba/libao/news/20120602T121911Z.html -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638741: test results
On Sun, Jul 01, 2012 at 03:58:45AM +0200, Leo 'costela' Antunes wrote: Hi, Hope you guys don't mind if I just jump in here and try to cool down the discussion, since it's getting kinda flamy. Yeah, that tends to happen when people get tired of repeating themselves to Goswin, and he keeping wanting to harp on about it ... This already got resolved on IRC, and I only replied here to make it clear to anyone looking at the bug that this really was off the table for Wheezy now. The discussion can't really get much cooler than Wheezy is now frozen. To get some distance and perspective I'd suggest referring this to the release-team: if they see the possible downfall as an acceptable trade-off for the multi-arch release goal, then go ahead with the patching, uploading and fixing bugs as they appear. Otherwise leave it be. So let's not annoy them with this now please. The only possible outcome of doing this now for them is more pain and more work and more delays before we are in a state to release. It will make it impossible for them to binNMU this package should it need it, and it will burn up their time needing to review patches that really aren't fixing anything that is remotely release critical. And they already have enough people requesting crazy freeze exceptions from them ... If nobody noticed they needed an m-a version of this before now, then clearly it's not a high priority for them, and it can easily wait until there is a better time to start experimenting with this again. The sooner the remaining RC bugs are fixed and we release, the sooner that will happen. This is how release cycles work. It's too late for untested things now. But thanks for the good intentions, Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638741: test results
Hi,
my only concern with the patch was that it breaks other sources
providing plugins for libao. As Ron mentioned on irc there are none such
sources in debian so this is of no concern.
I've tested the patch using mpg321 as test application and it works
exactly as it should. A strace shows libao opening the right multiarch
plugin dir and loading the plugins from the multiarch plugin dir as it
should:
open(/usr/lib/x86_64-linux-gnu/ao/plugins-4,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
stat(/usr/lib/x86_64-linux-gnu/ao/plugins-4/libesd.so, {st_mode=S_IFREG|0644,
st_size=10504, ...}) = 0
I checked the Ubuntu bugs for libao and they are not reproducable and
all concern earlier versions of libao (although that needed some
confident guessing) and do not apply to the mutiarch version.
Etienne: Could you please build a patched libao and test zsnes under
multiarch to give a second point of reference?
I would opt for including the patch before the freeze. If it breaks
something unexpected then there will be enough time during the freeze to
fix or revert it. It is only a freeze, not a release yet.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638741: test results
On Fri, Jun 29, 2012 at 07:58:59PM +0200, Goswin von Brederlow wrote: my only concern with the patch was that it breaks other sources providing plugins for libao. As Ron mentioned on irc there are none such sources in debian so this is of no concern. What I said doesn't mean there is no concern, it just means that all the things which you said would need doing - without so much as a casual look at the source or what was really needed - were completely irrelevant here. I checked the Ubuntu bugs for libao and they are not reproducable and all concern earlier versions of libao (although that needed some confident guessing) and do not apply to the mutiarch version. A few hours before the freeze is not the time to be indulging in blind guessing games and Works For Me assertions. cf. http://bash.org/?950581 Your first round of guessing what was needed here was wrong, and this round of guessing is based on equally little real and clear evidence. There is a word for certainty based on things you don't really know the full details of, but 'confidence' isn't the one that best describes it. I would opt for including the patch before the freeze. If it breaks something unexpected then there will be enough time during the freeze to fix or revert it. It is only a freeze, not a release yet. The whole point of the freeze is to *fix* the remaining RC bugs so that we can release - not to cram in last minute untested things that introduce as many more of them as possible right before the 'deadline'. You're months too late for if it breaks something unexpected speculation. That you left reporting the remaining ia32-libs deps until the last day is bad enough, I don't see any good reason to make it unnecessarily worse. There are plenty of other m-a issues that you should be working on fixing before the wheezy+1 cycle begins without adding extra busywork to that. Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638741: test results
* Goswin von Brederlow goswin-...@web.de [120629 22:56]: Etienne: Could you please build a patched libao and test zsnes under multiarch to give a second point of reference? I will be able to do that but not before Sunday, I'll let you know how it turns out. (NB : If one wants to do the test before, I uploaded m-a support to the zsnes git repository.) -- Etienne Millon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
