Bug#821321: libvorbisfile: ov_pcm_seek wrongly returns OV_EOF or segfaults sometimes
Hi Martin, > 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? 1.3.4-3 isn't on the main server anymore, but luckily I recently learned about snapshot.debian.org. It may be old news for you, but for anyone else who may be reading this report and doesn't know about it, I fetched the following two files and rebuilt them (together with the origial libvorbis_1.3.4.orig.tar.gz from jessie). I didn't try 1.3.5 yet as I want to change as little as possible in the system. http://snapshot.debian.org/archive/debian/20151001T033412Z/pool/main/libv/libvorbis/libvorbis_1.3.4-3.dsc http://snapshot.debian.org/archive/debian/20151001T033412Z/pool/main/libv/libvorbis/libvorbis_1.3.4-3.debian.tar.xz It did indeed fix the test case, and also my real case where I found the problem. I'll do some more tests soon and report if I find more problems, but I hope not. Thanks, Frank
Bug#821321: libvorbisfile: ov_pcm_seek wrongly returns OV_EOF or segfaults sometimes
On 2016-04-18 7:31 AM, Martin Steghöfer wrote: > 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? FWIW, I can reproduce with the included example and 1.3.4-2 on debian 8, but the segfault goes away after manually installing libvorbis0a_1.3.5-3_amd64.deb from testing. I likewise doesn't reproduce with with 1.3.5 from homebrew on macos. -r
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", ));
fprintf (stderr, "%i\n", ov_pcm_seek (, 0));
fprintf (stderr, "%i\n", ov_pcm_seek (, 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() (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#821321: libvorbisfile: ov_pcm_seek wrongly returns OV_EOF or segfaults sometimes
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", ));
fprintf (stderr, "%i\n", ov_pcm_seek (, 0));
fprintf (stderr, "%i\n", ov_pcm_seek (, 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() (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
