flac -t claims MD5 signature unset in STREAMINFO, yet it is present? #192
Comments
|
Possibly related to issue #155. Re-enconding the file over itself does not clear the issue. |
|
Running into the same issue as well, similar number of files affected. Reencoding does not fix the issue. Can provide sample files if that helps with debugging. |
|
Also experiencing this on Fedora 32 with flac 1.3.3. |
|
I'm having the same issue. It seems to only happen when files have two zeros at the start of the MD5 signature. |
|
A |
|
I built and installed flac 1.3.0 in a clean Arch Linux container and the same error happened. I installed flac 1.3.1 from the repos in an Ubuntu xenial container and couldn't reproduce the error. This is getting a bit beyond me, but I guess the bug is caused by something that changed in gcc or glibc. The memcmp call at line 1310 of src/flac/decode.c seems to be the trigger. I found this issue on the gcc bug tracker but don't understand it enough to know if it's actually the cause. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 I tried building 1.3.3 on Arch with the optimization flag set to -O1 and that does appear to fix the issue (gcc 10.1.0-2 and glibc 2.31-5). |
|
I just noticed there's a patch for this on the Sourceforge bug tracker. It does fix the issue for me. https://sourceforge.net/p/flac/bugs/478/ Is GitHub now the preferred place to report issues? The Xiph website still links to Sourceforge but I noticed someone there being told to reopen an issue here. |
https://sourceforge.net/p/flac/bugs/478/ states that has_md5sum fails when the first byte of md5sum is zero. As reported in the linked issue and on https://bugs.gentoo.org/719792, this occurs on gcc 9 and above. Patch is authored by issue reporter from sourceforge. Closes xiph#192.
A bug in gcc versions 9.2 - 10.1 causes strings to get incorrectly stripped when passed directly to memcmp (1). This is avoided by using the FLAC__byte type, which is backwards compatible and avoids compile-time checks. This was initially reported back March of this year, and has only seen increasing bug reports due to the affected gcc versions becoming more common as gcc 9 is included in Ubuntu 19.10 and later. The initial reporter also provided a patch in the bug report (2), which is included in this PR with authorship attributed to the original reporter. (1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 (2) https://sourceforge.net/p/flac/bugs/478/ Closes xiph#192.
A bug in gcc versions 9.2 - 10.1 causes strings to get incorrectly stripped when passed directly to memcmp with a zero first byte (1). This bug causes flac -t to fail on any .flac file with a md5 checksum beginning in 00. To work around this bug, the FLAC__byte type is used for an empty md5 sum to prevent a string from being stripped, which is backwards compatible and avoids compile-time checks. This was initially reported back March of this year, but has become more prevalent with gcc 9.2 being shipped with the latest Ubuntu versions (Ubuntu 19.10 and up ship with gcc 9.2). The initial reporter also provided a patch in the bug report (2), which is included in this PR with authorship attributed to the reporter. (1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 (2) https://sourceforge.net/p/flac/bugs/478/ Closes xiph#192.
A bug in gcc versions 9.2 - 10.1 causes strings to get incorrectly stripped when passed directly to memcmp with a zero first byte (1). This bug causes flac -t to fail on any .flac file with a md5 checksum beginning in 00. To work around this bug, the FLAC__byte type is used for an empty md5 sum to prevent a string from being stripped, which is backwards compatible and avoids compile-time checks. This was initially reported back March of this year, but has become more prevalent with gcc 9.2 being shipped with the latest Ubuntu versions (Ubuntu 19.10 and up ship with gcc 9.2). The initial reporter also provided a patch in the bug report (2), which is included in this PR with authorship attributed to the reporter. (1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 (2) https://sourceforge.net/p/flac/bugs/478/ Closes xiph#192.
A bug beginning in gcc version 9.2 causes strings to get incorrectly stripped when passed directly to memcmp with a zero first byte (1). This bug causes flac -t to fail on any .flac file with a md5 checksum beginning in 00. To work around this bug, the FLAC__byte type is used for an empty md5 sum to prevent a string from being stripped, which is backwards compatible and avoids compile-time checks. This was initially reported back in March 2020, but has seen more light since Ubuntu 19.10 and up ship with gcc 9.2 as the default compiler. A patch has been merged into the master gcc branch (2), but has not been included in any versions as of this commit date. The initial reporter provided a patch in their bug report (3), which is included in this PR with authorship attributed to the reporter. (1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 (2) https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=d5803b9876b3d11c93d1a10fabb3fbb1c4a14bd6 (3) https://sourceforge.net/p/flac/bugs/478/ Closes xiph#192.
A bug beginning in gcc version 9.2 causes strings to get incorrectly stripped when passed directly to memcmp with a zero first byte (1). This bug causes flac -t to fail on any .flac file with a md5 checksum beginning in 00. To work around this bug, the FLAC__byte type is used for an empty md5 sum to prevent a string from being stripped, which is backwards compatible and avoids compile-time checks. This was initially reported back in March 2020, but has seen more light since Ubuntu 19.10 and up ship with gcc 9.2 as the default compiler. A patch has been merged into the master gcc branch (2), but has not been included in any versions as of this commit date. The initial reporter provided a patch in their bug report (3), which is included in this PR with authorship attributed to the reporter. (1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 (2) https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=d5803b9876b3d11c93d1a10fabb3fbb1c4a14bd6 (3) https://sourceforge.net/p/flac/bugs/478/ Closes #192.
I've been hitting this issue and I can't seem to pin down the cause:
Running checks it seems to appear in about one in two hundred files. It is present in
flac v1.3.{1,2}.The text was updated successfully, but these errors were encountered: