Bug#888377: karlyriceditor: diff for NMU version 1.11-2.1
Hi Sebastian, Thank you for your efforts! I am fine with the NMU you are suggesting, so if you want, you can let it go through immediately (no more delay necessary). Cheers, Martin On 11/07/18 22:29 Sebastian Ramacher wrote: Control: tags 888377 + pending Dear maintainer, I've prepared an NMU for karlyriceditor (versioned as 1.11-2.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Cheers
Bug#899571: [Pkg-mpd-maintainers] mpd is marked for autoremoval from testing
Hi, I can take a look at migrating the list. However, I understand that there has to be a DD assigned as the owner, but I'm not a DD. Cheers, Martin On 11/07/18 13:50 Petter Reinholdtsen wrote: [Florian Schlichting] Hello libfishsound Maintainers/Uploaders, given that your package maintainer address has become invalid, are you aware of #899571 and are you planning to act on that in the forseeable future? Failing that, do you have any preference how this should be handled through an NMU? I lack the space free time to look into this myself in the forseeable future. I am aware the is being discussed on #debian-multimedia. I urge each of you to join in on that discussion.
Bug#821321: libvorbisfile: ov_pcm_seek wrongly returns OV_EOF or segfaults sometimes
Hi Frank,
Thank you for your bug report!
Judging from the code that reproduces the bug (two subsequent seeks to
0) and from the related vorbis code you are mentioning, this sounds a
lot like #782831, which was fixed in 1.3.4-3. Could you confirm or
refute that theory by testing your code (I guess you have further
examples apart from the one you posted) with 1.3.4-3?
Cheers,
Martin
El 17/04/16 a les 18:56, Frank Heckenbach ha escrit:
Package: libvorbisfile3
Version: 1.3.4-2
Severity: important
ov_pcm_seek wrongly returns OV_EOF or segfaults sometimes. I've
observed it in some situations, below is a very simple one to
reproduce. It's an important problem to me, because (unless fixed or
you can tell me exactly when seeking will work), I'd have to treat
all Ogg/Vorbis files as unseekable in my code, which would be a huge
performance penalty (decoding sequentially and buffering all in
memory).
% cat test.c
#include
#include
int main ()
{
OggVorbis_File vf;
fprintf (stderr, "%i\n", ov_fopen ("foo.ogg", &vf));
fprintf (stderr, "%i\n", ov_pcm_seek (&vf, 0));
fprintf (stderr, "%i\n", ov_pcm_seek (&vf, 0));
return 0;
}
% head -c 10 /dev/zero|oggenc -Q -r - -o foo.ogg&& gcc -g test.c -lvorbisfile
&& ./a.out
On i386:
0
0
-2
On amd64:
0
0
Segmentation fault
I tried to debug it and found: The 2nd time ov_pcm_seek_is_called
(from the 2nd ov_pcm_seek call), at line 1461
if(bisect!=vf->offset){
result=_seek_helper(vf,bisect);
if(result) goto seek_error;
}
begin == 3997 and vf->offset == 3997, so the call to _seek_helper is
skipped. However, ftell((FILE*)vf->datasource) == 4076, so it goes
on with a wrong file position, so _get_next_page fails and og
remains unintialized and ogg_page_serialno(&og) (line 1554) results
in UB.
I don't really understand the code: Telling from this line,
vf->offset should reflect the actual position of the data source.
But if so, I'd expect it to be adjusted after each successfull call
of seek_func (that's correctly done) and read_func. read_func is
only called from _get_data, but it doesn't adjust vf->offset.
Instead it puts the data into an internal buffer AFAIUI, so the
users of the data from the buffer are probably responsible for
adjusting vf->offset, but apparently something goes wrong there.
If I just set vf->offset to 4076 before line 1461 (2nd time), it
continues correctly. That's of course, not a fix, just an indication
that the wrong value of vf->offset is the real problem here.
Maybe vf->offset just needs to be revalidated before line 1461, but
it's used in many places, and I don't know how many of them might be
affected too.
-- System Information:
Debian Release: 8.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libvorbisfile3:amd64 depends on:
ii libc6 2.19-18+deb8u4
ii libogg01.3.2-1
ii libvorbis0a1.3.4-2
ii multiarch-support 2.19-18+deb8u4
libvorbisfile3:amd64 recommends no packages.
libvorbisfile3:amd64 suggests no packages.
-- no debconf information
Bug#818037: vorbis-tools: vcut always(?) segfaults
Frank Heckenbach wrote: The patch is in the git repository. Where can I get it (just the patch, so I can try it against the jessie version)? https://git.xiph.org/ says: vorbis-tools.git ... Last change 5 months ago It's not yet in the upstream git repository (I submitted the patch through their bug tracker, but someone from upstream has to check it and apply it), but in our (the Debian package's) git repository. You can find the patch here: https://anonscm.debian.org/cgit/pkg-xiph/vorbis-tools.git/tree/debian/patches/Fix-segfault-in-vcut.patch
Bug#818037: vorbis-tools: vcut always(?) segfaults
tags 818037 + pending thanks Frank Heckenbach wrote: Sorry for the brief description, but for what I can tell, that's really it. I tried various cases, and vcut always seems to just segfault. Here's one example: % head -c 50 /dev/zero | oggenc -Q -r -o 1.ogg - % vcut 1.ogg 2.ogg 3.ogg +1 Processing: Cutting at 1,00 seconds Segmentation fault Tried on both i386 and amd64. It did work correctly under squeeze and wheezy. Thanks for the report! I debugged it and found the problem. It was a simple indexing problem that seemed to have slipped away during quite some time because of a lucky memory layout: The pointer resulting from the wrong indexing points to the stack and therefore to valid memory (in terms of memory management), unless the block is too big. Now the memory layout has changed for some reason (GCC 5?), therefore we read a different value as block size, the block is too big for the stack and we get the segmentation faults. The patch is in the git repository. Cheers, Martin
Bug#803828: karlyriceditor: FTBFS with FFmpeg 2.9
Thanks Felipe for the upload, thanks Andreas for the patch! Martin
Bug#803828: karlyriceditor: FTBFS with FFmpeg 2.9
Felipe Sateler wrote: Thanks. I'm confused though: there are still deprecation warnings: ffmpegvideoencoder.cpp:264:24: warning: 'AVCodecContext::coded_frame' is deprecated [-Wdeprecated-declarations] if ( audioCodecCtx->coded_frame && audioCodecCtx->coded_frame->pts != AV_NOPTS_VALUE ) And multiple copies of that. Is this an unrelated warning(ie, scheduled for removal on a later version?). Andreas' patch only includes the fixes necessary to make things work with FFmpeg 3.0, but doesn't remove the use of all deprecated parts of the API. The warnings refer to features, which are still included in the 3.0 API, but are deprecated. So the package works with FFmpeg 3.0 (compilation tested by Andreas and runtime tested by me), but might break with FFmpeg 3.1 or any other future version of FFmpeg. But making the code future-proof is IMO a task for upstream (unless 3.1 arrives at Debian before they do so). Cheers, Martin
Bug#803828: karlyriceditor: FTBFS with FFmpeg 2.9
Felipe Sateler wrote: Please update the changelog fully to add the bug closure and upload distro (if you want, you can do it on a different branch that is only merged to master once the package is in the archive). Sorry. Please find the updated changelog in https://github.com/martin-steghoefer/debian-karlyriceditor/commits/1.11-2 (branch "1.11-2" of the same repository as before). Cheers, Martin
Bug#803828: karlyriceditor: FTBFS with FFmpeg 2.9
Hi Andreas, Andreas Cadhalpun wrote: I think there is a misunderstanding here. The deprecation of the APIs this patch is about happened several years ago, so fixing the code is certainly not premature, rather the contrary. The goal is that all Debian packages are ready for the new upstream release, where these long deprecated APIs have been removed, when it gets released. Otherwise the transition will be (a lot) less smooth. So please don't keep waiting. [...] I don't really understand this as you can test the replacement APIs with any release of the recent years. The only thing you can't test (without compiling from upstream git) is whether it will build with the new version of ffmpeg. But you don't have to test that, because I (compile-)tested my patch with upstream git. I do trust in the fact that the API is stable, and if the API is well specified and the implementation follows it, then there shouldn't be a problem. But you know how it is, there can always be unexpected runtime behaviors in the gray areas of the API, or implementations that don't completely respect what is specified in the API. And since I depend on sponsors, I'd like to make sure the update is complete. But anyway, since you offered a sponsor for the upload (see below), I don't mind uploading a version that is not yet tested with the new FFmpeg 2.9, as long as it works with the current FFmpeg (which I tested). I'm sure Felipe Sateler (who kindly offered to help with uploads for this transition) would be willing to sponsor this upload, like he did for dvbcut [1]. So as a way forward I suggest: * You prepare a package with this fix. * Optionally let me know how to test it, and I'll test with upstream git. * We ask Felipe to sponsor the upload. Does that sound good to you? Sounds great. Please find the new version of the package in the package's git repository: https://github.com/martin-steghoefer/debian-karlyriceditor Thanks again for the patch and for managing the transition. Cheers, Martin
Bug#803828: karlyriceditor: FTBFS with FFmpeg 2.9
severity 803828 minor thanks Hi Andreas, There was no update on this bug report because I found any upload on this matter premature. When this bug was reported, there was no transition yet [1] and the FFmpeg version you wanted to upgrade to hadn't even been release by upstream [2]. Nothing of this has changed so far, so I keep waiting. I thank you for your patch and your initiative and hope you understand that I can't very well upload anything before the version we are upgrading to is actually released and I can test its compatibility. When you first posted this report, I checked out your patch and confirmed that it doesn't break anything. But I can't be sure that it will fix all compatibility issues with FFmpeg 2.9/3.0 - because it doesn't exist yet. Since I am not a DD or DM, all my uploads have to go through sponsors, so I really want to get it right the first time. Cheers, Martin [1] https://release.debian.org/transitions/ [2] https://www.ffmpeg.org/download.html#releases Andreas Cadhalpun wrote: Dear Maintainer, the next version of FFmpeg is planned to be released this month (and it might be called 3.0 instead of 2.9). Since I haven't heard back from you during the past two month I'm wondering what the status of this bug is: * Are you aware of the patch I provided? * Do you plan an upload soon? * Is upstream aware of the problem? If this bug isn't fixed soon, it will become release critical and thus the package will either get NMUed or removed from testing. Also there is a new upstream version (2.1) available, which could be uploaded together with this patch. Best regards, Andreas
Bug#798960: libvorbis: Please upgrade to 1.3.5
No technical reason, just not enough time to test is as well as the number of reverse dependencies would demand it for a new upstream release. My testing efforts so far: * Test compilation of vorbis-tools against the libvorbis-dev package * Perform very basic tests of the ogg-vorbis related functionality of: audacity, vorbis-tools (oggenc, oggdec, ogg123), vlc, supertux, 0ad, audacious * Have it installed in my production system for several days (however, with very little ogg-vorbis related activity) But I guess, we could at least upload it to experimental. Petter, what do you think? Cheers, Martin Sebastien Bacher wrote: Hey there, is that update still being worked on or is it blocking on something?
Bug#795708: /usr/bin/ogg123: ogg123: Metadata_block_picture comments spew base64 all over the screen
Note: A bug report about the same issue seems to be present upstream: https://trac.xiph.org/ticket/1570
Bug#801610: libogg-vorbis-decoder-perl: FTBFS: Failed test 'raw_total'
block 801610 by 802393 thanks Niko Tyni wrote: On Mon, Oct 12, 2015 at 04:52:37PM +0300, Niko Tyni wrote: # Failed test 'raw_total' # at t/basic.t line 20. # got: '4414398' # expected: '4418594' This test was broken by src:libvorbis (binary:libvorbisfile3 to be exact) upgrade from 1.3.4-2 to 1.3.4-3. I have no idea if it's an intended change or an accidental side effect. Copying the libvorbis maintainers, could you please comment on that? Your test case seems to be correct: The new libvorbisfile3 version returns an incorrect value. The problem was introduced by backported upstream fixes for #782831. Those fixes are also present (without modification) in the recent 1.3.5 upstream release (in the process of being packaged) and my testing indeed confirmed that 1.3.5 has the same problem. So the bug is not Debian-specific and the fix should therefore be coordinated with the upstream developers. I have filed a bug for this against libvorbisfile3 (#802393).
Bug#802393: libvorbisfile3: ov_raw_total() ignores the size of the last page
Package: libvorbisfile3 Version: 1.3.4-3 Severity: normal Tags: confirmed The maintainers of the package "libogg-vorbis-decoder-perl" discovered that the return value of "ov_raw_total()" with i==-1 changed after the upgrade from libvorbisfile3 1.3.4-2 to 1.3.4-3, which breaks their test case. See #801610 for further information. Indeed, their test case seems to be correct and the new libvorbisfile3 version returns an incorrect value. The problem was introduced by backported upstream fixes for #782831. Those fixes are also present (without modification) in the recent 1.3.5 upstream release and testing confirmed that 1.3.5 has the same problem. So the bug is not Debian-specific and the fix should therefore be coordinated with the upstream developers. My analysis showed that the returned value is the difference between the offset of the last page and the offset of the first page of the logical bitstream. However, in order to comply with the specification, it should be the difference between the first byte *after* the last page and the offset of the first page. So the returned value is missing the size of the last page. The problem can be fixed by simply changing the line if(_bisect_forward_serialno(vf,0,dataoffset,end,endgran,endserial, vf->serialnos+2,vf->serialnos[1],0)<0)return(OV_EREAD); in vorbisfile.c to if(_bisect_forward_serialno(vf,0,dataoffset,vf->end,endgran,endserial, vf->serialnos+2,vf->serialnos[1],0)<0)return(OV_EREAD); However, since I find the bisection code relatively confusing, I'm not entirely sure that this won't break anything else (especially for the case of having multiple links). So I am going to propose this fix to upstream and wait for feedback before submitting a patch to the Debian package.
Bug#772877: oggenc fails when using '--advanced-encode-option disable_coupling' switch and CBR encoding
reassign 772877 libvorbisenc2 retitle 772877 libvorbis: Segmentation fault when disabling channel coupling thanks Actually the oggenc code about setting the "disable_coupling" option seems to be fine, but the relevant libvorbis encoding code not so much. So I'm reassigning this to libvorbisenc2. The code can be reproduced without oggenc in a simple example by calling "vorbis_encode_ctl" with action "OV_ECTL_COUPLING_SET" and argument being a pointer to an int variable with value 0. I've found the following two problems with the encoding library. First of all, the segmentation fault seems to occur due to poor return code checking: / | new_template = get_setup_template(.); | if(!hi->setup)return OV_EIMPL; | hi->setup=new_template; | hi->base_setting=new_base; | vorbis_encode_setup_setting(vi,vi->channels,vi->rate); \ If "get_setup_template" returns NULL, which it is allowed to in general, and which it does in this specific scenario, then "hi->setup" will be NULL - which "vorbis_encode_setup_setting" cannot cope with. The NULL check should either come *after* assigning the new value to "hi->setup" (that's the way it is done in "vorbis_encode_setup_vbr" and "vorbis_encode_setup_managed"), or the NULL check should refer to "new_template". The second question is, why "get_setup_template" actually returns NULL. In this case, it should be able to find a matching setup template. The answer is in the following line at the beginning of "get_setup_template": / | if(q_or_bitrate)req/=ch; \ This line is supposed to divide the total desired bitrate up into bitrates for each channel. However, in the specific case of disabling the coupling, the parameter "ch" is set to -1. The desired effect of this is to accept only setups that don't couple channels, which is achieved. However, as a side effect this also screws up the mentioned bitrate division. The bitrate is then divided by "-1" and we end up with a negative desired bitrate, which can never be fulfilled. Fixing this requires a signature change of "get_setup_template", otherwise the real number of channels cannot be known in this case. Since the function "get_setup_template" doesn't appear in any header file at all, this signature change doesn't affect the ABI nor API and is therefore safe. I will provide a patch, when I find the time to do a thorough testing of the fix. Cheers, Martin
Bug#775983: oggenc: Invalid memory access with low sampling rate
tags 775983 + confirmed retitle 775983 oggenc: Invalid memory access with low sampling rate thanks The problem seems to be independent of oggenc's resampler. It can be observed with any input file having a low sampling rate, e.g.: dd if=/dev/zero bs=1024 count=1000 | valgrind oggenc -r -R 500 - > /dev/null The cut-off frequency seems to be 512 Hz. Everything >= 512 Hz works, everything < 512 Hz exposes the invalid memory access. To me it looks a little bit like libvorbis cannot encode audio with such a low sampling rate. But either it fails to refuse such inputs with a sanity check, or oggenc doesn't properly check the return codes. However, I've checked the oggenc encoder code and it seems to be pretty thorough about return code checking, both in generally and specifically regarding the calls to the functions "vorbis_encode_setup_managed" and "vorbis_encode_setup_managed", which is where the sampling rate is passed to libvorbis. Looks like this needs some proper debugging... Cheers, Martin
Bug#263762: /usr/bin/oggdec: oggdec manpage error: oggdec - doesn't write to stdout
tags 263762 + pending thanks Dear Reuben, I've fixed this by adjusting oggdec's behavior to the one specified in the man page (instead of adjusting the information in the man page). I think that's the behavior that most users would expect. A trivial code change did the trick. New behavior: / | mast@biene-maja$ cat hogans-heroes.ogg | oggdec - | wc -c | oggdec from vorbis-tools 1.4.0 | 4321342 | mast@biene-maja$ cat hogans-heroes.ogg | oggdec - -o - | wc -c | oggdec from vorbis-tools 1.4.0 | 4321342 | mast@biene-maja$ cat hogans-heroes.ogg | oggdec - -o hogans-heroes.wav && wc -c hogans-heroes.wav | oggdec from vorbis-tools 1.4.0 | 4321342 hogans-heroes.wav | mast@biene-maja$ rm hogans-heroes.wav | mast@biene-maja$ oggdec hogans-heroes.ogg && wc -c hogans-heroes.wav | oggdec from vorbis-tools 1.4.0 | Decoding "hogans-heroes.ogg" to "hogans-heroes.wav" | [100,0%] | 4321342 hogans-heroes.wav \ Cheers, Martin
Bug#694812: subtitlecomposer: Spellchecking aborts program when blank entry encountered
tags 694812 + pending thanks Apparently this is a general problem of Sonnet::Dialog, which cannot handle empty buffers. I was able to reproduce the crash outside of Subtitle Composer in an isolated example by passing an empty buffer to Sonnet::Dialog. Sonnet::Dialog's specification doesn't exclude empty buffers, so I consider this a bug in Sonnet. But even so, it might be good to work around this problem in Subtitle Composer, too. Even the KDE people themselves (the creators of Sonnet) apply that kind of workaround in their applications (e.g. in Kate [1] [2]). I've created a patch working around the problem by skipping empty entries (they don't have to be checked anyway). It's in the package's git repository, waiting to be uploaded.
Bug#797644: kdelibs5-dev: kopete FTBFS: No rule to make target '/usr/lib/libsoprano.so', needed by 'kopete/kopete'
Martin Steghöfer wrote: It's fine for "libkhtml.so" to request linking to libsoprano. But if it does so, IMHO its corresponding -dev package should make sure that the necessary dependencies are pulled in. Never mind, someone just re-added the missing dependency to kdelibs5-dev, just like I asked. See #799520. Cheers, Martin
Bug#797644: kdelibs5-dev: kopete FTBFS: No rule to make target '/usr/lib/libsoprano.so', needed by 'kopete/kopete'
Thank you for your comment, Scott! Let my clarify...
Scott Kitterman wrote:
If there's a warning not to link against it, isn't the solution not to do that?
Yes, of course it would be a solution *not* to link against it, but
"kdelibs5-dev" forces me to do so (that's why I blame it).
That's actually part of the point I was trying to make: My package (as
well as others that are FTBFS'ing in the same way) doesn't actually
*want* to link against libsoprano. It never asks for it. As I said
before: The library libsoprano "is never even mentioned in any of the
CMakeLists.txt files".
It is some CMake magic in kdelibs5-dev's macros that pulls it in. It is
enough to do the following:
/
| KDE4_ADD_EXECUTABLE( myMainApp mymainapp.cxx )
| TARGET_LINK_LIBRARIES( myMainApp ${KDE4_KHTML_LIBS} )
\
That makes "myMainApp" link against libsoprano.
It's fine for "libkhtml.so" to request linking to libsoprano. But if it
does so, IMHO its corresponding -dev package should make sure that the
necessary dependencies are pulled in.
Hope that clears things up a little...
Cheers,
Martin
Bug#797644: kdelibs5-dev: kopete FTBFS: No rule to make target '/usr/lib/libsoprano.so', needed by 'kopete/kopete'
Dear kdelibs5-dev maintainers, One package I worked on is affected by this problem, too. That's why I started investigating this issue and found out that there is a whole bunch of packages that are currently (or were recently) FTBFS'ing because of this problem. Some maintainers employed the workaround of adding a build dependency to "libsoprano-dev" because that's the only way they can fix the FTBFS themselves. But it sure feels like a hack, which is why I'd prefer not to have to do this. What's the reason for this odd behaviour? I couldn't really see this from this bug report, just that it had something to do with "the transition from nepomuk to the new baloo package". Is this going to be fixed properly at some point? I consider adding "libsoprano-dev" to the Build-Depends of all dependant packages just a temporary workaround. Could we keep this bug open as a reminder that this still needs a proper fix? To me it feels really wrong to add a build dependency to a library that is never even mentioned in any of the CMakeLists.txt files, nor is used directly by any of the code (there is even a warning telling me that I shouldn't have linked against it). Or is there any justification for seeing libsoprano-dev as a "real" build dependency of packages of that kind, and I'm just not seeing it? Or a way to get rid of the "dependency"? Cheers, Martin
Bug#775983: oggenc: low --resample rate -> double free or corruption
Petter Reinholdtsen wrote: [Jakub Wilk 2015-01-22] I tried to resample the input file to a very low rate, but oggenc crashed: This no longer happen with version 1.4.0-6 on my machine, at least. Now I get an error instead: No crash for me, either. But valgrind reports a whole bunch of invalid memory access problems. Depending on the memory layout, they probably lead to the crash. Cheers, Martin
Bug#799957: subtitlecomposer: Please upgrade to 0.5.7
Package: subtitlecomposer Version: 0.5.3-3 Severity: normal Dear Maintainer, Several bug fix releases of "subtitlecomposer" have been published since the last Debian package upgrade. The current version is 0.5.7, whereas the Debian package is still at 0.5.3. The release fixes several bugs that were also reported to this BTS here. Please upgrade to the most recent version 0.5.7. Please note that you probably haven't caught the most recent updates because your "watch file" is outdated. It still refers to the SourceForge project home [1], but development has been moved to Github [2]. Cheers, Martin Steghöfer [1] http://sourceforge.net/projects/subcomposer/ [2] https://github.com/maxrd2/subtitlecomposer/
Bug#798960: libvorbis: Please upgrade to 1.3.5
El 22-09-2015 a les 23:40, Petter Reinholdtsen ha escrit:
Did you include all the patches in Debian into the 1.3.5 release?
Knowing which to keep will make the update a bit easier for us. The
complete set is available from
https://sources.debian.net/src/libvorbis/1.3.4-3/debian/patches/ >.
Most patches are actually backports of upstream commits anyway. Of the
ones that aren't, those that were actually forwarded to Xiph.org are all
included in 1.3.5. That leaves us with only two patches ("Fix build
failure with DSO link changes." and "Avoid SIGFPE when bytespersample is
zero") that have never been forwarded to upstream (probably because they
were introduced by NMUs) and are therefore not included in 1.3.5. I can
take care of forwarding them now.
I've started packaging 1.3.5 in the git branch
"package-new-upstream-version".
Cheers,
Martin
Bug#777209: libkate1 is not Multi-Arch compatible
Petter Reinholdtsen wrote: E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/__init__.pyc E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/__init__.pyo E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/constants.pyc E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/constants.pyo E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/demuxer.pyc E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/demuxer.pyo E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/finder.pyc E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/finder.pyo E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/muxer.pyc E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/muxer.pyo E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/options.pyc E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/options.pyo E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/tester.pyc E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/tester.pyo E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/tools.pyc E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/tools.pyo E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/ui_editor.pyc E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/ui_editor.pyo E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/ui_main.pyc E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/ui_main.pyo E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/ui_options.pyc E: libkate-tools: package-installs-python-bytecode usr/lib/python2.7/dist-packages/kdj/ui_options.pyo E: libkate-tools: python-script-but-no-python-dep usr/bin/KateDJ I tried to look into this and couldn't reproduce those lintian errors. So I checked it out manually and can confirm: My binary package "libkate-tools" doesn't contain any .pyc or .pyo files, just the corresponding .py files are present, as desired. Maybe your build wasn't clean? Did you build the package using pbuilder (I did)? Cheers, Martin
Bug#606224: oggvideotools: oggJoin fails on powerpc
Petter Reinholdtsen wrote: [...] PATH=`pwd`/debian/oggvideotools/usr/bin:$PATH ./debian/tests/test-oggjoin + cd /tmp/tmp.25t0237HSw + echo info: Running autopkgtest script ./debian/tests/test-oggjoin info: Running autopkgtest script ./debian/tests/test-oggjoin + echo info: Generating Ogg Theora file info: Generating Ogg Theora file + oggSlideshow /usr/share/pixmaps/debian-logo.png creating video stream for picture 7.958333 + echo info: Copy Ogg Theora file using oggJoin. info: Copy Ogg Theora file using oggJoin. + oggJoin out.ogv slideshow.ogv + [ -e out.ogv ] + echo success: Ogg Theora file out.ogv created. success: Ogg Theora file out.ogv created. + echo info: test completed successfully info: test completed successfully + at_exit + set +x info: test exiting, removing /tmp/tmp.25t0237HSw Am I testing the wrong thing? Well, I'm sure there are endianness issues with your test case, too. But the particular error reported in the bug only shows when using a .ogg audio file. The whole "oggSlideshow" business isn't actually necessary to reproduce the problem. A simple > oggJoin out.ogv /usr/share/sounds/gnome/default/alerts/sonar.ogg will reproduce the behavior. We may, however, find an example file in the archive with less dependencies. The mentioned "sonar.ogg" file is in the package "gnome-control-center-data", which pulls in quite a lot of dependencies. Also, please note that the existence of "out.ogv" is no indicator for the presence of the problem. The file will be created in any case, albeit empty. But you can check the exit code of "oggJoin". It will indicate the problem by returning a non-zero exit code. Cheers, Martin
Bug#790442: FTBFS with new LaTeX: Unknown float option `H'.
tags 790442 + pending
thanks
Thanks for the fix, Ralph! I just backported it into the package.
Cheers,
Martin
Ralph Giles wrote:
On Mon, 29 Jun 2015 11:32:43 -0400 Martin Michlmayr wrote:
You're using the "H" float option. According to
https://en.wikibooks.org/wiki/LaTeX/Floats,_Figures_and_Captions
you need \usepackage{float} for that, but it seems simpler solution
is to replace it with "!h".
Thanks for the report. We fixed this upstream by adding the package;
we were using the [H] directive specifically in those two sections to
keep the packet layout at the top of the section for easy reference.
https://git.xiph.org/?p=theora.git;a=commitdiff;h=fbb275803696085225c310773474ef4dcf8a4528
With the current source text, [!h] seems to work well enough, but [H]
is more robust since we needed to be specific there at some point
during development.
-r
Bug#606224: oggvideotools: oggJoin fails on powerpc
I compiled the package from source in the mentioned QEMU-emulated big-endian MIPS machine, so I could debug it properly. This way I found the culprit for this specific error. However, only very little of the other file reading code seems to be ready for a big-endian environment. There seems to be a whole lot of refactoring necessary to make the package endianness independent. If at all, this has to be done by upstream. I think for the moment we should just stop building the package for big-endian architectures. What do you think?
Bug#606224: oggvideotools: oggJoin fails on powerpc
found 606224 0.8a-1 thanks Since there was no more feedback from the bug reporter, I tried to reproduce this on my own. I don't have access to a ppc machine, but managed to get a Debian Wheezy running in a QEMU-emulated big-endian MIPS machine, on which I could reproduce the problem with oggvideotools 0.8a-1. So far I haven't tried any other versions because I'd have to compile them from source, which can be a pain in the emulator. But judging from the diff between 0.8a-1 and the current version 0.8a-3, the problem is probably still present (if oggvideotools is the actual culprit, and not some underlying library). Cheers, Martin Petter Reinholdtsen wrote: [Daniel Kahn Gillmor] I haven't tested recently, and won't have access to a ppc machine for a few days. feel free to ping me later if i haven't made it back to test this, though. thanks for picking up this package! Did you manage to test if oggJoin still fail on powerpc? Perhaps you can send us a test script to run during build to discover the problem?
Bug#782831: libvorbis: use of non-initialized variable leads to SIGSEV in dhewm3
Tobias Frost wrote: I'm currently considering to NMU the workaround. I hope that I get around to integrating the 1.3.4 patch or packaging 1.3.5 this weekend. Otherwise, please NMU the workaround. It may not be too nice to just have a workaround, but I consider it safe. Best, Martin
Bug#782831: libvorbis: use of non-initialized variable leads to SIGSEV in dhewm3
El 12-06-2015 a les 15:06, Tobias Frost ha escrit: Did you report this issue already upstream? Could not find it on their BTS... Not necessary because upstream doesn't have the problem. Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#782831: libvorbis: use of non-initialized variable leads to SIGSEV in dhewm3 -- fixed in new upstream version
Hi Tobias! Thank you for the effort! I've already identified the problem. The upstream commit we imported in order to fix #762571 had some issues that were fixed later in the upstream repository (but never imported into the Debian package). I've identified the relevant commits and they seem to fix the problem in the Debian package, but I haven't gotten around to doing an exhaustive testing. Those fixes are, of course, contained in 1.3.5, but since packaging 1.3.5 may require a little more time, I may upload the patches for 1.3.4 anyway. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#784075: subtitlecomposer: Missing "Build-Conflicts" entry "qt5-qmake"
Package: subtitlecomposer Version: 0.5.3-4 Severity: minor Dear maintainers of subtitlecomposer, The package subtitlecomposer doesn't build from source if the package "qt5-qmake" is installed. If this package is installed, the subtitlecomposer's build system will use the Qt5 QMake instead of the Qt4 QMake, but subtitlecomposer/KDE is incompatible with Qt5. This can be fixed by either patching the build system to use the specific executable "qmake-qt4" instead of the generic executable "qmake" or by simply adding a "Build-Conflicts" entry for "qt5-qmake". Thank you for maintaining subtitlecomposer and in advance for fixing this problem! Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#782831: libvorbis: use of non-initialized variable leads to SIGSEV in dhewm3
Update: This is related to the beginning-of-stream special case for seeking and to the fact that there is only one "normal" ogg page in the file. The first time this special case is used, it seems to advance the page pointer to a place where the same special case cannot find any page during the second seek because the stream ends (that type of seeking works only forward). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#782831: libvorbis: use of non-initialized variable leads to SIGSEV in dhewm3
Dear Tobi,
Thank you for the bug report and your analysis of the problem.
The error handling is one thing. A library should be robust to failures
and not crash the whole product. The crashing doesn't happen on other
distros because for bug #762571 we backported an upstream change that
fixes an infinite loop when seeking to 0 and that new code is apparently
less robust to internal failures. Since the code comes from upstream,
their current SVN head has probably the same problem.
But on the other hand I don't think there is a reason for the internal
function _get_next_page to fail. I think the function ov_pcm_seek_page
is allowed to assume that under the given circumstances the call to
_get_next_page has to succeed. So mitigating the problem by making the
code more robust (as your patch does) would avoid the crash, but the
call to ov_pcm_seek_page would still fail without justification and the
playback would have to be aborted.
That's why I tried to find the underlying problem. Unfortunately, the
fact that the only known way to trigger the bug was via "dhewm3"
required me to build that application and even dig out a copy of Doom 3,
which is apparently required to run the test case. Finally I was able to
extract the data that triggered the crash and reproduce the crash in a
simple executable without "dhewm3". Further debugging revealed that the
problem can be triggered by doing two subsequent seeks to 0 on any very
short vorbis file (not only the one extracted from "dhewm3" / Doom 3) -
which is great because this way we have an example file that can be
posted here without copyright trouble.
For now that's as far as I got. But at least the bug is isolated now
(see attached files; compile vorbistest.c against libvorbis-dev and
execute it with the path to silence-short.ogg as first parameter). When
I have more time, I can do further debugging to find the root of the
problem.
Cheers,
Martin
El 18-04-2015 a les 14:31, Tobias Frost ha escrit:
Package: libvorbis-dev
Version: 1.3.4-2
Severity: normal
Dear Maintainer,
Please read for a background: https://github.com/dhewm/dhewm3/issues/104
Short: dhewm3 calls ov_pcm_seek_page(), where an object of ogg_page (og) is
created
on the heap, which seems should be initialized by the call to _get_next_page().
However the call to this function is not successful, returnin OV_EOF (-2) and
the result is that ogg_page is not initialized but still later used, even if
the code
recognized that bisection fails (bisec==-1). However, it still accesses it in
the call to ogg_page_serialno(&og) leading to a SEGV.
A special guard for this, first initializing og.header with NULL and checking
for it later
makes the SIGSE'm unsure if this fix is "sane". With that disclaimer, here's
the patch I used:
diff -Naur libvorbis-1.3.4/lib/vorbisfile.c libvorbis-1.3.4_/lib/vorbisfile.c
--- libvorbis-1.3.4/lib/vorbisfile.c2015-04-18 14:28:43.0 +0200
+++ libvorbis-1.3.4_/lib/vorbisfile.c 2015-04-18 14:04:34.262733024 +0200
@@ -1442,6 +1442,7 @@
ogg_int64_t best=-1;
ogg_page og;
+og.header = 0;
/* bisection loop */
while(begin
+ if (!og.header) {
+ result = -1;
+ goto seek_error;
+ }
+
if(begin == vf->dataoffsets[link] &&
ogg_page_serialno(&og)==vf->serialnos[link]){
Please let me know how I can help...
--
tobi
-- System Information:
Debian Release: 8.0
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libvorbis-dev depends on:
ii libogg-dev 1.3.2-1
ii libvorbis0a 1.3.4-2
ii libvorbisenc2 1.3.4-2
ii libvorbisfile3 1.3.4-2
libvorbis-dev recommends no packages.
libvorbis-dev suggests no packages.
-- no debconf information
#include
#include
#include "vorbis/codec.h"
#include "vorbisfile.h"
int main(int argc, char **argv){
OggVorbis_File vf;
FILE *input = fopen(argv[1], "rb");
if(ov_open(input, &vf, NULL, 0) < 0) {
fprintf(stderr,"Input does not appear to be an Ogg bitstream.\n");
exit(1);
}
if(ov_pcm_seek( &vf, 0 ) < 0) {
fprintf(stderr,"First seek failed.\n");
exit(1);
}
if(ov_pcm_seek( &vf, 0 ) < 0) {
fprintf(stderr,"Second seek failed.\n");
exit(1);
}
ov_clear(&vf);
return(0);
}
silence-short.ogg
Description: video/ogg
Bug#776086: vorbis-tools: CVE-2014-9638 CVE-2014-9639 CVE-2014-9640
Moritz Muehlenhoff wrote: Did you contact upstream, are fixes available for these? There are bug tracker items available for the two remaining issues [1] [2], but there has been no movement so far. I've looked into it and the security aspect is fairly easy to fix by just adding an additional sanity check that allows only positive numbers of channels (rule out 0 to avoid CVE-2014-9638 and negative values to avoid CVE-2014-9639). For the case CVE-2014-9638, I even consider this the proper and complete fix. In CVE-2014-9639, however, the deeper reason for the appearance of a negative number of channels is an overflow because of several unsuitable data types used in the reading of the wav headers. The proper fix would be to change those data types - which has to be done with great care, in order to avoid shifting the overflow from its current place to a place that might be even less guarded. I haven't gotten around to reviewing the code and fixing this. But maybe for now we can just stick with the sanity check? It fixes the security aspect and doesn't break any case that wasn't broken already - it however doesn't fix the problem that oggenc refuses to process some theoretically valid (although very uncommon, if existent at all) WAV files with very extreme parameters. Cheers, Martin [1] https://trac.xiph.org/ticket/2137 [2] https://trac.xiph.org/ticket/2136 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776326: subtitlecomposer breaks MIME type detection of some PNGs
Package: subtitlecomposer Version: 0.5.3-4 Severity: normal Dear maintainers of subtitlecomposer, the installation of the package subtitlecomposer breaks the MIME type detection of certain PNGs. Before installation of subtitlecomposer: | mast:~$ gvfs-info headset.png | grep content-type | standard::content-type: image/png | standard::fast-content-type: image/png After installation of subtitlecomposer: | mast:~$ gvfs-info headset.png | grep content-type | standard::content-type: text/x-tmplayer | standard::fast-content-type: image/png Note that the PNG file content type is now detected as "text/x-tmplayer" (before: "image/png"). The required file "headset.png" is attached to this message. This affects other programs, e.g. it breaks the Ambiance theme window decoration in a bug reported to Ubuntu [1] or it crashes the PulseAudio volume control without error message in my case (the Gtk call to load the icon throws an unhandled exception - and I'd guess that the problem can also affect other Gtk-based programs in the same way). The problem can be fixed temporarily by lowering the priority of text/x-tmplayer and text/x-tmplayer+ from 100 to 40 in /usr/share/mime/packages/subtitlecomposer.xml and updating the database by executing "update-mime-database /usr/share/mime". A permanent fix is available upstream [2] (see also the upstream bug report [3]). Thank you for maintaining subtitlecomposer and in advance for fixing this problem! Cheers, Martin [1] https://bugs.launchpad.net/ubuntu/+source/subtitlecomposer/+bug/993275 [2] https://github.com/maxrd2/subtitlecomposer/commit/6528219ade1f2ca2d78b85a236397aa0d62583ee.patch [3] https://github.com/maxrd2/subtitlecomposer/issues/1
Bug#776086: vorbis-tools: CVE-2014-9638 CVE-2014-9639 CVE-2014-9640
retitle 776086 CVE-2014-9638 CVE-2014-9639 thanks Dear Salvatore, thank you for reporting this! Salvatore Bonaccorso wrote: CVE-2014-9638[0]: Oggenc division by zero issue Confirmed with 1.4.0-6 as well as with the current git head. There doesn't seem to be a fix yet, so I am going to look into it. CVE-2014-9639[1]: Oggenc channel integer overflow Confirmed with 1.4.0-6 as well as with the current git head. There doesn't seem to be a fix yet, so I am going to look into it. CVE-2014-9640[2]: segfault when trying to encode trivial raw input This one is a duplicate of Debian bug #771363, which we fixed in December in version 1.4.0-6 (which made it into Jessie). No idea why the Debian security tracker lists 1.4.0-6 as vulnerable. This should be changed, but I don't know how. Since it's classified as a security issue now, we should probably backport the fix to stable, shouldn't we? If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. Will do, at least for the remaining 2 issues. For CVE-2014-9640 there was no CVE identifier when we fixed it. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774516: vorbis-tools: null pointer dereference
Jakub Wilk wrote: AFL comes with comprehensive documentation, but if you had trouble setting it up, please let me know. :-) No real trouble, but some questions I'd like to ask you (seeing that you seem to have more experience with the tool). But that is better done off-list, this bug report isn't the proper place. BTW, AFL also runs into SIGFPE (probably #772978). I'm also seeing those with my own executions of AFL. I'm gonna check, if it's the same issue that has already been reported. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728062: vorbis-tools: mailcap of ogginfo
tags 728062 + pending thanks Martin Steghöfer wrote: So for now I've uploaded the change only to the separate branch "mime" in our git repository. If nobody raises any concerns, I will integrate this into the "master" branch, so it can be uploaded to the archive eventually. No concerns raised after nearly one month, so I'm merging this into the package's master branch, upload pending. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774516: vorbis-tools: null pointer dereference
Forgot to CC the bug report itself. Here comes the message: Martin Steghöfer wrote: reassign 774516 libvorbisfile3 tags 774516 confirmed thanks Hi Jakub, Thank you for the bug report! Jakub Wilk wrote: Both oggdec and ogg123 crash on the attached file, trying to dereference null pointer: [...] Confirmed, I can reproduce this. #0 0xf7f925a8 in vorbis_packet_blocksize (vi=0x804d2f0, op=0x910c) at synthesis.c:168 #1 0xf7fb6b4d in _initial_pcmoffset (vf=0x92cc, vi=0x804d2f0) at vorbisfile.c:440 #2 0xf7fb8ec0 in _open_seekable2 (vf=0x92cc) at vorbisfile.c:625 #3 0xf7fb9117 in _ov_open2 (vf=0x92cc) at vorbisfile.c:941 #4 ov_open_callbacks (f=0x804d020, vf=0x92cc, initial=0x0, ibytes=0, callbacks=...) at vorbisfile.c:997 #5 0x0804977a in decode_file (in=0x804d020, out=0x9098, out@entry=0x804d188, infile=0xd88d "crash.ogg", outfile=0x804d008 "crash.wav") at oggdec.c:265 #6 0x08048d5f in main (argc=2, argv=0xd6b4) at oggdec.c:455 Judging from this stacktrace and from the fact that your file crashes audacity, too, I'd say we're dealing with a problem in the decoder library. Reassigning to package libvorbis. I am going to look into this and/or forward it to upstream. This bug was found using American fuzzy lop: https://packages.debian.org/experimental/afl Huh! Didn't know about this tool (although I've heard about the general concept of fuzzing to discover bugs). I will have to give it a spin... Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578720: vorbis-tools: Sends invalid argument to ALSA when playing some files
Hi Ron! I agree that implementing some "magic" to find out the real reason isn't a very good idea. I think the main point where we still disagree is how "magic" (according to you) or "specified" (according to me) the meaning of EINVAL really is in this situation. Ron write: The problem is, that even if this is the case with the current alsa code, we have no guarantee it would always remain true. And it may in turn pass back error codes from the kernel, which could include this one too. Technically it *can* do a lot of things, but it isn't allowed to. Passing on an "EINVAL" error code from somewhere internal is something I would consider a bug. If a callee returns an "invalid arguments" code to the caller, that information has to refer to the actual call at hand, instead of some call somewhere under the hood. In the latter case a return value "EINVAL" would be very misleading. (I admit, however, that some programmers might feel tempted to just pass on error codes unchecked, especially because in C you cannot have container exceptions wrapped around the original exception like in OO languages.) If a function "set number of channels" reports an invalid argument, to me the only correct interpretation of this is that the number of channels that I've asked for isn't allowed. And no, the ALSA documentation itself doesn't say that explicitly. But other (more general) references for EINVAL do so. And I consider that common sense. But I can understand that to you don't want to trust too much in other programmers' care for reasonable error codes and rather stick with whatever error string they hand you. (Although I'm afraid that with that level of trust you probably have very little to base on in general, seeing how few things are actually specified in an exact and/or formal way - unfortunately!). (which is why I didn't bother looking at the alsa-lib code to see if there was a way we could do something 'clever' here. Its next release could look nothing like the code in the current one in its internals, even if it's otherwise API/ABI compatible) You are right that whatever is under the hood should be irrelevant to us. I shouldn't have mentioned that I looked at the implementation. That was more of a side note than an argument. I'm just discussing the meaning of the API (even though I know what is under the hood). And there's still a long list of things other than number of channels which this could fail on in much the same way (sample rate, sample format, sample size, etc.) They could fail with the same error code, but not in the same function call. If the callee tells us that the argument was invalid, that should (and does in this case) refer to the actual argument at hand. I think anything which wants to verify those things in a user friendly manner really needs to check them for validity specifically itself, rather than just throwing them at libao to see if they'll stick, and hoping it will explain why not in a way suitable for them. That's a different path to solve the same issue. I didn't know that the libao API allowed us to do so. In any case, this would probably be an excessive effort for this issue. But in general, independently from the quality of ALSA/libao's error message, implementing this would be a good thing. Can you point me in the right direction? At first sight I haven't found a libao function to check that. Or were you thinking about checking device capabilities using ALSA directly? That would somehow foil the point of using libao as intermediary in the first place. In the current libao code, I don't think this will even output a message at all unless you've turned the verbosity up (which is different to the code that this was originally seen on). I'm going to check that suspicion. If it is correct, that would render our hole discussion pointless. :-( And then there's the risk of breaking other software by changing the error code, like you said. :-( Right, including breaking libao if we were to do the trick you proposed above :) No, our check for the EINVAL return code would just never become "true" and therefore we would be back to using the strings handed to us by "snd_strerror". Our "trick" (as you call it) wouldn't be outside the specification. But the ALSA return code change could break applications that consider EINVAL the *only* valid error code in the case (which they shouldn't). Well, the ones who don't read documentation (or source :) are probably still going to think/report that ogg123 is broken even if it tells them "Sorry I can't play 1 channel audio on your system!", so I'm not sure we can really ever win that game. Unfortunately that's true... ;-( We should wrap this up before we get lost in a too general discussion: While I still think that "mode not supported by ALSA device" is the only valid conclusion that can be drawn from receiving an "invalid parameter" error on that concrete function
Bug#578720: vorbis-tools: Sends invalid argument to ALSA when playing some files
Hi Ron!
Ron wrote:
No, that's fine. Most of that was just me "thinking out loud" as I traced
through the relevant code. That we agree on that just means we came to the
same conclusion. I didn't mean to suggest you thought otherwise, I was
just fleshing out the reasons I thought that was the right call to make.
Ah, OK, that's good :-)
And all we really know is that call into alsa-lib failed. We don't
really know anything more about *why* it failed than the error code
it returns. If all it returns is "Invalid argument", that's all we
have to go on.
True, but that may be all we need, if we interpret it in the context.
The wording is bad because ALSA tries to use generic error codes
wherever possible, in this case the EINVAL ("Invalid argument") error
code from the linux system errors. It also delegates the
int-to-string-translation to the linux system errors function "strerror"
- which, of course, cannot know the ALSA context.
Is there any other reason for this function to fail with EINVAL other
than the device not supporting the mode we've asked for? Which other
"invalid argument" could there be? The other arguments we pass to the
function have to be OK at that point.
A very quick look at the ALSA code seems to confirm that EINVAL is
returned if and only if after ruling out all configurations that don't
comply with the number of channels we've asked for, the remaining set of
configurations would be empty.
To me, that seems to be enough to interpret EINVAL in *this* *concrete*
place as "device doesn't support the output mode we've asked for".
We can't know that was because the hardware didn't support the
requested number of channels (if alsa doesn't explicitly say that)
it could be for any number of reasons.
It could fail for a number of other reasons, but in those other cases it
wouldn't report EINVAL, would it?
Right, but "Set hardware channels failed" doesn't explain it much
differently.
The string you suggested would certainly more readable. But that part
isn't the main point, I think the other part is more important:
And "invalid parameters" is all alsa told us.
Yes, but this part may be interpreted in the context to provide a more
detailed error message (see my explanation above).
I'm not specifically objecting to improving that, but to do so
it would have to be in alsa-lib, not libao. And then there'd
be some risk of breaking something else using alsa if it makes
assumptions about the error codes that might be returned.
[...]
You might be able to do something more in ALSA, but whether that's
a good idea, and whether its maintainers would be keen to do it
is a question you'd have to run past them.
If we can't work anything out for libao, then that's the next (and last)
thing I would try. But I see more chances for this to happen in libao.
If ALSA sticks to generic Linux system error codes almost everywhere,
then they probably won't abandon that principle for this little issue.
And then there's the risk of breaking other software by changing the
error code, like you said. :-(
(or close it with a patch sent upstream to note this in the
ogg123 docs, which might be useful regardless of what the ALSA folk do).
That would at least keep the users from thinking that "ogg123" or
"libao" is broken - at least those that read documentation ;-)
Thanks again for you collaboration!
Cheers,
Martin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578720: vorbis-tools: Sends invalid argument to ALSA when playing some files
Hi Ron!
Thank you for your quick and comprehensive answer! :-)
Unfortunately, I think I should have pasted more information into my
previous mail. Most of your answer tries to argue away a point that I
actually already ruled out in a message I posted earlier to this bug
report: It looks like we both agree that doing the upmixing is out of
the scope of both ogg123 and libao. I didn't suggest to do that. I
thought the snippet I pasted into my message to you made that clear. But
apparently it didn't, I'm sorry for not having made that more clear and
therefore having wasted your time. I have a very compact way of writing
things, but I try to be more verbose this time.
After upmixing is ruled out, the only thing left is to (maybe) improve
the error message, if that's possible.
In ogg123 we don't have the information that would be necessary in order
to tell what's going on. The only thing ogg123 knows is that for some
reason the ALSA output couldn't be opened. And that's what ogg123
reports to the user ("Error: Cannot open device alsa."). I don't see any
way to improve this.
So, if anything, we can only improve the *other* message. And that one
"comes" from ALSA (the error code and its translation into a string) and
is "emitted" (converted to string, composed and printed) by libao, like
I tried to explain in my previous message:
The string "invalid argument" comes from ALSA ("snd_strerror")
and it's printed by libao (in "ao_plugin_open"). So either of
them could improve the wording.
Since you were doubting this...
The second to last line appears to have come from alsa-lib itself,
I don't see anything in libao that would emit that.
...let me be more specific: The line in which libao emits this is
located in ao_alsa09.c:391 in version 0.8.8 (which is the one the bug
reporter used). In the most recent version (1.1.0) a similar output
would be emitted by ao_alsa.c:521.
It [the error message] might be a little counter-intuitive
until you realise some hardware simply can't handle mono output
Exactly, *that* is the (only) point where I see potential for
improvement. The function name "snd_pcm_hw_params_set_channels" probably
doesn't mean much to the user. And "invalid parameters" sounds more like
an internal software problem (one of those illegal function parameters
that you try to detect with assertions) than like a lack of hardware
features.
but it's not clear to me that anything
above the level of alsa-lib can really
second-guess (or report) why it
failed in any more detailed way.
Not clear to me, either. That's why I'm coming to you because you know
libao better. An idea from my side: libao *can* know what's going on by
combining the following information: The fact that the error happened,
when setting the output device parameters, and the return code (an
integer value that means "invalid parameters"). The information in
"internal->cmd" could even tell *which* parameter couldn't be set (in
this case the number of channels).
I'm not saying that anything *has* to be done, neither am I saying that
libao is the right place to do say. I'm just saying that *if* we want to
do anything to improve this, the only places that occur to me for doing
this in a reasonable way are libao or ALSA. That's why I came to you, to
hear your opinion, if you think this should be done in libao, in ALSA or
not at all.
So sorry, I don't really see an easy out that just lets you punt this
one to someone else :)
I wasn't trying to. This is not about *who* does things (I'd be glad to
contribute, be the "issue" in vorbis-tools or in libao; reassigning
doesn't mean that I'm out), but *where* things are done. Since it was
clear to me that the issue couldn't be helped in vorbis-tools, instead
of just closing the issue I tried a final shot: Searching an external
place, where the issue might be mitigated. And I still see a slight
chance for this to happen in libao.
Thank you for your help! :-)
Cheers,
Martin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578720: vorbis-tools: Sends invalid argument to ALSA when playing some files
severity 578720 minor
thanks
Martin Steghöfer wrote:
The error message here is a bit cryptic. What it tries to say is: Your
output device doesn't support Mono playback and no software in the
output pipeline [...] is willing to do the necessary upmixing [...]
Doing the upmixing in ogg123 is certainly out of its scope and libao
also seems too simple. [...]
Hmmm, however, what could be done about this issue is to improve the
error message, so it tells the user that the mode isn't supported by the
user's hardware, instead of talking about an "invalid argument".
Unfortunately, this message isn't produced by ogg123. The string
"invalid argument" comes from ALSA ("snd_strerror") and it's printed by
libao (in "ao_plugin_open"). So either of them could improve the wording.
What do the libao maintainers (Ron and John in CC) think about this?
Should I reassign this to the libao package?
Cheers,
Martin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772981: libvorbis: Suspicion of SIGFPE with corrupt input file
Package: libvorbis Version: 1.3.4-2 Severity: normal While investigating the cause for #772978, the relevant libvorbis code gave me the impression that (with input files different from the referenced one) the division by zero may happen even if oggdec handled the reported errors correctly. The relevant stacktrace: Process terminating with default action of signal 8 (SIGFPE) Integer divide by zero at address 0x802FA8133 at 0x50632A6: res2_inverse (res0.c:830) by 0x50654A8: mapping0_inverse (mapping0.c:756) by 0x5054071: vorbis_synthesis (synthesis.c:88) by 0x4E3AC66: _fetch_and_process_packet (vorbisfile.c:707) by 0x4E3E073: ov_read_filter (vorbisfile.c:1971) by 0x4E3E6D2: ov_read (vorbisfile.c:2092) by 0x40212A: decode_file (oggdec.c:304) by 0x402692: main (oggdec.c:455) I am going to look for other ways (not exploiting oggdec's poor error handling) to trigger this division by zero and report it back here. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772978: vorbis-tools: oggdec crashes with SIGFPE (was: "oggdec goes into an infinite loop while processing file")
Package: vorbis-tools Version: 1.4.0-6 Severity: normal File: /usr/bin/oggdec Tags: confirmed I'm forwarding this bug report from Ubuntu bug 629135 [1]. Original description: / | Binary package hint: vorbis-tools | | oggdec goes into an infinite loop while processing the | file at http://bazaar.launchpad.net/%7Eubuntu-bugcontrol/ | qa-regression-testing/master/annotate/head%3A/scripts/ | libvorbis/011.ogg: | | $ oggdec libvorbis/011.ogg -o /tmp/011.ogg-converted.wav | oggdec from vorbis-tools 1.2.0 | Decoding "libvorbis/011.ogg" to "/tmp/011.ogg-converted | .wav" | Warning: hole in data (-137) | Warning: hole in data (-137) | Warning: hole in data (-137) | [] | | The test file in question was generated as part of | http://redpig.dataspill.org/2008/05/multiple- | vulnerabilities-in-ogg-tremor.html | | ProblemType: Bug | DistroRelease: Ubuntu 10.10 | Package: vorbis-tools 1.2.0-6build1 | ProcVersionSignature: Ubuntu 2.6.35-19.26-generic 2.6.35.3 | Uname: Linux 2.6.35-19-generic x86_64 | Architecture: amd64 | Date: Thu Sep 2 15:11:57 2010 | InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - | Alpha amd64 (20100827) | ProcEnviron: | LANG=en_US.UTF-8 | SHELL=/bin/bash | SourcePackage: vorbis-tools \ I couldn't confirm the infinite loop with vorbis-tools/1.4.0-6 and libvorbis/1.3.4-2, but received a SIGFPE with the following stacktrace: Process terminating with default action of signal 8 (SIGFPE) Integer divide by zero at address 0x802FA8133 at 0x50632A6: res2_inverse (res0.c:830) by 0x50654A8: mapping0_inverse (mapping0.c:756) by 0x5054071: vorbis_synthesis (synthesis.c:88) by 0x4E3AC66: _fetch_and_process_packet (vorbisfile.c:707) by 0x4E3E073: ov_read_filter (vorbisfile.c:1971) by 0x4E3E6D2: ov_read (vorbisfile.c:2092) by 0x40212A: decode_file (oggdec.c:304) by 0x402692: main (oggdec.c:455) The referenced input file is corrupted and it's therefore fine for oggdec to refuse decoding it. It should, however, do that by aborting gracefully with an error message. The SIGFPE smells like undefined behavior, especially considering that the original bug submitter reported an infinite loop - whose disappearance in the most recent versions might be a coincidence. As far as I can see, the main culprit in the case of this concrete file is in the oggdec executable, which keeps on decoding after libvorbis reports a stream error. This is mainly due to oggdec not distinguishing between harmless "holes" in the stream (after which you can keep on decoding) and fatal stream corruptions (that should trigger abort). I am going to provide a patch for this. Nevertheless, the libvorbis code gives me the impression that the division by zero may happen (in other cases) even if oggdec handled the reported errors correctly. However, so far I haven't been able to produce an ogg vorbis file that triggers this problem. I will file a separate bug for this and look into it. Cheers, Martin [1] https://bugs.launchpad.net/ubuntu/+source/vorbis-tools/+bug/629135 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772976: oggdec internationalization is broken
Package: vorbis-tools Version: 1.4.0-6 Severity: minor File: /usr/bin/oggdec While trying to fix a different bug, I've discovered that the "oggdec" executable uses the "_" (underscore) macro for internationalization and has translations of the relevant strings available in the .po files, but nevertheless outputs everything in English. This is probably due to a lack of initialization of the internationalization modules in that executable. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772877: oggenc fails when using '--advanced-encode-option disable_coupling' switch and CBR encoding
Package: vorbis-tools Version: 1.4.0-6 Severity: normal File: /usr/bin/oggenc Tags: confirmed I'm forwarding this bug report from Ubuntu bug 948459 [1]. Original description: | Running the following command line in a shell (with in.wav | being a commong 16bit 44,1KHz wave file): | | oggenc -b 80 -m 80 -M 80 --advanced-encode-option \ | disable_coupling -o out.ogg in.wav | | I get the following output: | | Mise en route du mécanisme de gestion du débit | Ouverture avec le module wav : WAV file reader | Encodage de "stereo.wav" | en "out.ogg" | en utilisant la gestion du débit (min 80 kbps, max 80 kbps) | Setting advanced encoder option "disable_coupling" | Erreur de segmentation | | Without the '--advanced-encode-option disable_coupling' | switch, encoding works as usual. | | More about my setup: | Ubuntu 10.10 amd64 (all packages up to date) | vorbis-tools 1.4.0 | | More information available on demand, this is the | first time I file a bug here. I could confirm this on 1.4.0-6 and get the following stacktrace: ==16296== Invalid read of size 8 ==16296==at 0x4E4AD38: ??? (in /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8) ==16296==by 0x4E4CBCC: vorbis_encode_ctl (in /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8) ==16296==by 0x408A2C: set_advanced_encoder_options (encode.c:102) ==16296==by 0x4093E5: oe_encode (encode.c:348) ==16296==by 0x403F4C: main (oggenc.c:440) ==16296== Address 0xf0 is not stack'd, malloc'd or (recently) free'd Cheers, Martin [1] https://bugs.launchpad.net/ubuntu/+source/vorbis-tools/+bug/948459 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772766: vorbis-tools: ogg123 shows error message and aborts playback of speex files
Package: vorbis-tools Version: 1.4.0-6 Severity: normal File: /usr/bin/ogg123 Tags: pending While working on the fix for #312185, related to acoustic problems with playing stereo speex files in ogg123, I discovered additional unrelated issues with ogg123's ability to play speex files: The cryptic error message '" in channel matrix ""' is shown and sometimes the output aborts. Both symptoms are caused by the channel matrix data structure not being initialized properly by the speex decoder module. I've uploaded a fix for this issue to git. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#312185: vorbis-tools: ogg123 plays speex files wrong: clicks, then silence.
Martin Steghöfer wrote: However, the issue happens even after transcoding the speex file to ogg vorbis (using audacity). This assessment was based and on a file mix-up in my testing process and is wrong. The issue is speex-specific. The problem occurs with speex files that declare 2 channels in the header, but don't provide any in-band stereo signal before the first sample. As far as I can see, the speex standard allows this, it is never even mentioned that any in-band stereo signal has to be sent at all. So ogg123 should be able to handle this case. However, the initialization of the stereo information data structure in ogg123 doesn't happen until the first in-band stereo signal is received. For all samples before the first stereo signal, the stereo information data structure is used in an uninitialized state and therefore produces distortions/noise/silence. The patch in git commit fb82b1de29 fixes the problem by using the proper libspeex functions for handling the life cycle of the stereo information data structure. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#263762: /usr/bin/oggdec: oggdec manpage error: oggdec - doesn't write to stdout
Thanks for reporting this issue! I think it's the "oggdec" executable that needs fixing rather than the documentation. Writing to "-.wav" is probably a quite undesired behavior for most users. Will look into it... Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772137: unblock: vorbis-tools/1.4.0-6 (fixing crash and faulty parameter parsing)
Ivo De Decker wrote: Unblocked. Thanks! :-) Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#239073: /usr/bin/ogg123: ogg123 status filling the console
tags 239073 + pending thanks Thanks for reporting the bug! A patch has been committed to our git repository and an updated version of the package will soon be uploaded to the Debian archives. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728062: vorbis-tools: mailcap of ogginfo
Hi Kevin! Thank you for the contribution! It sounds like a good idea to me. I've given your patch a try and, for what I can see, it works great. It seems to implement the "cat" action properly, while not disturbing the "view" action (thanks to the low priority). However, as I don't know much about MIME-type support, there may be flaws that I don't see. So for now I've uploaded the change only to the separate branch "mime" in our git repository. If nobody raises any concerns, I will integrate this into the "master" branch, so it can be uploaded to the archive eventually. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739099: vorbis-tools: ogg123 manpage inadequately documents -d option
Hi Paul!
Martin Steghöfer wrote:
[documentation examples skipped]
I'm not sure what else you'd expect here. Especially your doubt about
the format of the name-value pairs seems to be explained in the very
first paragraph of the man page ("-o option:value"). Is the
information not structured enough? Not visible enough? Ambiguous?
As I couldn't really confirm the lack of documentation that you reported
(see previous message [1]), it would be great, if you could provide us
with a little more details about how specifically we could improve the
documentation. Otherwise I'm afraid we cannot do anything about it and
have to close the bug report without changes to the package.
Cheers,
Martin
[1] https://bugs.debian.org/739099#10
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772137: unblock: vorbis-tools/1.4.0-6 (fixing crash and faulty parameter parsing)
tags 772137 - moreinfo thanks Ivo De Decker wrote: If the package is uploaded before Monday Dec 8th, it can still be unblocked. Otherwise, it's too late for jessie. Remove the moreinfo tag once it's in unstable. Thank you for your efforts! The package just got uploaded and will shortly appear in "unstable". Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763338: Bug#771363: Get #763338 and #771363 into Jessie
Forwarded message Subject: Re: Bug#772137: unblock: vorbis-tools/1.4.0-6 (fixing crash and faulty parameter parsing) Date: Sat, 6 Dec 2014 18:16:34 +0100 From: Ivo De Decker To: Martin Steghöfer , 772...@bugs.debian.org Control: tags -1 confirmed Hi, On Sat, Dec 06, 2014 at 06:09:30PM +0100, Martin Steghöfer wrote: Ivo De Decker wrote: >This package is not in unstable, so it can't be unblocked. Thanks for the reply! The changes are in our git repository, but I don't have upload permissions and the only member of our team who does hasn't gotten around to uploading it yet. So I tried to get the changes approved before the 5th December deadline. Can it be preapproved? If the package is uploaded before Monday Dec 8th, it can still be unblocked. Otherwise, it's too late for jessie. Remove the moreinfo tag once it's in unstable. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772137: unblock: vorbis-tools/1.4.0-6 (fixing crash and faulty parameter parsing)
Ivo De Decker wrote: This package is not in unstable, so it can't be unblocked. Thanks for the reply! The changes are in our git repository, but I don't have upload permissions and the only member of our team who does hasn't gotten around to uploading it yet. So I tried to get the changes approved before the 5th December deadline. Can it be preapproved? Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772391: vorbis-tools: bashism in /bin/sh script
tags 772391 confirmed pending thanks Thank you for reporting this! I've fixed this in git commit af56389cda. The current severity "minor" seems appropriate, given that the affected line is never actually executed in a properly installed system, and that even if it is executed using "dash" instead of "bash", the return value is still recognized correctly as "false". So this won't go into Jessie. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763338: Get #763338 and #771363 into Jessie
Petter Reinholdtsen wrote: Did you ask for pre-approval? No, I was hoping we would have something uploaded before I asked for unblock. Finally I sent in a debdiff this morning [1]. Let's see if someone attends to it in time. Cheers, Martin [1] https://bugs.debian.org/772137 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#772137: unblock: vorbis-tools/1.4.0-6 (fixing crash and faulty parameter parsing)
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Please unblock package vorbis-tools. The version 1.4.0-6, about to be
uploaded to unstable, fixes the following two bugs, both having severity
"important":
* #771363 is about a crash on closing input files of type "raw".
Although the crash happened only after correctly encoding the file, it
can severely affect the tool's usability regarding encoding of multiple
files. The bug was fixed by backporting a commit from the upstream SVN
repository.
* #763338 is about faulty processing of input parameters in the script
"vorbistagedit", which makes it impossible to use the script with
filenames containing spaces.
The changlog entry for 1.4.0-6:
[ Martin Steghöfer ]
* Fix oggenc crash on closing raw input files by backporting r19117
from upstream
(Closes: #771363)
* Fix vorbistagedit: Correctly process input files containing spaces
(Closes: #763338)
Please find attached a debdiff between the version in testing (1.4.0-5)
and the version about to be uploaded (1.4.0-6).
Thanks!
Martin
unblock vorbis-tools/1.4.0-6
-- System Information:
Debian Release: 7.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru vorbis-tools-1.4.0/debian/changelog
vorbis-tools-1.4.0/debian/changelog
--- vorbis-tools-1.4.0/debian/changelog 2014-11-11 21:49:04.0 +0100
+++ vorbis-tools-1.4.0/debian/changelog 2014-12-05 13:16:04.0 +0100
@@ -1,3 +1,13 @@
+vorbis-tools (1.4.0-6) UNRELEASED; urgency=medium
+
+ [ Martin Steghöfer ]
+ * Fix oggenc crash on closing raw input files by backporting r19117 from
upstream
+(Closes: #771363)
+ * Fix vorbistagedit: Correctly process input files containing spaces
+(Closes: #763338)
+
+ -- Martin Steghöfer Fri, 05 Dec 2014 13:14:24 +0100
+
vorbis-tools (1.4.0-5) unstable; urgency=low
[ Martin Steghöfer ]
diff -Nru vorbis-tools-1.4.0/debian/extra/vorbistagedit
vorbis-tools-1.4.0/debian/extra/vorbistagedit
--- vorbis-tools-1.4.0/debian/extra/vorbistagedit 2014-11-11
21:49:04.0 +0100
+++ vorbis-tools-1.4.0/debian/extra/vorbistagedit 2014-12-05
13:16:04.0 +0100
@@ -32,7 +32,13 @@
exit 1
fi
-for opt in $(getopt -n $ME -l version,help -o Vh? -- "$@"); do
+# process and reorder arguments using "getopt"
+eval set -- $(getopt -s sh -n $ME -l version,help -o Vh? -- "$@")
+
+# process the options (not the filenames yet) and remove them from the
argument array
+while [ $# -gt 0 ]
+do
+ opt="$1"
case $opt in
--version|-V)
versioninfo
@@ -40,13 +46,23 @@
--help|-h|-\?)
usage
exit 0;;
---) :;;
--*)
+--)
+ # found "--", which separates options and filenames in "getopt" output;
+ # so we are done parsing the options
+
+ # remove the "--"
+ shift
+
+ # now there are only filenames in the argument array => stop processing
+ break;;
+*)
echo "E: $ME: invalid argument: $opt" >&2
usage
exit 1;;
-*) :;;
esac
+
+ # remove the processed option from the argument array
+ shift
done
if ! command -v vorbiscomment >/dev/null; then
diff -Nru
vorbis-tools-1.4.0/debian/patches/0009-Fix-oggenc-crash-on-closing-raw-input-files.patch
vorbis-tools-1.4.0/debian/patches/0009-Fix-oggenc-crash-on-closing-raw-input-files.patch
---
vorbis-tools-1.4.0/debian/patches/0009-Fix-oggenc-crash-on-closing-raw-input-files.patch
1970-01-01 01:00:00.0 +0100
+++
vorbis-tools-1.4.0/debian/patches/0009-Fix-oggenc-crash-on-closing-raw-input-files.patch
2014-12-05 13:16:04.0 +0100
@@ -0,0 +1,37 @@
+From: =?utf-8?q?Martin_Stegh=C3=B6fer?=
+Date: Sat, 29 Nov 2014 10:57:11 +0100
+Subject: Fix oggenc crash on closing raw input files
+
+Origin: backport,
https://trac.xiph.org/changeset/19117/trunk/vorbis-tools/oggenc
+Author: Gregory Maxwell
+Bug-Debian: https://bugs.debian.org/771363
+
+Fixes a crash of oggenc on closing of any raw input file. The problem was
+a function call using a function pointer that had become invalid when
+a variable that was still referenced by a pointer ran out of scope.
+---
+ oggenc/oggenc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/oggenc/oggenc.c b/oggenc/oggenc.c
+index 5c36fea..7ad9303 100644
+--- a/oggenc/oggenc.c
b/oggenc/oggenc.c
+@@ -97,6 +97,8 @@ int main(int argc, char **argv)
+ .3,-1,
+ 0,0,0.f,
+ 0, 0, 0, 0, 0};
++input_format raw_format = {NULL, 0, raw_open, wav_close, "raw",
++ N_("RAW file reader&qu
Bug#763338: Get #763338 and #771363 into Jessie
If we want to get this into Jessie, we probably need to act now. Could you try getting this uploaded, Petter? Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763338: /usr/bin/vorbistagedit: Doesn't escape filenames properly
Thank you for reporting this problem, Roland! I tried to track the problem down. I'm certainly not a shell-script expert, but I think I fixed it. The patch that was applied earlier to fix this bug only fixed the quoting of the *input* to "getopt". However, there was still a problem with the interpretation of its *output* that didn't take into account its quoting. "GNU getopt" quotes its output, so it can be correctly split into parameters. However, just using that output directly in a for loop doesn't take into account that quoting, but splits the output string at every space regardless its quoting. To avoid this, the output of "getopt" is now parsed using "eval set --", which overwrites the original command-line parameters with the ones provided by "getopt", taking into account quoting. Iterating over those parameters using a "while" loop with the "shift" command (to advance) provides an additional positive effect: The possibility to process the options in the first loop and the filenames in a second loop. Before, the filename loop processed all options a second time. Therefore you could only have options that exited immediately (otherwise they would be interpreted as filenames in the second loop). The changes are in git's master branch right now. We should probably cherry-pick the commit into the branch "jessie-fixes" and upload a new version of the package because this has a realistic chance of going into jessie, doesn't it? Could somebody maybe give it a little more testing? I'm not sure, if my own testing covered all possible edge cases. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771448: vorbistagedit doesn't read filenames from stdin
Package: vorbis-tools Version: 1.4.0-5 Severity: normal File: /usr/bin/vorbistagedit While working on the fix for #763338, related to the "vorbistagedit" script, I discovered another issue with the same script: The documentation claims that without input files given as command-line arguments the list of input filenames is read from stdin, and indeed there is code in the script to do so. However, that code is never actually executed. If there are no input files given as command-line arguments, the "usage" error message is shown and the script quits. I assume that the guard showing the "usage" information and exiting was introduced in order to avoid confusion for users that launch the script vorbistagedit without parameters and get a program that waits for input without saying anything. I worked around this confusion by adding an explanatory message in case that stdin comes from an interactive console. So the guard preventing input from stdin could be removed. The "usage" error message is only shown, if *after* reading from stdin the filename list is still empty. The change is in git's master branch. Probably this isn't important enough to make it into Jessie, is it? Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771363: Fixed in git; severity "important"
severity 771363 important thanks Fixed in git. I'm changing the severity of this to "important": Even though the crash happens *after* correctly encoding the file, it prevents posterior files from being encoded and makes batch encoding impossible. This severity probably qualifies the fix to go into Jessie during the first freeze phase. I will file an unblock request as soon as the package is uploaded. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771363: oggenc --raw segfaults
tags 771363 confirmed thanks Jakub Wilk wrote: Package: vorbis-tools Version: 1.4.0-5 oggenc --raw seems to always segfault: Thanks for the bug report, Jakub! I can reproduce this bug in 1.4.0-5 and several older versions, so this isn't something we broke recently. And it doesn't only crash on empty files (like in your example), but also on every other raw file I've tried. I can look into it this weekend. The valgrind report seems pretty helpful: | Use of uninitialised value of size 8 |at 0x403392: main (oggenc.c:449) | | Jump to the invalid address stated on the next line |at 0x1C8: ??? |by 0x403394: main (oggenc.c:449) | Address 0x1c8 is not stack'd, malloc'd | or (recently) free'd The crash only happens when using optimization during compilation. However, I'm afraid this comes too late to be fixed for Jessie. The first phase of the freeze (with "important" bugs accepted) is over on 5th December and even if we upload right now, the package won't make it into "testing" in time. Or am I misreading the Freeze Policy and the 5th December applies to the "unblock" (instead of the actual migration to "testing")? Getting it into Jessie during the second phase of the freeze doesn't seem to be viable either, at first sight this doesn't seem to be an RC bug. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769479: unblock: libvorbis/1.3.4-2 (fix invalid memory access)
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Please unblock package libvorbis. The version 1.3.4-2, currently in
unstable, fixes bug #716613, which is about an access to invalid memory
by the encoding library of libvorbis. The bug has the potential to crash
applications that use libvorbis with a segfault, if the application
doesn't have additional sanity checks in place that go beyond checking
libvorbis' return values.
The changlog entry for 1.3.4-2:
[ Martin Steghöfer ]
* Add sampling rate sanity check to avoid invalid memory access.
(Closes: #716613
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716613>)
Please find attached a debdiff between the version in testing (1.3.4-1)
and the version to unblock (1.3.4-2).
Thanks!
Martin
unblock libvorbis/1.3.4-2
-- System Information:
Debian Release: 7.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libvorbis-1.3.4/debian/changelog libvorbis-1.3.4/debian/changelog
--- libvorbis-1.3.4/debian/changelog2014-10-24 20:15:54.0 +0200
+++ libvorbis-1.3.4/debian/changelog2014-11-04 12:09:32.0 +0100
@@ -1,3 +1,11 @@
+libvorbis (1.3.4-2) unstable; urgency=low
+
+ [ Martin Steghöfer ]
+ * Add sampling rate sanity check to avoid invalid memory access.
+(Closes: #716613)
+
+ -- Petter Reinholdtsen Mon, 03 Nov 2014 09:08:25 +0100
+
libvorbis (1.3.4-1) unstable; urgency=medium
[ Martin Steghöfer ]
diff -Nru
libvorbis-1.3.4/debian/patches/0004-Add-sampling-rate-sanity-check-to-avoid-invalid-memo.patch
libvorbis-1.3.4/debian/patches/0004-Add-sampling-rate-sanity-check-to-avoid-invalid-memo.patch
---
libvorbis-1.3.4/debian/patches/0004-Add-sampling-rate-sanity-check-to-avoid-invalid-memo.patch
1970-01-01 01:00:00.0 +0100
+++
libvorbis-1.3.4/debian/patches/0004-Add-sampling-rate-sanity-check-to-avoid-invalid-memo.patch
2014-11-04 12:09:32.0 +0100
@@ -0,0 +1,38 @@
+From: =?utf-8?q?Martin_Stegh=C3=B6fer?=
+Date: Mon, 27 Oct 2014 22:06:15 +0100
+Subject: Add sampling rate sanity check to avoid invalid memory access.
+
+Bug-Debian: https://bugs.debian.org/716613
+
+Input files with sampling rate 0 are useless and can make
+libvorbis access invalid memory because the logic in
+_vp_psy_init (and probably other functions) isn't prepared for
+it. A sanity check lets the library refuse those inputs
+gracefully in the initialization functions before they can
+do harm.
+---
+ lib/vorbisenc.c | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/lib/vorbisenc.c b/lib/vorbisenc.c
+index f0f7c08..afd1bff 100644
+--- a/lib/vorbisenc.c
b/lib/vorbisenc.c
+@@ -903,6 +903,8 @@ int vorbis_encode_setup_vbr(vorbis_info *vi,
+ long channels,
+ long rate,
+ float quality){
++ if(rate <= 0) return OV_EINVAL;
++
+ codec_setup_info *ci=vi->codec_setup;
+ highlevel_encode_setup *hi=&ci->hi;
+
+@@ -948,6 +950,8 @@ int vorbis_encode_setup_managed(vorbis_info *vi,
+ long nominal_bitrate,
+ long min_bitrate){
+
++ if(rate <= 0) return OV_EINVAL;
++
+ codec_setup_info *ci=vi->codec_setup;
+ highlevel_encode_setup *hi=&ci->hi;
+ double tnominal=nominal_bitrate;
diff -Nru libvorbis-1.3.4/debian/patches/series
libvorbis-1.3.4/debian/patches/series
--- libvorbis-1.3.4/debian/patches/series 2014-10-24 20:15:54.0
+0200
+++ libvorbis-1.3.4/debian/patches/series 2014-11-04 12:09:32.0
+0100
@@ -1,3 +1,4 @@
0001-Fix-build-failure-with-DSO-link-changes.patch
0002-Avoid-SIGFPE-when-bytespersample-is-zero.patch
0003-Fix-hang-when-loading-Ogg-Theora-files-in-audacity.patch
+0004-Add-sampling-rate-sanity-check-to-avoid-invalid-memo.patch
Bug#768685: libtheora: FTBFS in jessie: ld: player_example-player_example.o: undefined reference to symbol 'rintf@@GLIBC_2.2.5'
tags 768685 + patch pending thanks Hi Simon! Thanks for your help! The patch works fine. It compiles in my unstable jail on amd64 and the player example binary still works as expected. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538025: Still found in 1.4.0-4
found 538025 vorbis-tools/1.4.0-4 thanks This is still an issue in 1.4.0-4. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#359948: vorbis-tools: ogg123 undocumentedly requires -d to preceed -f
On Wed, 29 Mar 2006 09:40:47 -0900 Britton Leo Kerin wrote: > Actually the man page doesn't really even say that -f is going to > require -d, and the error message that you get when you try -f alone > doesn't say that you need to have the -d preceed the -f, though this > requirement probably makes sense. So it ends up looking like it just > doesn't work unless you happen to try switching the options around. Well, the man page (of both the old 1.1.1-3 version on which the bug was reported and the most recent version 1.4.0-4) does say it in the synopsis (pay attention to the square brackets): [ -d driver [ -o option:value ] [ -f filename ] ] The "ogg123 --usage" output also mentions it and is more explicit: -f file, --file file Set the output filename for a file device previously specified with --device. But I think the documentation can be more explicit in 2 places: The "options" section of the man page doesn't mention the condition. And the error message after using the "-f" option alone lets you now that "-d" is needed, but doesn't say it must precede the "-f" option. I will provide a patch to improve this. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578720: vorbis-tools: Sends invalid argument to ALSA when playing some files
tags 578720 wontfix thanks Hi John! On Thu, 22 Apr 2010 07:44:50 +0100 John Talbut wrote: Playing: /data/Sounds/Barbara_Allen.ogg Ogg Vorbis stream: 1 channel, 44100 Hz ALSA snd_pcm_hw_params_set_channels error: Invalid argument Error: Cannot open device alsa. The error message here is a bit cryptic. What it tries to say is: Your output device doesn't support Mono playback and no software in the output pipeline (that probably looks somewhat like the following in your case) is willing to do the necessary upmixing: ogg123 -> libao -> ALSA -> device driver -> hardware Doing the upmixing in ogg123 is certainly out of its scope and libao also seems too simple. ALSA has plugins to support upmixing [1] [2]. The device driver or the hardware are certainly harder to replace. You could also put a sound server like pulseaudio in the middle, that could do the upmixing, too. Alsacap [3] seems like an interesting tool to check, which modes your current ALSA configuration supports. Cheers, Martin [1] https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture#Upmixing [2] https://packages.debian.org/jessie/libasound2-plugins [3] http://www.volkerschatz.com/noise/alsa.html#alsacap -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745857: ogg123 outputs corrupt sound when pulseaudio is installed
tags 745857 moreinfo
thanks
Hi Stefan!
Thanks for reporting this bug. It would really help us, if you could
contribute some more information about this. To get started, some questions:
1. Which output device ("-d" option) are you using with ogg123? Does the
stuttering happen with all of them? Even if you're not using Pulseaudio
directly, audio is very likely routed through it.
2. Does the stuttering happen with other programs that use the same
device (ALSA, Pulseaudio, OSS,...)?
3. Do you observe high CPU load of any application (e.g. ogg123,
pulseaudio) during the playback?
4. Is the stuttering specific to any files or does it happen with all of
them (maybe depending on their sampling rate etc.)?
Cheers,
Martin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739099: vorbis-tools: ogg123 manpage inadequately documents -d option
tags 739099 moreinfo
thanks
On Sat, 15 Feb 2014 19:57:36 + Paul LeoNerd Evans
wrote:
The manpage briefly mentions the -d option, and says it takes such
choices as 'alsa'. It further mentions that the 'alsa' option has
some sub-parameters.
However, the manpage doesn't include a sufficiently-clear example or
explanation on how to build the actual value for the -d option to
contain these options. Are they comma-separated? Colons? Use
name=value or name:value, or what..?
Excerpts from the manpage of ogg123 in vorbis-tools 1.4.0-1:
[ -d driver [ -o option:value ] [ -f filename ] ]
(Synopsis)
-o option[:value], --device-option option[:value]
Sets the option option to value for the preceding
device. See DEVICES for a list of valid options for
each device.
(Options)
alsa Advanced Linux Sound Architecture live output driver. Options:
buffer_time:value
Override the default hardware buffer size (in milliseconds).
(One of many examples for options:value pairs in the "Devices" section)
I'm not sure what else you'd expect here. Especially your doubt about
the format of the name-value pairs seems to be explained in the very
first paragraph of the man page ("-o option:value"). Is the information
not structured enough? Not visible enough? Ambiguous?
Cheers,
Martin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#307325: ogg123 freeze when interrupting at End-Of-Stream
Hi Rémi! On Sat, 10 Apr 2010 12:02:40 +0300 Rémi Denis-Courmont wrote: reopen 307325 submitter 307325 ! found 307325 1.4.0-1 thanks This is still happening here. If I press Ctrl+C when ogg123 shows '(EOS)' at the end of the status line (after Output Buffer), it gets completely stuck. Thank you for your persistence and sorry that the bug has been open for such a long time. The vorbis-tools package didn't really have maintainers for some time. Now we (some new members that joined the packaging team) are trying to shake things up. I've prepared a patch for the problem and submitted it to our repository. It will be part of the next release 1.4.0-5. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#312185: vorbis-tools: ogg123 plays speex files wrong: clicks, then silence.
Bug still reproducible with vorbis-tools 1.4.0-4. As this issue happens mostly with this specific file, a decoding issue would stand to reason. However, the issue happens even after transcoding the speex file to ogg vorbis (using audacity). As it's very unlikely that the actual waveform is causing the issue, the trigger has to be some other data that survives the transcoding, like sampling rate or number of channels. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716613: [Mayhem] Bug report on vorbis-tools: oggenc crashes with exit status 136
reassign 716613 libvorbisenc2 thanks This test case actually triggers 2 bugs that are both related to the sampling rate of the input file being 0: The first one being in libvorbis (including the most recent version 1.3.4-1): ==29485== Invalid read of size 4 ==29485==at 0x50F62C2: _vp_psy_init (psy.c:308) ==29485==by 0x50EE7AA: _vds_shared_init (block.c:225) ==29485==by 0x50EEB9D: vorbis_analysis_init (block.c:298) ==29485==by 0x409294: oe_encode (encode.c:357) ==29485==by 0x403E8F: main (oggenc.c:431) ==29485== Address 0x5e3189c is 4 bytes before a block of size 1,024 alloc'd ==29485==at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_ memcheck-amd64-linux.so) ==29485==by 0x50F609A: _vp_psy_init (psy.c:279) ==29485==by 0x50EE7AA: _vds_shared_init (block.c:225) ==29485==by 0x50EEB9D: vorbis_analysis_init (block.c:298) ==29485==by 0x409294: oe_encode (encode.c:357) ==29485==by 0x403E8F: main (oggenc.c:431) The second one being in vorbis-tools: ==29485== Process terminating with default action of signal 8 (SIGFPE) ==29485== Integer divide by zero at address 0x8031102BE ==29485==at 0x409D22: final_statistics (encode.c:752) ==29485==by 0x4099AA: oe_encode (encode.c:697) ==29485==by 0x403E8F: main (oggenc.c:431) Neither software is prepared to handle the (useless) case of having an input with sampling rate 0. Instead of accessing invalid memory or producing a SIGFPE, they should both separately bail out thanks to a sanity check. Reassigning this bug to libvorbis because that's the library where the change has more impact (and even fixing it only in libvorbis would avoid the crash), but both packages should be fixed up. Will provide patches soon. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510459: No luck reproducing this
I've tried to reproduce this issue on an installation with all the old library versions mentioned in the original bug report. No luck so far. In order to reproduce it I've tried several combinations of the following: * Play with inaccessible ALSA (original bug report) * Play with 2 instances in parallel using OSS (suggested in msg #25) * Play with ALSA volume set to 0 (suggested in msg #30) * Play within a detached screen session (suggested in Ubuntu bug mentioned in msg #45) * Play streaming from an icecast2 server (suggested in msg #40) No hang and no valgrind error message whatsoever :-( Maybe this is platform specific? The original bug report mentions powerpc, I'm trying on amd64. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765341: Please don't let audacity freeze like this...
Martin Steghöfer wrote:
Andoru Ekkusu wrote:
Does anyone have any idea when this patch will be committed?
Hopefully soon, otherwise the new package won't make it to testing in
time before the freeze. Then getting the fix into jessie will become
much more complicated. I think it's quite important for the usability
to have these remaining issues fixed.
Attaching a debdiff fixing the bugs #765341 and #765779 - in case that
helps.
Cheers,
Martin
diff -Nru audacity-2.0.6/debian/changelog audacity-2.0.6/debian/changelog
--- audacity-2.0.6/debian/changelog 2014-10-14 01:28:54.0 +0200
+++ audacity-2.0.6/debian/changelog 2014-10-25 16:54:13.0 +0200
@@ -1,3 +1,12 @@
+audacity (2.0.6-2) unstable; urgency=medium
+
+ * Workaround for wx bug causing layout problems in recovery dialog.
+ * Fix effect dialog segfault due to events before initialization and
+add workaround for wxWidgets bug "Reentry in clipboard". (Closes: #765341)
+ * Fix cursor recapturing in track panel sliders. (Closes: #765779)
+
+ -- Martin Steghöfer Sat, 25 Oct 2014 16:16:17 +0200
+
audacity (2.0.6-1) unstable; urgency=medium
* New upstream release.
diff -Nru audacity-2.0.6/debian/patches/fix-cursor-recapturing-sliders.patch
audacity-2.0.6/debian/patches/fix-cursor-recapturing-sliders.patch
--- audacity-2.0.6/debian/patches/fix-cursor-recapturing-sliders.patch
1970-01-01 01:00:00.0 +0100
+++ audacity-2.0.6/debian/patches/fix-cursor-recapturing-sliders.patch
2014-10-25 16:48:02.0 +0200
@@ -0,0 +1,26 @@
+Description: Fix cursor recapturing in track panel sliders
+ wxWidgets 3.0 has added a lot of asserts to detect incorrect usage
+ of its APIs. Now capturing the cursor, when it's already captured,
+ throughs an assertion failure. This can be the case in the track
+ panel sliders because the sliders capture the cursor themselves
+ (because they are also used in other places outside the track panel,
+ where this is actually necessary), but the track panel also manages
+ the cursor capturing because it needs it for other operations.
+ Fix the recapturing problem by letting the sliders capture the cursor
+ only if necessary.
+Author: Martin Steghöfer
+Bug-Debian: https://bugs.debian.org/
+
+--- a/src/widgets/ASlider.cpp
b/src/widgets/ASlider.cpp
+@@ -1070,7 +1070,9 @@ void LWSlider::OnMouseEvent(wxMouseEvent & event)
+event.ShiftDown());
+ }
+
+- mParent->CaptureMouse();
++ if (!mParent->HasCapture()) {
++ mParent->CaptureMouse();
++ }
+ // wxSetCursor(wxCURSOR_BLANK);
+ ((TipPanel*)LWSlider::sharedTipPanel)->SetTargetParent(mParent);
+ FormatPopWin();
diff -Nru audacity-2.0.6/debian/patches/series
audacity-2.0.6/debian/patches/series
--- audacity-2.0.6/debian/patches/series2014-10-14 01:24:08.0
+0200
+++ audacity-2.0.6/debian/patches/series2014-10-25 16:56:23.0
+0200
@@ -1,3 +1,7 @@
fix-minsrc-autoreconf.patch
wxWidgets-3.0.patch
clang-ftbfs.patch
+fix-cursor-recapturing-sliders.patch
+workaround-wxwidgets-fit-recovery.patch
+wxwidgets-clipboard-reentry-workaround.patch
+wxwidgets-effect-dialogs-segfault.patch
diff -Nru audacity-2.0.6/debian/patches/workaround-wxwidgets-fit-recovery.patch
audacity-2.0.6/debian/patches/workaround-wxwidgets-fit-recovery.patch
--- audacity-2.0.6/debian/patches/workaround-wxwidgets-fit-recovery.patch
1970-01-01 01:00:00.0 +0100
+++ audacity-2.0.6/debian/patches/workaround-wxwidgets-fit-recovery.patch
2014-10-25 16:48:59.0 +0200
@@ -0,0 +1,65 @@
+Description: Workaround for wx bug causing layout problems in recovery dialog
+ Workaround for a bug in wxWidgets 3.0 that causes the Fit()
+ function to fail in certain desktop environments (gnome, xfce)
+ before the first window of the same style class is shown on
+ screen (http://trac.wxwidgets.org/ticket/16440). As a workaround,
+ call Fit() and other methods that depend on its results again
+ *after* we know that the window has been shown. While the bug
+ may affect other calls to Fit() on a low level, the workaround
+ is necessary only for the recovery dialog, which is particularly
+ vulnerable because:
+ 1. It is shown very, very early in the program execution and
+ therefore very likely to be the first dialog of its style class
+ shown on screen.
+ 2. It doesn't have scrollbars or flexible-size controls that
+ could compensate the wrong dialog size.
+Author: Martin Steghöfer
+Forwarded: llluc...@gmail.com, 2014-10-20
+Bug-Debian: http://bugs.debian.org/765341
+
+--- a/src/AutoRecovery.cpp
b/src/AutoRecovery.cpp
+@@ -38,6 +38,10 @@
+ public:
+AutoRecoveryDialog(wxWindow *parent);
+
++#if defined(__WXGTK__) && wxCHECK_VERSION(3, 0, 0)
++ void OnShow(wxShowEvent & event);
++#endif
++
+ private:
+void PopulateList();
+void PopulateOrExchange(ShuttleGui & S);
+@@ -65,6 +69,9 @@
+
Bug#765779: Maintainers, please make sure this makes it into testing in time :-)
Andoru Ekkusu wrote: Does anyone have any idea when this patch will be committed? Hopefully soon, otherwise the new package won't make it to testing in time before the freeze. Then getting the fix into jessie will become much more complicated. I think it's quite important for the usability to have these remaining issues fixed. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765341: Maintainers, please make sure this makes it into testing in time :-)
Hopefully the maintainers pick up those fixes soon, otherwise the new package won't make it to testing in time before the freeze. Then getting the fixes into jessie will become much more complicated. I think it's quite important for the usability to have these remaining issues fixed. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765341: more information
El 21/10/14 a les 14:13, Klaumi Klingsporn ha escrit:
sorry for the late answer
No need to apologize, you've been a great help so far!
El 21/10/14 a les 16:10, Klaumi Klingsporn ha escrit:
and I also added the
configure flag '--with-lv2=system' to Debian/rules
...which I think is a good idea, independently of the current problems.
I'd suggest that the package maintainers do the same, if there is no
specific reason not to.
In audacity-2.0.6/src/effects/lv2/LV2Effect.cpp I found your comment
from the wxWidgets-3.patch:
" // wxWidgets calls OnTextCtrl during creation
// of the text control, and LadspaEffectDialog::OnTextCtrl calls
HandleText,
// which assumes all the fields have been initialized.
// This can give us a bad pointer crash, so manipulate inSlider to
// no-op HandleText during creation. "
This is already very close. :-)
But actually the comment wasn't added by my wxWidgets patch, but was
there before. And it's not the problem, but the solution. It's a
workaround that has been in several effect dialogs to avoid a crash on
Windows. Starting from wxWidgets 3.0 this workaround is necessary for
GTK, too. In fact, the wxWidgets patch already activated it for the
LadspaEffectDialog, but neither for the VampEffectDialog nor the
LV2EffectDialog.
The attached patch (wxwidgets-effect-dialogs-segfault.patch) now does it
for those, too. Again, I also re-attached the patches for the other
problems you mentioned in this report.
Cheers,
Martin
P.S.: Depending on the plugin parameters, those LV2 dialogs look really
ugly (empty space in weird places, empty boxes,...). But that's
something unrelated to the library upgrade and has to be improved for
the next upstream version, not in this Debian bug.
Description: Workaround for wx bug causing layout problems in recovery dialog
Workaround for a bug in wxWidgets 3.0 that causes the Fit()
function to fail in certain desktop environments (gnome, xfce)
before the first window of the same style class is shown on
screen (http://trac.wxwidgets.org/ticket/16440). As a workaround,
call Fit() and other methods that depend on its results again
*after* we know that the window has been shown. While the bug
may affect other calls to Fit() on a low level, the workaround
is necessary only for the recovery dialog, which is particularly
vulnerable because:
1. It is shown very, very early in the program execution and
therefore very likely to be the first dialog of its style class
shown on screen.
2. It doesn't have scrollbars or flexible-size controls that
could compensate the wrong dialog size.
Author: Martin Steghöfer
Forwarded: llluc...@gmail.com, 2014-10-20
Bug-Debian: http://bugs.debian.org/765341
--- a/src/AutoRecovery.cpp
+++ b/src/AutoRecovery.cpp
@@ -38,6 +38,10 @@
public:
AutoRecoveryDialog(wxWindow *parent);
+#if defined(__WXGTK__) && wxCHECK_VERSION(3, 0, 0)
+ void OnShow(wxShowEvent & event);
+#endif
+
private:
void PopulateList();
void PopulateOrExchange(ShuttleGui & S);
@@ -65,6 +69,9 @@
EVT_BUTTON(ID_RECOVER_ALL, AutoRecoveryDialog::OnRecoverAll)
EVT_BUTTON(ID_RECOVER_NONE, AutoRecoveryDialog::OnRecoverNone)
EVT_BUTTON(ID_QUIT_AUDACITY, AutoRecoveryDialog::OnQuitAudacity)
+#if defined(__WXGTK__) && wxCHECK_VERSION(3, 0, 0)
+ EVT_SHOW(AutoRecoveryDialog::OnShow)
+#endif
END_EVENT_TABLE()
void AutoRecoveryDialog::PopulateOrExchange(ShuttleGui& S)
@@ -102,6 +109,22 @@
Center();
}
+#if defined(__WXGTK__) && wxCHECK_VERSION(3, 0, 0)
+void AutoRecoveryDialog::OnShow(wxShowEvent & event)
+{
+ // Workaround for wxWidgets bug #16440:
+ // http://trac.wxwidgets.org/ticket/16440
+ // Fit() doesn't work correctly in some desktop environments
+ // with GTK. But it does work after the first window of the
+ // same style class has been shown on screen. So re-execute
+ // Fit() and other methods that depend on its result AFTER
+ // we know that the window has been shown.
+ Fit();
+ SetMinSize(GetSize());
+ Center();
+}
+#endif
+
void AutoRecoveryDialog::PopulateList()
{
mFileList->DeleteAllItems();
Description: Workaround for wxWidgets bug: Reentry in clipboard
The wxWidgets bug http://trac.wxwidgets.org/ticket/16636 prevents
us from doing clipboard operations in wxShowEvent and wxTimerEvent
processing because those event could possibly be processed during
the (not sufficiently protected) Yield() of a first clipboard
operation, causing reentry. Audacity had a workaround in place
for this problem (the class "CaptureEvents"), which however isn't
applicable with wxWidgets 3.0 because it's based on changing the
gdk event handler, a change that would be overridden by wxWidgets's
own gdk event handler change.
Instead, as a new workaround, specifically protect those processings
of wxShowEvent and wxTimerEvent that try to do clipboard operations
from being executed within Yield(). This is done by delaying their
execution by posting pure wxWidge
Bug#765341: Patch available
Hi Manfred! Manfred wrote: I get the same error which Klaumi reported. I installed Audacity today using Synaptic, then I recorded both sides of a turntable without problems. First time that error occured after pressing ctrl-B, it always occurs when playing a .aup file, also those files which were created with my old Debian system (Lenny or Squeeze). An empty dialog window opens which can't be closed and the app window doen't react by any click, while still playing the file. Thank you for the information! But the bug can already be reproduced quite reliably by the example project that Klaumi submitted. And I believe that the problem is fixed by the patch "wxwidgets-clipboard-reentry-workaround.patch" that I posted earlier. Now it is important that someone actually tests the patch and the package maintainers include it in a new version of the package (if they find it suitable). If you encounter this problem again in a future audacity package version including the patch (most likely version 2.0.6-2), we would very much appreciate it, if you reported it again. Thank you! Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765341: more information
Fabian Greffrath wrote: just because noone has done this so far (or I have read over it), I want to thank you for the massive amount of effort and time you invest in fixing these bugs, both in Audacity and in wxwidgets! So, thank you! ;) It's always nice to be appreciated, thanks! :-) Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765341: more information
tag 765341 patch
thanks
El 16/10/14 a les 20:19, Martin Steghöfer ha escrit:
2. Small buttons in the project recovery dialog
[...]
Regarding 2: I've observed this. It's a bug of wxWidgets 3.0.x. I've
filed it in the wxWidget upstream tracker, but it doesn't seem to
receive much attention:
http://trac.wxwidgets.org/ticket/16440
As upstream clearly won't provide a fix for that in time, I've attached
a patch for audacity (workaround-wxwidgets-fit-recovery.patch) that
works around this problem.
(I've attached the bug for your problem 1 again, to make sure it doesn't
get lost. Both attached patches are necessary to fix/workaround problems
1 and 2.)
Cheers,
Martin
Description: Workaround for wx bug causing layout problems in recovery dialog
Workaround for a bug in wxWidgets 3.0 that causes the Fit()
function to fail in certain desktop environments (gnome, xfce)
before the first window of the same style class is shown on
screen (http://trac.wxwidgets.org/ticket/16440). As a workaround,
call Fit() and other methods that depend on its results again
*after* we know that the window has been shown. While the bug
may affect other calls to Fit() on a low level, the workaround
is necessary only for the recovery dialog, which is particularly
vulnerable because:
1. It is shown very, very early in the program execution and
therefore very likely to be the first dialog of its style class
shown on screen.
2. It doesn't have scrollbars or flexible-size controls that
could compensate the wrong dialog size.
Author: Martin Steghöfer
Forwarded: llluc...@gmail.com, 2014-10-20
Bug-Debian: http://bugs.debian.org/765341
--- a/src/AutoRecovery.cpp
+++ b/src/AutoRecovery.cpp
@@ -38,6 +38,10 @@
public:
AutoRecoveryDialog(wxWindow *parent);
+#if defined(__WXGTK__) && wxCHECK_VERSION(3, 0, 0)
+ void OnShow(wxShowEvent & event);
+#endif
+
private:
void PopulateList();
void PopulateOrExchange(ShuttleGui & S);
@@ -65,6 +69,9 @@
EVT_BUTTON(ID_RECOVER_ALL, AutoRecoveryDialog::OnRecoverAll)
EVT_BUTTON(ID_RECOVER_NONE, AutoRecoveryDialog::OnRecoverNone)
EVT_BUTTON(ID_QUIT_AUDACITY, AutoRecoveryDialog::OnQuitAudacity)
+#if defined(__WXGTK__) && wxCHECK_VERSION(3, 0, 0)
+ EVT_SHOW(AutoRecoveryDialog::OnShow)
+#endif
END_EVENT_TABLE()
void AutoRecoveryDialog::PopulateOrExchange(ShuttleGui& S)
@@ -102,6 +109,22 @@
Center();
}
+#if defined(__WXGTK__) && wxCHECK_VERSION(3, 0, 0)
+void AutoRecoveryDialog::OnShow(wxShowEvent & event)
+{
+ // Workaround for wxWidgets bug #16440:
+ // http://trac.wxwidgets.org/ticket/16440
+ // Fit() doesn't work correctly in some desktop environments
+ // with GTK. But it does work after the first window of the
+ // same style class has been shown on screen. So re-execute
+ // Fit() and other methods that depend on its result AFTER
+ // we know that the window has been shown.
+ Fit();
+ SetMinSize(GetSize());
+ Center();
+}
+#endif
+
void AutoRecoveryDialog::PopulateList()
{
mFileList->DeleteAllItems();
Description: Workaround for wxWidgets bug: Reentry in clipboard
The wxWidgets bug http://trac.wxwidgets.org/ticket/16636 prevents
us from doing clipboard operations in wxShowEvent and wxTimerEvent
processing because those event could possibly be processed during
the (not sufficiently protected) Yield() of a first clipboard
operation, causing reentry. Audacity had a workaround in place
for this problem (the class "CaptureEvents"), which however isn't
applicable with wxWidgets 3.0 because it's based on changing the
gdk event handler, a change that would be overridden by wxWidgets's
own gdk event handler change.
Instead, as a new workaround, specifically protect those processings
of wxShowEvent and wxTimerEvent that try to do clipboard operations
from being executed within Yield(). This is done by delaying their
execution by posting pure wxWidgets events - which are never executed
during Yield().
Author: Martin Steghöfer
Bug-Debian: https://bugs.debian.org/765341
--- a/src/Project.cpp
+++ b/src/Project.cpp
@@ -1625,9 +1625,13 @@
// Call "OnSize" again (the previous calls to "OnSize" might not
// have succeeded because some methods are not available before
- // the actual creation/showing of the window)
- wxSizeEvent sizeEvent(GetSize());
- OnSize(sizeEvent);
+ // the actual creation/showing of the window).
+ // Post the event instead of calling OnSize(..) directly. This ensures that
+ // this is a pure wxWidgets event (no GDK event behind it) and that it
+ // therefore isn't processed within the YieldFor(..) of the clipboard
+ // operations (workaround for Debian bug #765341).
+ wxSizeEvent *sizeEvent = new wxSizeEvent(GetSize());
+ GetEventHandler()->QueueEvent(sizeEvent);
// Further processing by default handlers
Bug#753744: audacity does nothing when trying to load a ogg-file by passing its name as argument
Hi! Would you mind sharing that .ogg file? This way your problem can be reproduced. I couldn't reproduce it with any of the .ogg files I have. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765779: audacity: "An assertion failed!" when changing track volume or panning
Dear Andoru,
thanks a lot for the bug report! :-)
With the upgrade to 3.0, wxWidgets enforces the correct usage of its API
a lot more with asserts. So now, many bugs that were in Audacity before
become visible as error messages (which themselves may cause even more
undesired behavior, if they pop up in the wrong moment like here).
In this case it complains about capturing a cursor that is already
captured. This happens in the track panel sliders because the sliders
capture the cursor themselves (because they are also used in other
places outside the track panel, where this is actually necessary), but
the track panel also manages the cursor capturing because it needs it
for other operations.
Fortunately, this has an easy fix: Simply prevent the sliders from
capturing the cursor, if it's already captured (see patch attached).
Regarding the small buttons in the recovery window: This is due to a bug
in upstream wxWidgets (http://trac.wxwidgets.org/ticket/16440).
Unfortunately, my bug report (filed months ago) hasn't received a lot of
attention. So we may have to think of a workaround for Audacity. If you
want to help, you can compile the example I submitted in the upstream
report and confirm the problem there, so at least the status can upgrade
from "new" to "confirmed". Maybe that makes it receive a little more
attention.
Cheers,
Martin
Description: Fix cursor recapturing in track panel sliders
wxWidgets 3.0 has added a lot of asserts to detect incorrect usage
of its APIs. Now capturing the cursor, when it's already captured,
throughs an assertion failure. This can be the case in the track
panel sliders because the sliders capture the cursor themselves
(because they are also used in other places outside the track panel,
where this is actually necessary), but the track panel also manages
the cursor capturing because it needs it for other operations.
Fix the recapturing problem by letting the sliders capture the cursor
only if necessary.
Author: Martin Steghöfer
Bug-Debian: https://bugs.debian.org/
--- a/src/widgets/ASlider.cpp
+++ b/src/widgets/ASlider.cpp
@@ -1070,7 +1070,9 @@ void LWSlider::OnMouseEvent(wxMouseEvent & event)
event.ShiftDown());
}
- mParent->CaptureMouse();
+ if (!mParent->HasCapture()) {
+ mParent->CaptureMouse();
+ }
// wxSetCursor(wxCURSOR_BLANK);
((TipPanel*)LWSlider::sharedTipPanel)->SetTargetParent(mParent);
FormatPopWin();
Bug#765341: more information
Hi Klaumi!
Regarding (1):
El 16/10/14 a les 23:53, Klaumi Klingsporn ha escrit:
You find a sample-project at:
https://www.dropbox.com/s/79d6p6sri6shlj5/sample-project.tgz?dl=0
Thanks, that sample project helped a lot to track down the problem! :-)
I identified the problem as a bug in wxWidgets 3.0. In order to fulfill
clipboard operations, they have to process GDK events. Unfortunately,
the processing isn't sufficiently protected and processes not only
clipboard events, but all kinds of stuff - like wxShowEvent and
wxTimerEvent, which in our case perform clipboard operations on their
own and cause the reentry.
If you want the details, you can find them in the upstream bug report I
filed:
http://trac.wxwidgets.org/ticket/16636
Actually the situation was even worse in wxWidgets 2.8: While in 3.0
they have a porous safety net in the event processing, in 2.8 they
didn't have any safety net at all. BUT:
* Audacity had its own safety net in place as a workaround - which,
however is now incompatible with wxWidgets' own safety net (they both
rely on changing the GDK event handler - whoever does the change later,
wins).
* The distribution of the clipboard operations (in which event they are
processed) in Audacity with 2.8 was more fortunate.
So I tried to work around this by shifting the moment of doing the event
processing that involves clipboard operations at a moment at which we
can be certain of not being in a YieldFor(..) call (and therefore not in
a clipboard operation executed before). I hope that I've covered all
dangerous processings, it's not easy to identify them. I've attached a
patch (wxwidgets-clipboard-reentry-workaround.patch) that works for me
with the audacity-2.0.6-1 package. Do you have the chance to try it? Or
do you want me to provide a binary package for you to try it or something?
3. Segmentation fault on applying LV2 plugins
[...]
Only an idea of an user-only: Maybe it has something to do with my
extra set configure-flag "--with-lv2=system".
I think there's a good chance that it's related to that. However, could
you be more specific about the LV2 plugin you tried and where it comes
from? The crash that I could produce turned out to be more related to
the LV2 plugin itself than audacity.
Cheers,
Martin
Description: Workaround for wxWidgets bug: Reentry in clipboard
The wxWidgets bug http://trac.wxwidgets.org/ticket/16636 prevents
us from doing clipboard operations in wxShowEvent and wxTimerEvent
processing because those event could possibly be processed during
the (not sufficiently protected) Yield() of a first clipboard
operation, causing reentry. Audacity had a workaround in place
for this problem (the class "CaptureEvents"), which however isn't
applicable with wxWidgets 3.0 because it's based on changing the
gdk event handler, a change that would be overridden by wxWidgets's
own gdk event handler change.
Instead, as a new workaround, specifically protect those processings
of wxShowEvent and wxTimerEvent that try to do clipboard operations
from being executed within Yield(). This is done by delaying their
execution by posting pure wxWidgets events - which are never executed
during Yield().
Author: Martin Steghöfer
Bug-Debian: https://bugs.debian.org/765341
--- a/src/Project.cpp
+++ b/src/Project.cpp
@@ -1625,9 +1625,13 @@
// Call "OnSize" again (the previous calls to "OnSize" might not
// have succeeded because some methods are not available before
- // the actual creation/showing of the window)
- wxSizeEvent sizeEvent(GetSize());
- OnSize(sizeEvent);
+ // the actual creation/showing of the window).
+ // Post the event instead of calling OnSize(..) directly. This ensures that
+ // this is a pure wxWidgets event (no GDK event behind it) and that it
+ // therefore isn't processed within the YieldFor(..) of the clipboard
+ // operations (workaround for Debian bug #765341).
+ wxSizeEvent *sizeEvent = new wxSizeEvent(GetSize());
+ GetEventHandler()->QueueEvent(sizeEvent);
// Further processing by default handlers
event.Skip();
--- a/src/TrackPanel.cpp
+++ b/src/TrackPanel.cpp
@@ -360,6 +360,8 @@
EVT_MENU(OnTimeTrackLinID, TrackPanel::OnTimeTrackLin)
EVT_MENU(OnTimeTrackLogID, TrackPanel::OnTimeTrackLog)
EVT_MENU(OnTimeTrackLogIntID, TrackPanel::OnTimeTrackLogInt)
+
+EVT_TIMER(wxID_ANY, TrackPanel::OnTimer)
END_EVENT_TABLE()
/// Makes a cursor from an XPM, uses CursorId as a fallback.
@@ -927,7 +929,7 @@
}
/// AS: This gets called on our wx timer events.
-void TrackPanel::OnTimer()
+void TrackPanel::OnTimer(wxTimerEvent& event)
{
mTimeCount++;
// AS: If the user is dragging the mouse and there is a track that
--- a/src/TrackPanel.h
+++ b/src/TrackPanel.h
@@ -207,7 +207,7 @@
virtual double GetMostRecentXPos();
- virtual void OnTimer();
+ virtual void OnTimer(wxTimerEvent& event);
virtual int GetLeftOffset() const { return GetLabelWidth() + 1;}
Bug#765341: more information
Hi Klaumi! Thank you for reporting the issue(s)! I have to admit that I'm a bit lost in your tale. Am I right that what you are reporting are the following 3 issues? 1. "assert !ms_clipboard failed in wxClipboardSync" in various occasions: a) When opening a certain project (all project in which you had applied LV2 plugins before?) b) When playing the current selection 2. Small buttons in the project recovery dialog 3. Segmentation fault on applying LV2 plugins Regarding 1: I am unable to reproduce this with any of my projects, neither by doing (a) nor (b). Maybe you could share a project that triggers the failure? Regarding 2: I've observed this. It's a bug of wxWidgets 3.0.x. I've filed it in the wxWidget upstream tracker, but it doesn't seem to receive much attention: http://trac.wxwidgets.org/ticket/16440 Maybe you can report being affected by that problem, too, so they raise its priority. If they don't fix it, we have to place some kind of workaround in Audacity. Regarding 3: I was able to reproduce that crash in Debian unstable. However, I could not reproduce it in Ubuntu (using the exact same audacity package with wxWidgets 3.0), which I found weird. Maybe there is something more to it than Audacity's problems. I'm looking into that. Cheers, Martin El 16/10/14 a les 13:36, Klaumi Klingsporn ha escrit: So, from my point of view as petty user, it would be better to link audacity against the old library for jessie. I know about the wxWidgets-transition, but the old version works works, upstream is working on the transition to wxwidgets 3.0 as well, why pressure the transition at this point? I don't think wx2.8 will be around in Jessie. For example, there are many, many packages that were designed to run with FFmpeg, but in Debian they have to be ported to libav. For wxWidgets 2.8 it's much less serious, most packages have made the transition cleanly some time ago, it's really only Audacity that still has slight problems with wx3.0 - which is mainly because the transition was completely ignored during several months. Also, the transition isn't really "pressured" (as you say), the corresponding bug was opened 5 months ago. So for now, let's try to get those issues fixed as soon as possible! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739722: libvorbis: New upstream release
Hi Kurt! On Tue, 9 Sep 2014 17:21:18 +0200 Kurt Roeckx wrote: Any news about this? Would you mind I did an NMU with the new > upstream version? It seems that no one of the packaging group that maintains this package is active any more. So Petter Reinholdtsen and me have joined the group, in order to get some work done on these important packages. Since you're proposing a NMU, maybe you have some work done on this already? Thank you! Cheers, Martin
Bug#762571: Patch for libvorbis (Was: Debdiff)
Petter Reinholdtsen wrote: Thank you very much. I used it when uploading an NMU fixing this issue and a few others. I converted the source format to 3.0 (quilt) in the process, to make it easier to track changes done to the upstream source. Thanks for your effort, otherwise this patch would have rotten in here for months, I guess. The quilt-conversion is also a great step forward for that package! Please test the new library and let me know if there are any problems with the NMU. I've tested the vorbis functionality of some programs that use libvorbis. So far everything looks fine to me. But as I said, I don't have a great testing environment for libvorbis set-up, so those were just very basic file reading and writing tests using different GUI multimedia programs based on libvorbis. Perhaps you can want to join the Debian Xiph.org Maintainers group. I suspect they could use some fresh blood. :) They sure do, considering that all of their packages currently in unstable are NMUs (except one, which is still the same version as years ago, untouched). I don't mind helping out, but in this case I guess "joining the team" means "being the team", which would be more effort than I am able to commit to, I'm sorry. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749659: audacity: Systematic check for Printf/Format mismatches
Hi Benjamin! Martin Steghöfer wrote: And before we just upload stuff to upstream, I'd also like to discuss the upstream integration with the person that has been working on wx3.0 there Looking at the recent upstream activity, I've changed my mind about this: We should get this into upstream as soon as possible! Otherwise porting the fixes is just going to be even more difficult. Now that someone has made an initial commit about wxWidgets 3.0, people upgrade and try to fix things - but not always in the proper way. Today's upstream commits alone justify being worried: 3 commits arrived upstream trying to fix wx3.0-related stuff: The first one removed functionality (!) in order to avoid the problems. The second one replaced one inadequate function call by another inadequate function call - which avoids the crash for the moment, but is equally wrong and may still crash with other compiler flags. The third one silenced a warning instead of fixing the underlying problem - which causes an invalid memory access and therefore a possible crash. With all those "fixes" in place, porting the patch won't only get harder (because of conflicts), but the diff will also become more cryptic (it's easier to understand a simple fix than to understand the fix of an existing fix). So today I took the time to port my fixes (again) to the current svn head. I've got them sitting in my local git, divided in many commits, for better documentation (the Debian patch is huge and no one can tell any more, which change corresponds to which fix). I can send them all to you and you import them manually into svn. Or I can commit them directly to the svn - I've got git-svn set-up, I'd just need access to the repository. I can also send the patches to you first, for inspection (but it's mainly what you've seen here in the debdiff, just divided, ported and with non-Debian-relevant changes). For the Debian package I still recommend the patch I've sent earlier today. Why bother with extra porting work and combining several patches (including additional porting work)? Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749659: audacity: Systematic check for Printf/Format mismatches
El 09/10/14 a les 01:11, Benjamin Drung ha escrit: Your patch needs to be forward ported, We already have a patch that fixes 2.0.6 for wxWidgets 3.0. Back when you asked me to forward-port my patch to the current svn head (in order to get the changes into upstream), I did. Apart from the porting it includes specific fixes for svn head. Fortunately, 2.0.6 isn't that different from what was svn head back then, so we have a patch for 2.0.6, find it attached. To keep it small, I've removed everything that isn't relevant here (fixes of dead code or code that otherwise isn't relevant on Debian), but we will have that available for upstream. Be aware that this patch is by far not as well tested as my patch for 2.0.5! [...] backport the preliminary upstream changes for wxWidgets 3.0.1 from r13403 [...] [...] Upstream want to get wx3.0 support in for 2.0.7 and is actively working on getting it in the svn "Actively working", yes, unfortunately. Why? Your messages sounded like upstream was aware of this being resolved already, especially with you being part of upstream (AFAIK). Not only was this a major duplication of effort, but now it also requires additional porting - which is mainly manual work here, given that different people have been working on similar issues and touching the same code, but in different ways. What we're doing here is really inefficient. So you could provide the missing bits and we will get upstream to test your proposed changes (when I commit them to the upstream repository). So you're proposing to do the upstream integration first? I'd do it the other way round, given that for 2.0.6 we already have a patch and that the upstream integration has just gotten more complicated. We've already lost a lot of time. And before we just upload stuff to upstream, I'd also like to discuss the upstream integration with the person that has been working on wx3.0 there, especially as he has been fixing some code that I consider obsolete with wx3.0 and that I'd like to fix some things in a different way. Cheers, Martin Description: Compile audacity against wxWidgets 3.0 Solved compilation issues: (1.) Allow wxWidgets 3.0 in various configure scripts. (2.) The file dialog was derived from an internal wx class that disappeared in wx3.0 (discussed in further detail below). (3.) In several places the types in interfaces changed between wxChar* and wxString. I've tried to modify the code so it works with both interfaces (thanks to implicit conversion; may look a bit weird in some places). (4.) Calls to "wxTheApp->SuspendIdleCallback()" are no longer supported. They were part of a workaround for a clipboard problem, which fortunately doesn't seem to be there any longer in wx3.0, so I deactivated it for wx3.0. (5.) AddPendingEvent() and ProcessEvent() now have the visibility "protected" in wxWindow. It has always been a bad idea to call them directly on a wxWindow object, but now it's explicitly forbidden. Instead, those functions should be called on the object returned by GetEventHandler(). (6.) The class wxStandardPaths is now a singleton and has to be treated as such (no more explicit constructor calls). (7.) "wxLogWarning" is a macro now, so the "::" prefix doesn't work on it anymore. (8.) Several int types (which were actually used as enums) are now real enum types (e.g. wxRasterOperationMode, wxMouseButton) and have to be used as such. (9.) Apart from the FD constants (which have been fixed in Olly's patch already) there are some other constants which have received a prefix (e.g. wx* -> wxFONTFAMILY_*, wx* -> wxFONTSTYLE_*, wx* -> wxFONTWEIGHT_*). (10.) Signature changes in constructors of wxFlexGridSizer and wxIcon and wxSizeEvent (11.) Missing includes (missing header files were probably included indirectly in wx2.8 by chance) (12.) When deriving from the abstract class wxGridTableBase, different methods have to be implemented with wx3.0 (EndEdit with new signature and ApplyEdit) than before with wx2.8 (only EndEdit with old signature). Now both versions are implemented in parallel in the classes TimeEditor and ChoiceEditor (one version essentially being a wrapper of the other one). Solved runtime issues: (1.) Segmentation fault: The LadspaEffectDialog receives EVT_TEXT events before it's properly initialized. To prevent this, a workaround was already in place, but was only active on Windows. It looks like this happens now on more platforms (including GTK). As the workaround doesn't do any harm, even if activated unnecessarily, I've simply activated it for all environments. (2.) GTK critical warning "IA__gtk_range_set_range: assertion 'min < max' failed" because of negative numbers as result of window size checking. Added a sanity check that straightens up the numbers in edge cases. (3.) GTK critical warning "IA__gdk_window_get_origin: assertion 'GDK_IS_WINDOW (window)' failed": Received events of type wxSizeEvent on
Bug#749136: jellyfish: FTBFS with clang instead of gcc
El 09/10/14 a les 13:16, Andreas Tille ha escrit: Thanks a lot for your work on this Always a pleasure working with you guys :-) Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749136: jellyfish: FTBFS with clang instead of gcc
Hi Andreas!
El 08/10/14 a les 21:06, Andreas Tille ha escrit:
Would you volunteer to check the current Git repository regarding the
clang issue? It's not ready yet but the state is good enough to look
into the clang build.
The current state of the package in Debian-Med's git repository has the
exact same issues as upstream HEAD (no more, no less). Therefore it
would be adequate to use the patching from my upstream pull request:
https://github.com/gmarcais/Jellyfish/pull/21
Btw. I think you're missing the tag "upstream/2.1.4" in order to make
git-buildpackage build it without complaints.
Sorry I can't be of any help there. I have no clue about ruby packaging.
Me neither but it's done and thanks to super fast ftpmaster yaggo is
just in unstable.
Cool, that was quick! :-)
For the record: The patch has been merged into upstream git
(https://github.com/gmarcais/Jellyfish/pull/21) and will therefore
be part of the next Release v2.1.5 - which could take a while to be
published.
Since I'm not that deep into Github: What would be the most
straightforward way to obtain these patches (and turn them into
quilt patches)?
You can just append a suffix ".patch" to the URLs of commits (e.g.
https://github.com/martin-steghoefer/Jellyfish/commit/780f2ec4.patch) or
complete pull requests (e.g.
https://github.com/gmarcais/Jellyfish/pull/21.patch), which will give
you a patch in git format. This is something that quilt already accepts,
although it is probably not "debianized" enough to put it into a package
like this (additional git-specific meta-data, wrong tagging format,
patch divided in several sections by commits). You can fix that by
letting quilt rewrite the patch with "dquilt refresh" (when it is the
top of the quilt stack) and then adding the Debian tagging.
I've done it for the pull request that is relevant here and attached it
to this message.
Cheers,
Martin
Description: Fix compilation using the "clang" compiler
This fixes 2 issues with the clang compilation:
1.) The length of the array defined locally in array::_get_val
cannot be detected to be constant by a standard C++ compiler.
GCC's g++ accepts the code anyway because of its ample support
for variable-length arrays (VLAs). Clang doesn't support VLAs
for non-POD (Plain Old Type) types. Starting from version 3.5,
however, it is able to detect the constant nature of the value
used (using non-standard language features, too) and therefore
doesn't need LVAs here. However, clang compilers before 3.5 as
well as compilers that support only pure C++ need this patching.
2.) The clang compiler warns about the "register" keyword being
deprecated in C++11. As the Jellyfish build system treats
warnings as errors, this breaks the build with clang. I suggest
to remove the keyword instead of silencing the warning because
most modern compilers (e.g. the recent versions of GCC, clang
and Visual Studio) ignore the keyword in their optimization
algorithms anyway.
Author: Martin Steghöfer
Forwarded: https://github.com/gmarcais/Jellyfish/pull/21
Bug-Debian: http://bugs.debian.org/749136
--- a/include/jellyfish/large_hash_array.hpp
+++ b/include/jellyfish/large_hash_array.hpp
@@ -444,7 +444,7 @@
bool get_key_id(const key_type& key, size_t* id, key_type& tmp_key, const word** w, const offset_t** o, const size_t oid) const {
// This static_assert makes clang++ happy
static_assert(std::is_pod::value, "prefetch_info must be a POD");
-prefetch_info info_ary[prefetch_buffer::capacity()];
+prefetch_info info_ary[prefetch_buffer::capacityConstant];
prefetch_buffer buffer(info_ary);
warm_up_cache(buffer, oid);
--- a/include/jellyfish/simple_circular_buffer.hpp
+++ b/include/jellyfish/simple_circular_buffer.hpp
@@ -106,6 +106,7 @@
class pre_alloc : public base > {
typedef base > super;
public:
+ static const int capacityConstant = capa;
explicit pre_alloc(T* data) : super(data) { }
static int capacity() { return capa; }
};
--- a/include/jellyfish/rectangular_binary_matrix.hpp
+++ b/include/jellyfish/rectangular_binary_matrix.hpp
@@ -261,8 +261,8 @@
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wuninitialized"
#endif
-register xmm_t acc = acc ^ acc; // Set acc to 0
-register xmm_t load = load ^ load;
+xmm_t acc = acc ^ acc; // Set acc to 0
+xmm_t load = load ^ load;
#ifdef __clang__
#pragma clang diagnostic pop
#endif
Bug#716353: biosquid: sreformat crash - Proposing patch
Hi there! :-)
I've fixed the crash. It was a segmentation fault due to a faulty
implementation of a command-line options parser.
The command line parser accessed invalid memory when a given option
matched several option definitions as a prefix, but none of them exactly
(e.g. "--s" as option with "--sam" and "--samfrac" as option
definitions). This was due to an incorrect check of exact matching that
tried to access "opt[i].name" with i being greater than the upper bound
of the array "opt" in case of not having an exact match. Replaced it
with the proper check.
Please find the patch attached.
I couldn't forward the patch to upstream because there doesn't seem to
be an upstream any more... :-/
Cheers,
Martin
Description: Fix segmentation fault with ambiguous arguments
The command line parser accessed invalid memory when a given
option matched several option definitions as a prefix, but none
of them exactly (e.g. "--s" as option with "--sam" and
"--samfrac" as option definitions). This was due to an incorrect
check of exact matching that tried to access "opt[i].name" with
i being greater than the upper bound of the array "opt" in case
of not having an exact match. Replaced it with the proper check.
Author: Martin Steghöfer
Bug-Debian: http://bugs.debian.org/716353
--- a/getopt.c
+++ b/getopt.c
@@ -109,7 +109,8 @@
opti = i;
if (arglen == strlen(opt[i].name)) break; /* exact match, stop now */
}
- if (nmatch > 1 && arglen != strlen(opt[i].name))
+ if (nmatch > 1 // got several prefix matches
+ && i == nopts) // with none of them being an exact match
Die("Option \"%s\" is ambiguous; please be more specific.\n%s",
argv[optind], usage);
if (nmatch == 0)
Bug#749136: jellyfish: FTBFS with clang instead of gcc
Hi Andreas! El 04/10/14 a les 19:41, Andreas Tille ha escrit: In the case of Jellyfish I guess the best thing is to migrate to latest upstream version. That sounds like a good idea in general. It won't solve the clang issue, though. I commited the packaging to Git - however, it needs https://github.com/gmarcais/yaggo which needs to be packaged first. Sorry I can't be of any help there. I have no clue about ruby packaging. For the record: The patch has been merged into upstream git (https://github.com/gmarcais/Jellyfish/pull/21) and will therefore be part of the next Release v2.1.5 - which could take a while to be published. Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716540: Status of netcdf (Was: Bug#716540: [Mayhem] Bug report on minc-tools: minccopy crashes with exit status 139)
El 06/10/14 a les 09:57, Andreas Tille ha escrit:
there exists a patch for an issue in netcdf and a changelog entry [...] in Git
about a new version.
Thanks for pointing out the work that has been started on packaging a
new version!
I'd like to add that there has just been a new upstream beta release
4.3.3-rc2. We might want to package that (or the final 4.3.3 release or
the current git snapshot which is probably almost the final 4.3.3)
instead of a snapshot from several months ago. It's probably more stable.
In any case, both the snapshot that has been used to start the packaging
work in the Debian-med repository as well as the recent upstream beta
release contain partial fixes of the problem addressed in my patch. They
fix 2 of the 3 issues with the URI parsing. I submitted the fix of the
3rd issue to upstream [1] (maybe it will even make it into the 4.3.3
release) and attach the updated patch here in 2 versions, one that
applies cleanly to the snapshot in the Debian-Med repository
[malformed-uri-crash-snapshot-debian-med.patch] and another one that
applies cleanly to upstream's git HEAD and the 4.3.3-rc2 beta release
[malformed-uri-crash-4.3.3-rc2.patch].
Cheers,
Martin
[1] https://github.com/Unidata/netcdf-c/pull/84
Description: Fix checks for malformed URIs to avoid crashes
The functions nc_uriparse and ocuriparse caused a segmentation
fault when called on malformed URIs like "http:/". This was due
to a logical error in the parsing code.
Author: Martin Steghöfer
Bug-Debian: http://bugs.debian.org/757884
Forwarded: https://github.com/Unidata/netcdf-c/pull/84
--- a/libdispatch/ncuri.c
+++ b/libdispatch/ncuri.c
@@ -188,7 +188,7 @@ ncuriparse(const char* uri0, NCURI** durip)
{THROW(6); /* illegal protocol*/}
/* skip // */
-if(p[0] != '/' && p[1] != '/')
+if(p[0] != '/' || p[1] != '/')
{THROW(7);}
p += 2;
--- a/oc2/ocuri.c
+++ b/oc2/ocuri.c
@@ -186,7 +186,7 @@ ocuriparse(const char* uri0, OCURI** durip)
{THROW(6); goto fail; /* illegal protocol*/}
/* skip // */
-if(p[0] != '/' && p[1] != '/')
+if(p[0] != '/' || p[1] != '/')
{THROW(7); goto fail;}
p += 2;
--
1.9.1
Description: Fix checks for malformed URIs to avoid crashes
The functions nc_uriparse and ocuriparse caused a segmentation
fault when called on malformed URIs like "http:/". This was due
to a logical error in the parsing code.
Author: Martin Steghöfer
Bug-Debian: http://bugs.debian.org/757884
Forwarded: https://github.com/Unidata/netcdf-c/pull/84
--- a/libdispatch/ncuri.c
+++ b/libdispatch/ncuri.c
@@ -169,7 +169,7 @@ ncuriparse(const char* uri0, NCURI** durip)
{THROW(6); goto fail; /* illegal protocol*/}
/* skip // */
-if(p[0] != '/' && p[1] != '/')
+if(p[0] != '/' || p[1] != '/')
{THROW(7); goto fail;}
p += 2;
--- a/oc2/ocuri.c
+++ b/oc2/ocuri.c
@@ -169,7 +169,7 @@ ocuriparse(const char* uri0, OCURI** durip)
{THROW(6); goto fail; /* illegal protocol*/}
/* skip // */
-if(p[0] != '/' && p[1] != '/')
+if(p[0] != '/' || p[1] != '/')
{THROW(7); goto fail;}
p += 2;
Bug#763989: xdrawchem hangs when doing "Undo"
Package: xdrawchem Version: 2.0-2 Severity: normal Hi there! Under certain circumstances (which actually happen a lot) xdrawchem hangs when doing "Undo" (be it via the Menu or via Ctrl+Z, it doesn't matter) and has to be killed. It seems that the hang always happens when the "Undo" operation would lead to a non-empty worksheet (meaning: almost always!). Once hung, the program uses 100% CPU load of one core. Steps to reproduce: * Start up xdrawchem. * Add 2 lines by doing the following: * Activate the line tool by clicking on the icon depicting a straight, continuous line in the toolbar (tooltip text: "Draw Line"). * Draw a line on the worksheet. * Draw a second line on the worksheet. (It doesn't matter, if it's connected to the first line or not.) * Undo the last action by clicking the menu "Edit" -> "Undo" * Verify that the GUI doesn't respond any longer. Terminal output between clicking "Undo" and hanging: 4 PAGESIZE: "PAGE_LETTER" PAGEORIENT: "PAGE_PORTRAIT" DP::AtomID: "a0" DP::SetCoordFromXML: "74 100" DP::SetColorFromXML: "0 0 0" DP::SetFontFromXML: "Helvetica#12" "Helvetica" * "12" DP::SetElementFromXML: "C" DP::SetElementMaskFromXML: " " DP::AtomID: "a1" DP::SetCoordFromXML: "99 100" DP::SetColorFromXML: "0 0 0" DP::SetFontFromXML: "Helvetica#12" "Helvetica" * "12" DP::SetElementFromXML: "C" DP::SetElementMaskFromXML: " " " a0 a1 1 0 1 0 0 0 " GetColorFromXML: "0 0 0" Compiling Qt and xdrawchem both with DEB_BUILD_OPTIONS="noopt nostrip" I was able to get meaningful stacktraces. As the thread is still active (but probably in an infinite loop), those stacktraces vary, a "typical" one looks like this (from #4 on below they are always identical, the frames #0 to #3 may be different in other cases): #0 0x75517ac5 in _int_free (av=, p=, have_lock=0) at malloc.c:4087 #1 0x7635f7b8 in QString::free (d=0xcd1cc0) at tools/qstring.cpp:1235 #2 0x0042aae5 in QString::~QString (this=0x7fffc880, __in_chrg=) at /usr/include/qt4/QtCore/qstring.h:880 #3 0x004a33be in ChemData::load_native (this=0xc8f020, wholefile=...) at xdrawchem/chemdata_xdc.cpp:105 #4 0x004977fe in ChemData::Undo (this=0xc8f020) at xdrawchem/chemdata_edit.cpp:183 #5 0x005072ff in Render2D::Undo (this=0xb027d0) at xdrawchem/render2d.cpp:650 #6 0x00429289 in ApplicationWindow::Undo (this=0xa62c90) at xdrawchem/application.cpp:1945 #7 0x0053e432 in ApplicationWindow::qt_static_metacall (_o=0xa62c90, _c=QMetaObject::InvokeMetaMethod, _id=18, a=0x7fffcc70) at .moc/moc_application.cpp:225 #8 0x7642d87a in QMetaObject::activate (sender=sender@entry=0xc7d800, m=m@entry=0x7773cde0 , local_signal_index=local_signal_index@entry=1, argv=argv@entry=0x7fffcc70) at kernel/qobject.cpp:3539 #9 0x76c8ca62 in QAction::triggered (this=this@entry=0xc7d800, _t1=false) at .moc/release-shared/moc_qaction.cpp:276 #10 0x76c8e433 in QAction::activate (this=0xc7d800, event=event@entry=QAction::Trigger) at kernel/qaction.cpp:1257 #11 0x76c8e58c in QAction::event (this=, e=) at kernel/qaction.cpp:1183 #12 0x76c92e2c in QApplicationPrivate::notify_helper (this=this@entry=0x80d360, receiver=receiver@entry=0xc7d800, e=e@entry=0x7fffcf10) at kernel/qapplication.cpp:4567 #13 0x76c994a0 in QApplication::notify (this=0x7fffdda0, receiver=0xc7d800, e=0x7fffcf10) at kernel/qapplication.cpp:4353 #14 0x764194dd in QCoreApplication::notifyInternal (this=0x7fffdda0, receiver=0xc7d800, event=event@entry=0x7fffcf10) at kernel/qcoreapplication.cpp:953 #15 0x76cc42a6 in sendEvent (event=0x7fffcf10, receiver=) at ../../include/QtCore/../../src/corelib/kernel/ qcoreapplication.h:231 #16 QShortcutMap::dispatchEvent (this=this@entry=0x80d488, e=e@entry=0x7fffd210) at kernel/qshortcutmap.cpp:887 #17 0x76cc43dc in QShortcutMap::tryShortcutEvent (this=0x80d488, o=o@entry=0xb027d0, e=e@entry=0x7fffd210) at kernel/qshortcutmap.cpp:367 #18 0x76c9a773 in QApplication::notify (this=0x7fffdda0, receiver=0xb027d0, e=0x7fffd210) at kernel/qapplication.cpp:3991 #19 0x764194dd in QCoreApplication::notifyInternal (this=0x7fffdda0, receiver=receiver@entry=0xb027d0, event=event@entry=0x7fffd210) at kernel/qcoreapplication.cpp:953 #20 0x76c91556 in sendSpontaneousEvent (event=event@entry=0x7fffd210, receiver=receiver@entry=0xb027d0) at ../../include/QtCore/../../src/corelib/kernel/ qcoreapplication.h:234 #21 qt_sendSpontaneousEvent (receiver=receiver@entry=0xb027d0, event=event@entry=0x7fffd210) at kernel/qapplication.cpp:5565 #22 0x76d32027 in QKeyMapper::sendKeyEvent (keyWidget=keyWidget@entry=0xb027d0, grab=grab@entry=false, type=QEve
Bug#716616: mincconcat crash detected by Mayhem - Patch forwarded
Patch has been forwarded to upstream and merged:
https://github.com/BIC-MNI/minc-tools/pull/15
Please find attached a new version of the patch containing the
"Forwarded" tag with the above URL.
Cheers,
Martin
Description: Fix crash in mincconcat when header cannot be expanded
This patch fixes a segmentation fault that occurs when an input file
indicates compression (e.g. by having an extension ".bz2", ".gz",
etc.), but doesn't really contain data in the corresponding
compression format. In this case, exit with an error message instead
of just crashing.
Author: Martin Steghöfer
Bug-Debian: http://bugs.debian.org/716616
Forwarded: https://github.com/BIC-MNI/minc-tools/pull/15
--- a/progs/mincconcat/mincconcat.c
+++ b/progs/mincconcat/mincconcat.c
@@ -701,6 +701,10 @@
/* Expand the file header and open the file */
filename = miexpand_file(first_filename, NULL, TRUE, &created_tempfile);
+ if (!filename) {
+ fprintf(stderr, "Could not expand file \"%s\"!\n", first_filename);
+ exit(EXIT_FAILURE);
+ }
input_mincid = miopen(filename, NC_NOWRITE);
if (created_tempfile) {
(void) remove(filename);
