Vorbis issueshttps://gitlab.xiph.org/xiph/vorbis/-/issues2017-04-08T10:58:44Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/582[PATCH] Problem during book initialisation2017-04-08T10:58:44ZFelix Leder[PATCH] Problem during book initialisation```
The following situation can occur in _vds_shared_init (block.c) at line 224.
When calling vorbis_book_init_decode (sharedbook.c, l. 318) with a
static_codebook which has all lengthlist = 0, blocks with a size of 0 bytes are
allocated...```
The following situation can occur in _vds_shared_init (block.c) at line 224.
When calling vorbis_book_init_decode (sharedbook.c, l. 318) with a
static_codebook which has all lengthlist = 0, blocks with a size of 0 bytes are
allocated. The behaviour of malloc/calloc in that case is "implementation
dependant".
Most "implementations" return a pointer. Then everything works fine. BUT if you
have an implementation (e.g. TI DSPs) that returns NULL in case of a
calloc/malloc(0) either a segmentation fault is produced or data from memory
position 0 on is overwritten. Neither is wanted.
This overwriting happens in _book_unquantize (sharedbook.c, l. 183) in line 215
and possibly in line 235.
A fix is to replace lines 204 & 225 in this file:
< if((sparsemap && b->lengthlist[j]) || !sparsemap){
------------------
> if(b->lengthlist[j]){
This bug may be related to bug #340
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/581configure script ignores all the --with-ogg* options2017-04-08T10:58:44Zgorlikconfigure script ignores all the --with-ogg* options```
If there is a ogg version on the system configure will find it and ignore the --
with-ogg , --with-ogg-includes , --with-ogg-libraries options.
This prevents cross compiling on any system that has native ogg installed.
system detail...```
If there is a ogg version on the system configure will find it and ignore the --
with-ogg , --with-ogg-includes , --with-ogg-libraries options.
This prevents cross compiling on any system that has native ogg installed.
system details:
debian testing kernel 2.6.8-alpha and 2.6.9-i386
libvorbis-1.1.0
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/580divide by zero error2017-04-08T10:58:44Zjohnhdivide by zero error```
Encountered div by zero exception in bark_noise_hybridmp() in PSY.C caused by
the statement: D = tN * tXX - tX * tX; (don't know which one, there are 4
instances). When I prevented R = (A + x * B) / D; from being calculated if D ==
0...```
Encountered div by zero exception in bark_noise_hybridmp() in PSY.C caused by
the statement: D = tN * tXX - tX * tX; (don't know which one, there are 4
instances). When I prevented R = (A + x * B) / D; from being calculated if D ==
0, all was ok & the resultant OGG file could still be played (used winAmp).
Built v1.1 of ogg, vorbis, vorbisenc & vorbisfile with borland c++ builder v6 &
tested with builds of oggenc & oggdec on this dev. platform. Have emailed the
offending WAV file to Mike Smith - was generated by using directSound (v9) audio
capture api. Problem also occurred on a WAV decoded from an MP3 using LAME.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/577[PATCH] segfault in ov_time_seek()2017-04-08T10:59:27Zi.danihelka[PATCH] segfault in ov_time_seek()```
There seems to be bug in libvorbisfile.
The bug is in lib/vorbisfile.c in function ov_time_seek().
The variable "link" can have value -1 when is passed to expression
"vf->vi[link].rate".
The for cycle ends when (link == -1) or (seco...```
There seems to be bug in libvorbisfile.
The bug is in lib/vorbisfile.c in function ov_time_seek().
The variable "link" can have value -1 when is passed to expression
"vf->vi[link].rate".
The for cycle ends when (link == -1) or (seconds >= time_total).
This could leaves variable link with value -1.
This happends when functions is called with seconds = 0.0
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/572alloca() is not portable2017-04-08T10:58:44Zjohnathanalloca() is not portable```
All calls to function "alloca()" should be removed as this function is machine
specific and not supported on all platforms or all compilers (ie. MPW for
Macintosh does not support this functionality). Even the man page for alloca()
...```
All calls to function "alloca()" should be removed as this function is machine
specific and not supported on all platforms or all compilers (ie. MPW for
Macintosh does not support this functionality). Even the man page for alloca()
states that use of this function is inadvisable.
Thanks.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/566Freeze/infinite loop on old test file2017-04-08T10:59:27ZkcarnoldFreeze/infinite loop on old test file```
I found the attached file among some old experimentation I was doing with
peeling. (Actually, the original was larger, but 20k of it was enough to
trigger the problem.) I tried to play it with ogg123, but it hits an infinite
loop ...```
I found the attached file among some old experimentation I was doing with
peeling. (Actually, the original was larger, but 20k of it was enough to
trigger the problem.) I tried to play it with ogg123, but it hits an infinite
loop (in ov_open, I'll guess, from where it stopped). ogginfo says:
Negative granulepos on vorbis stream outside of headers. This file was created
by a buggy encoder
I'm marking this "major" because it happens reliably with such small data.
Hopefully it's reproducable on others' systems; if not, I can help debug. This
is the vorbis-tools Debian package, though, and it works very reliably on
everything else.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/557oggenc outputs 7s to stderr2017-04-08T10:58:44ZKyungjoon Leeoggenc outputs 7s to stderr```
Oggenc outputs lots of 7s to stderr when encoding. It still appears even when -Q
is active.
Here's a partial hexdump -C of the redirected output.
00000000 37 20 37 20 37 20 37 20 37 20 37 20 37 20 37 20 |7 7 7 7 7 7 7 7 |
*
``````
Oggenc outputs lots of 7s to stderr when encoding. It still appears even when -Q
is active.
Here's a partial hexdump -C of the redirected output.
00000000 37 20 37 20 37 20 37 20 37 20 37 20 37 20 37 20 |7 7 7 7 7 7 7 7 |
*
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/552if tell_func not implemented, seek_func called infinitely2017-04-08T10:59:27ZJack Moffittif tell_func not implemented, seek_func called infinitely```
In the course of testing the vorbisfile-python module, I noticed that if
tell_func is not implemented, then seek_func is called infinitely. A minor bug,
but the error logic in vorbisfile should probably catch coorner cases like thes...```
In the course of testing the vorbisfile-python module, I noticed that if
tell_func is not implemented, then seek_func is called infinitely. A minor bug,
but the error logic in vorbisfile should probably catch coorner cases like these.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/551vorbisfile documentation incomplete2017-04-08T11:08:16ZJack Moffittvorbisfile documentation incomplete```
missing all the _lap() functions, ov_read_float() etc.
``````
missing all the _lap() functions, ov_read_float() etc.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/527nightly snapshots not being built2017-04-08T11:08:16ZGhost Usernightly snapshots not being built```
since the server move (and possibly since the move to svn) the nightly
snapshots/builds haven't been generated.
Please sort out what all the expected links are and post them to this bug. Then
we can get them going again and possibly...```
since the server move (and possibly since the move to svn) the nightly
snapshots/builds haven't been generated.
Please sort out what all the expected links are and post them to this bug. Then
we can get them going again and possibly consolidate/rationalize a bit. Should
these all move to xiph.org? everything but icecast?
apparently there were icecast nightlies at http://xiph.org/~brendan/
```https://gitlab.xiph.org/xiph/vorbis/-/issues/517CVS vorbis/doc/v-comment.html doesn't match Vorbis_I_spec.html2017-04-08T11:08:16ZKyungjoon LeeCVS vorbis/doc/v-comment.html doesn't match Vorbis_I_spec.html```
At around line 1150 of http://xiph.org/ogg/vorbis/doc/Vorbis_I_spec.html#vorbis-
spec-comment it says that the 1.0 release of libvorbis sets the vendor string
to "Xiph.Org libVorbis I 20020717".
Meanwhile, around line 43 of CVS vor...```
At around line 1150 of http://xiph.org/ogg/vorbis/doc/Vorbis_I_spec.html#vorbis-
spec-comment it says that the 1.0 release of libvorbis sets the vendor string
to "Xiph.Org libVorbis I 20020717".
Meanwhile, around line 43 of CVS vorbis/doc/v-comment.html it says "Libvorbis
currently sets the vendor string to "Xiph.Org libVorbis I 20020717"
```Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/vorbis/-/issues/515bad m4 syntax with automake 1.8.x2017-04-08T10:58:44ZGitlab Botbad m4 syntax with automake 1.8.x```
people who have automake 1.8.x would see warnings like :
/usr/share/aclocal/vorbis.m4:9: warning: underquoted definition of XIPH_PATH_VORBIS
when running any ./autogen.sh
AC_DEFUN(XIPH_PATH_VORBIS,
should be
AC_DEFUN([XIPH_PATH_...```
people who have automake 1.8.x would see warnings like :
/usr/share/aclocal/vorbis.m4:9: warning: underquoted definition of XIPH_PATH_VORBIS
when running any ./autogen.sh
AC_DEFUN(XIPH_PATH_VORBIS,
should be
AC_DEFUN([XIPH_PATH_VORBIS],
then, automake would be silent
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/507line 95, typo: filed -> field2017-04-08T11:08:16ZKyungjoon Leeline 95, typo: filed -> field```
In line 95 of v-comment.html in CVS vorbis/doc/v-comment.html and
http://www.xiph.org/ogg/vorbis/doc/v-comment.html there is a typo.
> Below is a proposed, minimal list of standard filed names with a
filed -> field
``````
In line 95 of v-comment.html in CVS vorbis/doc/v-comment.html and
http://www.xiph.org/ogg/vorbis/doc/v-comment.html there is a typo.
> Below is a proposed, minimal list of standard filed names with a
filed -> field
```https://gitlab.xiph.org/xiph/vorbis/-/issues/505Compilation error with define INVSQ2EXP_LOOKUP_MIN2017-04-08T10:58:44ZjskinnerCompilation error with define INVSQ2EXP_LOOKUP_MIN```
File "lookup_data.h" line 71:
#define INVSQ2EXP_LOOKUP_MIN -32
should be changed to
#define INVSQ2EXP_LOOKUP_MIN (-32)
The value for INVSQ2EXP_LOOKUP_MIN should be in brackets because it is
negative... otherwise the compile...```
File "lookup_data.h" line 71:
#define INVSQ2EXP_LOOKUP_MIN -32
should be changed to
#define INVSQ2EXP_LOOKUP_MIN (-32)
The value for INVSQ2EXP_LOOKUP_MIN should be in brackets because it is
negative... otherwise the compiler pukes in "lookup.c" on line 43:
return INVSQ2EXP_LOOKUP[a-INVSQ2EXP_LOOKUP_MIN];
The preprocessor changes that to:
return INVSQ2EXP_LOOKUP[a--32];
and pukes on the double minus signs.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/500vorbis.m4:9: warning: underquoted definition of XIPH_PATH_VORBIS2017-04-08T10:58:44Zalexander.winstonvorbis.m4:9: warning: underquoted definition of XIPH_PATH_VORBIS```
Automake-1.8 complains that vorbis.m4 has an underquoted definition of
XIPH_PATH_VORBIS. According to
<http://mail.gnu.org/archive/html/libtool-patches/2002-10/msg00031.html>, these
are known to cause problems and possibly even sever...```
Automake-1.8 complains that vorbis.m4 has an underquoted definition of
XIPH_PATH_VORBIS. According to
<http://mail.gnu.org/archive/html/libtool-patches/2002-10/msg00031.html>, these
are known to cause problems and possibly even severer errors in the future.
Therefore, I am attaching a patch that quotes XIPH_PATH_VORBIS.
```https://gitlab.xiph.org/xiph/vorbis/-/issues/497Vorbis_I_spec.html needs updating2017-04-08T11:08:16ZKyungjoon LeeVorbis_I_spec.html needs updating```
http://xiph.org/ogg/vorbis/doc/Vorbis_I_spec.html is outdated. On line 2166, it
mentions the old MIME type:
The correct MIME type of any Ogg file is <tt class="literal">application/x-
ogg</tt>.
CVS vorbis/doc/xml/a1-encapsulation_o...```
http://xiph.org/ogg/vorbis/doc/Vorbis_I_spec.html is outdated. On line 2166, it
mentions the old MIME type:
The correct MIME type of any Ogg file is <tt class="literal">application/x-
ogg</tt>.
CVS vorbis/doc/xml/a1-encapsulation_ogg.xml and
http://xiph.org/ogg/vorbis/doc/vorbis-ogg.html are up-to-date.
```https://gitlab.xiph.org/xiph/vorbis/-/issues/493ov_read_float segfaults on oggflac streams2017-04-08T10:59:27Zjwmov_read_float segfaults on oggflac streams```
As ov_read doesn't check logical streams after the first, it's possible to
feed ov_read_float a physical stream that contains a non-vorbis logical stream
(such as ogg encapsulated flac). Rather than returning OV_EBADLINK, it will
...```
As ov_read doesn't check logical streams after the first, it's possible to
feed ov_read_float a physical stream that contains a non-vorbis logical stream
(such as ogg encapsulated flac). Rather than returning OV_EBADLINK, it will
segfault.
As ov_read_float and ov_read are similar, I expect the same applies for
ov_read.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/491example code error?2020-06-23T16:36:31ZBill Nottinghamexample code error?```
Originally filed in Red Hat's bugzilla by d.binderman@virgin.net:
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Description of problem:
I just tried to compile package libvorbis-1_0-8 from Fedora...```
Originally filed in Red Hat's bugzilla by d.binderman@virgin.net:
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Description of problem:
I just tried to compile package libvorbis-1_0-8 from Fedora.
The compiler said
1.
seeking_example.c(142): remark #592: variable "pos" is used before
its value is set
seeking_example.c(163): remark #592: variable "pos" is used before
its value is set
seeking_example.c(190): remark #592: variable "pos" is used before
its value is set
I've checked the source code, and I agree with the compiler. This
code would benefit from rework.
Version-Release number of selected component (if applicable):
libvorbis-1_0-8
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/480another segfault in libvorbis (triggered by CVS ices2 this time)2017-04-08T10:58:44Zgtgbranother segfault in libvorbis (triggered by CVS ices2 this time)```
Here's the backtrace. Please see bug #479 for a detailed description about my
system, the malloc.conf stuff etc.
#0 0x21d0298 in local_book_besterror (book=0x3c0e6bc8, a=0x3c2017a8)
at /usr/ports/mystuff/audio/libvorbis/w-libv...```
Here's the backtrace. Please see bug #479 for a detailed description about my
system, the malloc.conf stuff etc.
#0 0x21d0298 in local_book_besterror (book=0x3c0e6bc8, a=0x3c2017a8)
at /usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/res0.c:341
341 *a++ -= *ptr++;
#1 0x21d0320 in _encodepart (opb=0x3c05ad6c, vec=0x3c2017a8, n=32,
book=0x3c0e6bc8, acc=0x0)
at /usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/res0.c:354
354 int entry=local_book_besterror(book,vec+i*dim);
#2 0x21d0c6e in _01forward (vb=0x3c05ad68, vl=0x3c0d8900, in=0x3c035bb4, ch=1,
partword=0x3c2011a8, encode=0x21d02c0 <_encodepart>)
at /usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/res0.c:578
578 ret=encode(&vb->opb,in[j]+offset,samples_per_partition,
#3 0x21d16e5 in res2_forward (vb=0x3c05ad68, vl=0x3c0d8900, in=0x3c037c14,
out=0x0, nonzero=0x3c037c04, ch=2, partword=0x3c2011a8)
at /usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/res0.c:806
#4 0x21d3309 in mapping0_forward (vb=0x3c05ad68) at
/usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/mapping0.c:631
#5 0x21c407b in vorbis_analysis (vb=0x3c05ad68, op=0x0) at
/usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/analysis.c:47
#6 0x1c008c13 in encode_dataout (s=0x3c05ac00, og=0x3c037e7c) at
/usr/ports/mystuff/net/ices2/w-ices-2.0-Beta2-debug/ices-2.0-Beta2/src/encode.c:
213
#7 0x1c008366 in reencode_page (s=0x3c01e000, buf=0x3c006340,
outbuf=0x3c037ee8, outlen=0x3c037ee4)
at /usr/ports/mystuff/net/ices2/w-ices-2.0-Beta2-debug/ices-2.
0-Beta2/src/reencode.c:220
#8 0x1c009f04 in process_and_send_buffer (sdsc=0x3c012980, buffer=0x3c006340)
at /usr/ports/mystuff/net/ices2/w-ices-2.0-Beta2-debug/ices-2.
0-Beta2/src/stream_shared.c:121
#9 0x1c0069bb in ices_instance_stream (arg=0x3c012980) at
/usr/ports/mystuff/net/ices2/w-ices-2.0-Beta2-debug/ices-2.0-Beta2/src/stream.c:
254
#10 0x1c00e5ee in _start_routine (arg=0x3c00c4f0) at
/usr/ports/mystuff/net/ices2/w-ices-2.0-Beta2-debug/ices-2.
0-Beta2/src/thread/thread.c:655
#11 0xc38dcbd in _thread_start ()
#12 0x1f in ?? ()
Cannot access memory at address 0xffffffff.
Again, if I can help with more info, like certain variable/pointer values,
please let me know. I'll keep binary and coredumps.
Moritz
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/479ogg123 segfaults, backtrace hints to libvorbis2017-04-08T10:58:44Zgtgbrogg123 segfaults, backtrace hints to libvorbis```
After a while of listening to a Vorbis stream, ogg123 became "sick" and the
input buffer was hovering around 0.5-1%. A little later, during a song change,
it segfaulted. Here's the backtrace:
#0 0xdbae358 in decode_packed_entry_n...```
After a while of listening to a Vorbis stream, ogg123 became "sick" and the
input buffer was hovering around 0.5-1%. A little later, during a song change,
it segfaulted. Here's the backtrace:
#0 0xdbae358 in decode_packed_entry_number (book=0x3c0ce3c8, b=0x3c076a48)
at /usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/codebook.c:345
345 if(book->dec_codelengths[lo]<=read){
#1 0xdbae128 in vorbis_book_decodevv_add (book=0x3c0ce3c8, a=0xcfbfcc0c,
offset=416, ch=2, b=0x3c076a48, n=32)
at /usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/codebook.c:460
460 entry = decode_packed_entry_number(book,b);
#2 0xdbaaa31 in res2_inverse (vb=0x3c076a44, vl=0x3c013a40, in=0xcfbfcc0c,
nonzero=0xcfbfcbfc, ch=2)
at /usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/res0.c:859
859 if(vorbis_book_decodevv_add(stagebook,in,
#3 0xdbac7d8 in mapping0_inverse (vb=0x3c076a44, l=0x3c09b000)
at /usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/mapping0.c:702
#4 0xdb9d706 in vorbis_synthesis (vb=0x3c076a44, op=0xcfbfcd24)
at /usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/synthesis.c:76
#5 0xa53eb8f in _fetch_and_process_packet (vf=0x3c076800, op_in=0x0, readp=1,
spanp=1)
at /usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/vorbisfile.c:484
#6 0xa541a1f in ov_read (vf=0x3c076800, buffer=0x3c005fa0 "ยก", length=3072,
bigendianp=0, word=2, sgned=1, bitstream=0x3c076ac8)
at /usr/ports/mystuff/audio/libvorbis/w-libvorbis-1.0.1-debug/libvorbis-1.0.
1/lib/vorbisfile.c:1545
#7 0x1c007417 in ovf_read (decoder=0x3c013540, ptr=0x3c005fa0, nbytes=3072,
eos=0xcfbfce8c, audio_fmt=0xcfbfcea0) at oggvorbis_format.c:139
#8 0x1c006ec2 in play (
source_string=0x3c013480 "http://pandora.hrz.tu-chemnitz.de:8000/kolaradio.
ogg") at ogg123.c:525
#9 0x1c006b81 in main (argc=2, argv=0xcfbfcfb4) at ogg123.c:389
#10 0x1c0035a1 in ___start ()
#11 0x1c003517 in __start ()
#12 0xcfbfd100 in ?? ()
The icecast server in charge was -kh10 from Karl Heyes, which also had problems
(something about NULL pointers, I think we/he could find the problem and fix it)
... so it is possible that the server sent some junk to ogg123, however, I
believe that this is no valid reason for ogg123 or the vorbis libs to segfault.
The issue might be quite subtle since I compiled everything with certain
malloc() settings in malloc.conf for testing. The options I use are 'AGZ'. From
malloc.conf(3):
<snip>
A ``Abort''. malloc() will coredump the process, rather than tol-
erate failure. This is a very handy debugging aid, since the
core file will represent the time of failure, rather than when
the null pointer was accessed.
[...]
G Enable guard pages and chunk randomization. Each page size or
larger allocation is followed by a guard page that will cause a
segmentation fault upon any access. Smaller than page size
chunks are returned in a random order.
(this is unique to OpenBSD, as far as I know)
[...]
Z ``Zero''. Fill some junk into the area allocated (see J), except
for the exact length the user asked for, which is zeroed.
[...]
The J and Z flags are mostly for testing and debugging. If a program
changes behavior if either of these options are used, it is buggy.
The default cache size is 16 pages.
</snip>
Please let me know if I can help with further gdb output. The OS I am using is a
very recent version of OpenBSD 3.4-current on i386.
Moritz
```Monty MontgomeryMonty Montgomery