Vorbis issueshttps://gitlab.xiph.org/xiph/vorbis/-/issues2019-01-28T23:01:57Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2327vorbisfile free of uninitialized memory if seek fails2019-01-28T23:01:57ZGitlab Botvorbisfile free of uninitialized memory if seek failsIn vorbisfile.c, it is possible for ov_raw_seek to free some uninitialized memory (and therefore crash) if seek fails. I attach a patch to fix this bug.
This was originally discovered by an SFML user in this bug, and I investigated it a...In vorbisfile.c, it is possible for ov_raw_seek to free some uninitialized memory (and therefore crash) if seek fails. I attach a patch to fix this bug.
This was originally discovered by an SFML user in this bug, and I investigated it a bit more:
https://github.com/SFML/SFML/issues/1241Thomas DaedeThomas Daedehttps://gitlab.xiph.org/xiph/vorbis/-/issues/2271vorbis git repository missing release markers2017-11-01T04:49:44ZJacob Lifshayvorbis git repository missing release markersThe vorbis git repository should have branches or tags to indicate which commits are the releases. This makes it difficult to use as a submodule.The vorbis git repository should have branches or tags to indicate which commits are the releases. This makes it difficult to use as a submodule.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2230ov_raw_total() ignores the size of the last page2017-11-01T04:49:44ZMartin Steghöferov_raw_total() ignores the size of the last page[The maintainers of the Debian package "libogg-vorbis-decoder-perl" discovered](https://bugs.debian.org/801610) that the return value of `ov_raw_total()` with `i<0` changed after we (the Debian libvorbisfile maintainers) backported the u...[The maintainers of the Debian package "libogg-vorbis-decoder-perl" discovered](https://bugs.debian.org/801610) that the return value of `ov_raw_total()` with `i<0` changed after we (the Debian libvorbisfile maintainers) backported the upstream commit r19165. That change breaks one of their test cases. The same behavior can also be observed in the unpatched 1.3.5 release.
Indeed, their test case seems to be correct and the new libvorbisfile3 version returns an incorrect value. 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 only logical bitstream in the file. 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.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2221vorbis_comment_add_tag() crash: very large alloca()2017-11-01T04:49:44Zi80andvorbis_comment_add_tag() crash: very large alloca()While transcoding several MP3s via GStreamer on OSX with libvorbis 1.3.5, I encountered a consistent segmentation fault in vorbis_comment_add_tag().
GStreamer passes a very large "contents" argument for these files. vorbis_comment_add_t...While transcoding several MP3s via GStreamer on OSX with libvorbis 1.3.5, I encountered a consistent segmentation fault in vorbis_comment_add_tag().
GStreamer passes a very large "contents" argument for these files. vorbis_comment_add_tag() allocates the comment using alloca(), resulting in a stack overflow.
Replacing alloca() with _ogg_malloc() (and adding a corresponding _ogg_free()) resolves the crash.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2218psy.c: warning C4305: '=' : truncation from 'double' to 'float'2017-11-01T04:49:44Zirov13psy.c: warning C4305: '=' : truncation from 'double' to 'float'```
p->m_val = 1.;
if(rate < 26000) p->m_val = 0;
else if(rate < 38000) p->m_val = .94; /* 32kHz */
else if(rate > 46000) p->m_val = 1.275; /* 48kHz */
```
pls add .f
```
p->m_val = 1.f;
if(rate < 26000) p->m_val = 0.f;
...```
p->m_val = 1.;
if(rate < 26000) p->m_val = 0;
else if(rate < 38000) p->m_val = .94; /* 32kHz */
else if(rate > 46000) p->m_val = 1.275; /* 48kHz */
```
pls add .f
```
p->m_val = 1.f;
if(rate < 26000) p->m_val = 0.f;
else if(rate < 38000) p->m_val = .94f; /* 32kHz */
else if(rate > 46000) p->m_val = 1.275f; /* 48kHz */
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2203infer issues on libvorbis2017-11-01T04:49:44ZGhost Userinfer issues on libvorbisFacebook's infer static analysis tool complains about some possible null dereferences in libvorbis and libvorbisfile:
Starting analysis (Infer version git-4526ada822d01728c4ac0ac30fd2f9a2aa115c0f)
Analysis done
22 files analyzed
lib/...Facebook's infer static analysis tool complains about some possible null dereferences in libvorbis and libvorbisfile:
Starting analysis (Infer version git-4526ada822d01728c4ac0ac30fd2f9a2aa115c0f)
Analysis done
22 files analyzed
lib/block.c:110: error: NULL_DEREFERENCE
pointer link last assigned on line 108 could be null and is dereferenced at line 110, column 7
lib/codebook.c:152: error: NULL_DEREFERENCE
pointer s last assigned on line 151 could be null and is dereferenced at line 152, column 3
lib/floor0.c:79: error: NULL_DEREFERENCE
pointer info last assigned on line 78 could be null and is dereferenced at line 79, column 3
lib/floor0.c:139: error: NULL_DEREFERENCE
pointer *look->linearmap[W] last assigned on line 134 could be null and is dereferenced at line 139, column 7
lib/floor0.c:153: error: NULL_DEREFERENCE
pointer look last assigned on line 149 could be null and is dereferenced at line 153, column 3
lib/floor1.c:123: error: NULL_DEREFERENCE
pointer info last assigned on line 121 could be null and is dereferenced at line 123, column 3
lib/floor1.c:191: error: NULL_DEREFERENCE
pointer look last assigned on line 186 could be null and is dereferenced at line 191, column 3
lib/floor1.c:745: error: NULL_DEREFERENCE
pointer output last assigned on line 741 could be null and is dereferenced at line 745, column 7
lib/floor1.c:968: error: NULL_DEREFERENCE
pointer fit_value last assigned on line 966 could be null and is dereferenced at line 968, column 5
lib/info.c:60: error: NULL_DEREFERENCE
pointer vc->comment_lengths last assigned on line 58 could be null and is dereferenced at line 60, column 3
lib/mdct.c:66: error: NULL_DEREFERENCE
pointer T last assigned on line 54 could be null and is dereferenced at line 66, column 5
lib/psy.c:41: error: NULL_DEREFERENCE
pointer look last assigned on line 39 could be null and is dereferenced at line 41, column 3
lib/res0.c:200: error: NULL_DEREFERENCE
pointer info last assigned on line 197 could be null and is dereferenced at line 200, column 3
lib/res0.c:268: error: NULL_DEREFERENCE
pointer look last assigned on line 262 could be null and is dereferenced at line 268, column 3
lib/res0.c:430: error: NULL_DEREFERENCE
pointer partword last assigned on line 422 could be null and is dereferenced at line 430, column 5
lib/res0.c:496: error: NULL_DEREFERENCE
pointer partword last assigned on line 489 could be null and is dereferenced at line 496, column 3
lib/res0.c:790: error: NULL_DEREFERENCE
pointer work last assigned on line 785 could be null and is dereferenced at line 790, column 7
lib/vorbisfile.c:199: error: NULL_DEREFERENCE
pointer *serialno_list last assigned on line 196 could be null and is dereferenced at line 199, column 3
lib/vorbisfile.c:2324: error: NULL_DEREFERENCE
pointer vi last assigned on line 2321 could be null and is dereferenced at line 2324, column 7
lib/vorbisfile.c:2385: error: NULL_DEREFERENCE
pointer vi last assigned on line 2382 could be null and is dereferenced at line 2385, column 7
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2142_initial_pcmoffset uses error codes from vorbis_packet_blocksize in arithmetics2017-11-01T04:49:44ZMartin Steghöfer_initial_pcmoffset uses error codes from vorbis_packet_blocksize in arithmeticsWhile working on #2140, I realized that the function `_initial_pcmoffset` doesn't handle negative values (error codes) returned by `vorbis_packet_blocksize` properly. It simply uses the returned value in an arithmetic expression, regardl...While working on #2140, I realized that the function `_initial_pcmoffset` doesn't handle negative values (error codes) returned by `vorbis_packet_blocksize` properly. It simply uses the returned value in an arithmetic expression, regardless the sign - which leads to an incorrect result. In change, the functions `ov_raw_seek` and `ov_pcm_seek` seem to skip the current packet, if `vorbis_packet_blocksize` returns a negative value.
In the comments of #2140, tterribe suggested a fix that I'm attaching as patch, but couldn't test yet.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2140"Null pointer dereference" [forwarded from Debian #774516]2017-11-01T04:49:44ZMartin Steghöfer"Null pointer dereference" [forwarded from Debian #774516]I'm forwarding the bug 774516 (https://bugs.debian.org/774516) from the Debian bug tracker, so I can discuss with you the fix I'd propose.
----
Original report from Jakub Wilk <jwilk@debian.org>:
Package: vorbis-tools
Version: 1.4.0-6...I'm forwarding the bug 774516 (https://bugs.debian.org/774516) from the Debian bug tracker, so I can discuss with you the fix I'd propose.
----
Original report from Jakub Wilk <jwilk@debian.org>:
Package: vorbis-tools
Version: 1.4.0-6
Usertags: afl
Both oggdec and ogg123 crash on the attached file, trying to dereference
null pointer:
$ oggdec crash.ogg
oggdec from vorbis-tools 1.4.0
Segmentation fault
$ ogg123 crash.ogg
Audio Device: Advanced Linux Sound Architecture (ALSA) output
Segmentation fault
Backtrace:
#0 0xf7f925a8 in vorbis_packet_blocksize (vi=0x804d2f0, op=0xffff910c) at synthesis.c:168
#1 0xf7fb6b4d in _initial_pcmoffset (vf=0xffff92cc, vi=0x804d2f0) at vorbisfile.c:440
#2 0xf7fb8ec0 in _open_seekable2 (vf=0xffff92cc) at vorbisfile.c:625
#3 0xf7fb9117 in _ov_open2 (vf=0xffff92cc) at vorbisfile.c:941
#4 ov_open_callbacks (f=0x804d020, vf=0xffff92cc, initial=0x0, ibytes=0, callbacks=...) at vorbisfile.c:997
#5 0x0804977a in decode_file (in=0x804d020, out=0xffff9098, out@entry=0x804d188, infile=0xffffd88d "crash.ogg", outfile=0x804d008 "crash.wav") at oggdec.c:265
#6 0x08048d5f in main (argc=2, argv=0xffffd6b4) at oggdec.c:455
This bug was found using American fuzzy lop:
https://packages.debian.org/experimental/afl
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages vorbis-tools depends on:
ii libao4 1.1.0-3
ii libc6 2.19-13
ii libcurl3-gnutls 7.38.0-3
ii libflac8 1.3.0-3
ii libogg0 1.3.2-1
ii libspeex1 1.2~rc1.2-1
ii libvorbis0a 1.3.4-2
ii libvorbisenc2 1.3.4-2
ii libvorbisfile3 1.3.4-2
--
Jakub WilkMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2139libvorbis-1.3.4 misdecodes streams with single-symbol codebooks2017-11-01T04:49:44ZAndrew Churchlibvorbis-1.3.4 misdecodes streams with single-symbol codebooksAccording to the Vorbis specification (https://xiph.org/vorbis/doc/Vorbis_I_spec.html), "a codebook with a single used entry ... consists of a single codework of zero bits and 'reading' a value out of such a codebook always returns the s...According to the Vorbis specification (https://xiph.org/vorbis/doc/Vorbis_I_spec.html), "a codebook with a single used entry ... consists of a single codework of zero bits and 'reading' a value out of such a codebook always returns the single used value and sinks zero bits". However, libvorbis-1.3.4 does not follow this requirement, instead sinking a nonzero number of bits (presumably the number specified in the codebook). See the attached sample file.
I will note that the reference encoder does not seem to generate single-symbol codebooks, and the specification is unclear on how they should be encoded (since the bitstream format does not allow one to specify a code length of zero bits). However, I've seen files in the wild which do in fact contain such a codebook, perhaps as a result of some sort of external codebook optimizer.
The attached "sample.ogg" file was created from "original.ogg" by modifying the codebook at index 20 (file offset 0x503 + 1 bit; 18 symbols, of which only symbol 9 of length 3 bits is used) so all unused symbols are excluded from the Huffman decision tree, then deleting the 3 bits which encoded that symbol at the two locations it was used, file offsets 0x3117 + 4 bits and 0x3402 + 6 bits.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2120CHANGES changelog for libvorbis not updated since libvorbis 1.3.32020-06-10T22:01:44ZTim SmallCHANGES changelog for libvorbis not updated since libvorbis 1.3.3The CHANGES file for libvorbis 1.3.4 (and also the version in git at the time of writing) only includes changes up to 1.3.3 - i.e. no entries for the 1.3.4 release are present.The CHANGES file for libvorbis 1.3.4 (and also the version in git at the time of writing) only includes changes up to 1.3.3 - i.e. no entries for the 1.3.4 release are present.https://gitlab.xiph.org/xiph/vorbis/-/issues/2079tagcompare() uses toupper() and is sensitive to the current locale2019-02-02T04:30:06ZDavid Kingtagcompare() uses toupper() and is sensitive to the current localeI use libvorbis in EasyTAG to read Vorbis comments from Ogg files, and came across some code that resets the locale to the C locale before calling vorbis_comment_query_count() or vorbis_comment_query(). This avoids a problem where, if th...I use libvorbis in EasyTAG to read Vorbis comments from Ogg files, and came across some code that resets the locale to the C locale before calling vorbis_comment_query_count() or vorbis_comment_query(). This avoids a problem where, if the user's locale is (for example) Turkish, the dotted lower-case i 'i' is transformed to the dotted upper-case i 'İ', rather than the expected dotless upper-case i 'I'. This causes problems for tag names with 'i' characters in the Turkish locale, and maybe there are other examples too.
It would be nice if tagcompare() used a locale-insensitive upper-casing function, so that I do not have to do this in my application (ignoring the fact that calling setlocale() in an application which uses threads is asking for trouble).Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2078Invalid memory access with samplingrate==02017-11-01T04:49:44ZMartin SteghöferInvalid memory access with samplingrate==0I am forwarding this issue from the Debian bug tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716613
The Mayhem software detected a crash when passing a specially crafted FLAC file to oggenc. I've examined the problem furthe...I am forwarding this issue from the Debian bug tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716613
The Mayhem software detected a crash when passing a specially crafted FLAC file to oggenc. I've examined the problem further and found out that the problem is that the flac reader provides an input stream with a sampling rate of 0. This is something that neither oggenc itself nor libvorbisenc can cope with. The oggenc executable crashes with SIGFPE (division by the sampling rate in the statistics => division by 0) and libvorbisenc accesses invalid memory during the initialization.
While the oggenc crash doesn't affect the usability much (there is nothing valid to encode anyway in a file with sampling rate 0), libvorbisenc's access to invalid memory has the potential to either crash the whole downstream application with SIGSEGV or even be a security issue (although my preliminary examination didn't show any sign of exploitability).
The latest versions of vorbis-tools and libvorbis (and probably many earlier versions) are affected (I'm reporting this here because these version numbers don't appear in the TRAC version dropdown):
* libvorbis: 1.3.4
* vorbis-tools: 1.4.0
Please find attached the patches that we used in Debian. They add sanity checks to both the oggenc executable and the initialization routines of libvorbis.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2062Simplify render_point2017-11-01T04:49:44ZSven EberhardtSimplify render_pointThe render_point function seems to fit a linear function through (x0,y0) and (x1,y1) and then finds y(x) on that line. It does some special case handling for y0>y1 vs y0<y1, which, as far as I can see, is unnecessary. I.e., the current c...The render_point function seems to fit a linear function through (x0,y0) and (x1,y1) and then finds y(x) on that line. It does some special case handling for y0>y1 vs y0<y1, which, as far as I can see, is unnecessary. I.e., the current code:
int dy=y1-y0;
int adx=x1-x0;
int ady=abs(dy);
int err=ady*(x-x0);
int off=err/adx;
if(dy<0)return(y0-off);
return(y0+off);
should be equivalent to this:
return (x - x0) * (y1 - y0) / (x1 - x0) + y0;
The only difference would be in some integer overflow cases, which cannot happen in this place anyway. I've tried the replacement and found no difference when encoding a test file.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2060Typos in Vorbis I specification2017-11-01T04:49:44ZstefanTypos in Vorbis I specificationWhile reading through the [Vorbis I specification](https://xiph.org/vorbis/doc/Vorbis_I_spec.pdf), I discovered two minor typos:
*Section 4.3.8*
_"window\_blocksize(previous\_window)/4+window\_blocksize(current\_window)/4"_
should read
...While reading through the [Vorbis I specification](https://xiph.org/vorbis/doc/Vorbis_I_spec.pdf), I discovered two minor typos:
*Section 4.3.8*
_"window\_blocksize(previous\_window)/4+window\_blocksize(current\_window)/4"_
should read
_"window_blocksize(previous_window)/4+window_blocksize(current_window)/4"_
(remove the backslashes)
*Section 10.1*
_"The vector [floor1_inverse_dB_table] is a 256 element static lookup table consiting of the following values (read left to right then top to bottom):"_
_"consiting"_ should read _"consisting"_
It would mean a lot to me if you have time to fix them.https://gitlab.xiph.org/xiph/vorbis/-/issues/2038Vorbis borks a pure 440Hz sine wave at the highest quality level2017-11-01T04:49:44ZArtem S. TashkinovVorbis borks a pure 440Hz sine wave at the highest quality levelA test case:
```
oggenc -q10 *wav
WARNING: quality setting too high, setting to maximum quality.
Opening with wav module: WAV file reader
Encoding "01_440hz Tone.wav" to
"01_440hz Tone.ogg"
at quality 10.00
[ 99.9%] [ 0...A test case:
```
oggenc -q10 *wav
WARNING: quality setting too high, setting to maximum quality.
Opening with wav module: WAV file reader
Encoding "01_440hz Tone.wav" to
"01_440hz Tone.ogg"
at quality 10.00
[ 99.9%] [ 0m00s remaining] /
Done encoding file "01_440hz Tone.ogg"
File length: 14m 42.0s
Elapsed time: 0m 09.2s
Rate: 95.4935
Average bitrate: 26.0 kb/s
```
Components versions:
```
$ rpm -qa | grep vorbis
libvorbis-1.3.4-2.el6.i686
libvorbis-devel-1.3.4-2.el6.i686
vorbis-tools-1.4.0-16.el6.i686
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2030Incorrect bark() formula in floor0 specification2017-11-01T04:49:44ZAndrew ChurchIncorrect bark() formula in floor0 specificationIn the current version of the Vorbis I specification, the bark() function used by floor 0 is defined as:
bark(x) = 13.1 arctan(.00074x) + 2.24 arctan(.0000000185x^2 + .0001x)
However, the formula actually used by libvorbis is:
bark(x)...In the current version of the Vorbis I specification, the bark() function used by floor 0 is defined as:
bark(x) = 13.1 arctan(.00074x) + 2.24 arctan(.0000000185x^2 + .0001x)
However, the formula actually used by libvorbis is:
bark(x) = 13.1 arctan(.00074x) + 2.24 arctan(.0000000185x^2) + .0001x
(note that the .0001x is not part of the arctan argument).
Since floor 0 seems to be considered obsolete, I suggest changing the specification to reflect the formula actually used by libvorbis.https://gitlab.xiph.org/xiph/vorbis/-/issues/1982Switched ai and hi in vorbisenc.c2017-11-01T04:49:44ZTimothy GuSwitched ai and hi in vorbisenc.cFrom l.1089-1148 in lib/vorbisenc.c, the set function set the input argument to the default, and the GET function SET the output (NULL) to the system, i.e. the GET function is actually SET and vice versa. This should be a huge bug.
I ma...From l.1089-1148 in lib/vorbisenc.c, the set function set the input argument to the default, and the GET function SET the output (NULL) to the system, i.e. the GET function is actually SET and vice versa. This should be a huge bug.
I made this bug a "major" bug. If this is not the case, just close this ticket.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1975Segfault in libvorbisenc when passing --advanced-encode-option disable_coupli...2018-04-09T18:15:00ZaeliosheotupSegfault in libvorbisenc when passing --advanced-encode-option disable_coupling to oggencRunning this command in a shell produces a segfault:
```
oggenc -b 80 --advanced-encode-option disable_coupling -o out.ogg in.wav
```
With a libvorbisenc compiled with debug symbols, here is what gdb tells:
```
(gdb) run
Starting progr...Running this command in a shell produces a segfault:
```
oggenc -b 80 --advanced-encode-option disable_coupling -o out.ogg in.wav
```
With a libvorbisenc compiled with debug symbols, here is what gdb tells:
```
(gdb) run
Starting program: /usr/bin/oggenc -b 80 --advanced-encode-option disable_coupling -o out.ogg in.wav
Ouverture avec le module wav: WAV file reader
Encodage de "in.wav"
en "out.ogg"
au dbit approximatif de 80 kbps (encodage VBR en cours)
Setting advanced encoder option "disable_coupling"
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff791dfb0 in vorbis_encode_setup_setting (vi=0x7fffffffd640, channels=2, rate=44100) at vorbisenc.c:884
(gdb) bt
#0 0x00007ffff791dfb0 in vorbis_encode_setup_setting (vi=0x7fffffffd640, channels=2, rate=44100) at vorbisenc.c:884
#1 0x00007ffff791ed14 in vorbis_encode_ctl (vi=0x7fffffffd640, number=65, arg=0x7fffffffd84c) at vorbisenc.c:1208
#2 0x0000000000407725 in set_advanced_encoder_options (vi=0x7fffffffd640, count=1, opts=<optimized out>) at encode.c:102
#3 oe_encode (opt=0x7fffffffdf70) at encode.c:348
#4 0x0000000000403666 in main (argc=<optimized out>, argv=<optimized out>) at oggenc.c:431
(gdb)
```
I can reproduce this with any wav input file.
I'm on Ubuntu 12.04 x64, with libvorbisenc 2.0.8.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1974libvorbis-1.3.3 fails to link its tests2017-11-01T04:49:44Zheireckalibvorbis-1.3.3 fails to link its testsWhen building the tests for libvorbis-1.3.3 linking fails with the error below.
With the attached patch everything works fine.
```
make[1]: Entering directory `/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/C/64/test'
x86_64-p...When building the tests for libvorbis-1.3.3 linking fails with the error below.
With the attached patch everything works fine.
```
make[1]: Entering directory `/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/C/64/test'
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/test -I.. -I/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/include -Wall -Wextra -ffast-math -D_REENTRANT -fsigned-char -Wdeclaration-after-statement -march=native -pipe -O2 -floop-block -floop-interchange -floop-strip-mine -DUSE_MEMORY_H -c /var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/test/util.c
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/test -I.. -I/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/include -Wall -Wextra -ffast-math -D_REENTRANT -fsigned-char -Wdeclaration-after-statement -march=native -pipe -O2 -floop-block -floop-interchange -floop-strip-mine -DUSE_MEMORY_H -c /var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/test/write_read.c
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/test -I.. -I/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/include -Wall -Wextra -ffast-math -D_REENTRANT -fsigned-char -Wdeclaration-after-statement -march=native -pipe -O2 -floop-block -floop-interchange -floop-strip-mine -DUSE_MEMORY_H -c /var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/test/test.c
make test
make[2]: Entering directory `/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/C/64/test'
/bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -Wall -Wextra -ffast-math -D_REENTRANT -fsigned-char -Wdeclaration-after-statement -march=native -pipe -O2 -floop-block -floop-interchange -floop-strip-mine -DUSE_MEMORY_H -o test util.o write_read.o test.o ../lib/libvorbisenc.la ../lib/libvorbis.la -logg
Dequant test 1... OK
Dequant test 2... OK
Dequant test 3... OK
Dequant test 4... OK
Dequant test 5... OK
/bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -Wall -Wextra -ffast-math -D_REENTRANT -fsigned-char -Wdeclaration-after-statement -march=native -pipe -O2 -floop-block -floop-interchange -floop-strip-mine -DUSE_MEMORY_H -o test util.o write_read.o test.o ../lib/libvorbisenc.la ../lib/libvorbis.la -logg
libtool: link: x86_64-pc-linux-gnu-gcc -Wall -Wextra -ffast-math -D_REENTRANT -fsigned-char -Wdeclaration-after-statement -march=native -pipe -O2 -floop-block -floop-interchange -floop-strip-mine -DUSE_MEMORY_H -o .libs/test util.o write_read.o test.o ../lib/.libs/libvorbisenc.so ../lib/.libs/libvorbis.so /usr/lib64/libogg.so
make[2]: Leaving directory `/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/C/64/test'
util.o:util.c:function gen_windowed_sine: error: undefined reference to 'sin'
util.o:util.c:function gen_windowed_sine: error: undefined reference to 'cos'
collect2: error: ld returned 1 exit status
make[2]: *** [test] Error 1
make[1]: *** [check-am] Error 2
make[1]: *** Waiting for unfinished jobs....
Error:
* In program cave perform install --hooks --managed-output --output-exclusivity with-others =media-libs/libvorbis-1.3.3-r1:0::media --destination installed --replacing =media-libs/libvorbis-1.3.3-r1:0::installed --x-of-y 1 of 1:
* When installing 'media-libs/libvorbis-1.3.3-r1:0::media' replacing { 'media-libs/libvorbis-1.3.3-r1:0::installed' }:
* When running an ebuild command on 'media-libs/libvorbis-1.3.3-r1:0::media':
* Install failed for 'media-libs/libvorbis-1.3.3-r1:0::media' (paludis::ActionFailedError)
libtool: link: x86_64-pc-linux-gnu-gcc -Wall -Wextra -ffast-math -D_REENTRANT -fsigned-char -Wdeclaration-after-statement -march=native -pipe -O2 -floop-block -floop-interchange -floop-strip-mine -DUSE_MEMORY_H -o .libs/test util.o write_read.o test.o ../lib/.libs/libvorbisenc.so ../lib/.libs/libvorbis.so /usr/lib64/libogg.so
make[1]: Leaving directory `/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/C/64/test'
util.o:util.c:function gen_windowed_sine: error: undefined reference to 'sin'
util.o:util.c:function gen_windowed_sine: error: undefined reference to 'cos'
collect2: error: ld returned 1 exit status
make[1]: *** [test] Error 1
make: *** [check-recursive] Error 1
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1969Out of bounds index in psy.c2017-11-01T04:49:44ZTony WilsonOut of bounds index in psy.cV1.0.1..1.3.3
In function _vp_psy_init halfoc is limited to P_BANDS - 1 but later used +0 and +1
My guess is it should be P_BANDS - 2
Picked up when I recently translated the example enc/dec subset of ogg and vorbis to Google's Go as a...V1.0.1..1.3.3
In function _vp_psy_init halfoc is limited to P_BANDS - 1 but later used +0 and +1
My guess is it should be P_BANDS - 2
Picked up when I recently translated the example enc/dec subset of ogg and vorbis to Google's Go as a "learn 2 things at once" exercise.Monty MontgomeryMonty Montgomery