Closed taschenlampe closed 2 years ago
Can you upload that file?
Sorry...I just see now that the output/log is horribly formatted, my apologies!
-> This should be it https://easyupload.io/o22962
HTTP request sent, awaiting response... 403 Forbidden
HTTP request sent, awaiting response... 200 OK
Length: 331638 (324K) [text/html]
That's ... 324 kB of HTML.
Ok...this log/output should be better to read https://justpaste.it/37o2c
I don't need another log, I need the file. You link gives me only a HTML file.
Sorry...I feel super stupid :-D This link must work
Sorry...I feel super stupid :-D This link must work
Connecting to power.ddnss.org (power.ddnss.org)|93.104.93.74|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 22020 (22K) [text/html]
HTML again
Use this:
https://power.ddnss.org/s/NNPaGW8ejnHyjSS/download/00%20-%20Monster%20Hospital%20%5BMetric%5D.mp3
On Tue, Feb 22, 2022 at 1:03 PM Max Kellermann @.***> wrote:
Sorry...I feel super stupid :-D This link https://power.ddnss.org/s/NNPaGW8ejnHyjSS must work
Connecting to power.ddnss.org (power.ddnss.org)|93.104.93.74|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 22020 (22K) [text/html]
HTML again
— Reply to this email directly, view it on GitHub https://github.com/MusicPlayerDaemon/MPD/issues/1460#issuecomment-1048068651, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH3E4VTZWFUVUL2LDIZV6LU4PFXTANCNFSM5PB2QTRA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message ID: @.***>
Thanks @ranperry, that URL works.
I can't reproduce the problem with that file, but I tried to check the backtrace; it shows a crash in id3_ucs4_length()
, but MPD never calls that function.
The second backtrace shows where it's called:
#0 id3_ucs4_length (ucs4=ucs4@entry=0x0)
at /usr/src/debug/libid3tag-0.16.1-1.2.x86_64/ucs4.c:42
#1 0x00007ffff5c4a580 in id3_compat_fixup (tag=tag@entry=0x7fffe023e540)
at /usr/src/debug/libid3tag-0.16.1-1.2.x86_64/build/compat.gperf:240
#2 0x00007ffff5c4c9a0 in v2_parse (ptr=<optimized out>)
at /usr/src/debug/libid3tag-0.16.1-1.2.x86_64/tag.c:609
#3 id3_tag_parse (length=<optimized out>, data=<optimized out>)
at /usr/src/debug/libid3tag-0.16.1-1.2.x86_64/tag.c:661
#4 id3_tag_parse (data=<optimized out>, length=<optimized out>)
at /usr/src/debug/libid3tag-0.16.1-1.2.x86_64/tag.c:629
#5 0x000055555563217a in MadDecoder::ParseId3(unsigned long, Tag*)
This is a crash deep inside libid3tag, so it's a libid3tag bug.
What puzzled me was the libid3tag version number. Version 0.16.1 - that's strange, because the latest version is 0.15.1b, released 18 years ago: https://sourceforge.net/projects/mad/files/libid3tag/
So whatever you're using, it's not libid3tag. And it's buggy.
Maybe taschenlampe uses https://github.com/tenacityteam/libid3tag - seems to be a know issue https://github.com/tenacityteam/libid3tag/issues/6
@all: Thanks for looking into that issue.
Just a little note about libid3tag, I currently use version 0.16.1-1.2 that is "officially" provided by Opensuse TW (main repo oss).
This lib got updated 2022-01-10, and my last DB-update was earlier. That would confirm skidoo23's assumption...
Cheers
Was brought here from a closed bug I filed over the same issue. While I can easily file this downstream with the maintainers and they can block this version of libid3tag - it seems like distros are under the impression that tenacity's fork is the current upstream.
I'll concede this very well may be an upstream bug, but that pointer dereference exists in 0.15 as well. At very least if they are to become the new upstream, it'd be good to get to the bottom of why this happens. Clearly there's an unexpected NULL tag pointer being passed up the stack.
I wrote the issue that @taschenlampe mentioned, ie https://github.com/tenacityteam/libid3tag/issues/6 and a tentative fix, https://github.com/tenacityteam/libid3tag/issues/7.
Git blame says the bug I issued a fix for came with 0.15.1b from the official upstream at sourceforge - but there's not much point sending fixes to a project that appears to have been abandoned for almost 2 decades, so I sent it to the tenacityteam fork which seems to have at least some attempt at maintenance and is listed as the upstream source for at least the Gentoo libid3tag package.
Downgrading libid3tag to official 0.15.1b from sourceforge should therefore not affect this issue at all, and may reintroduce others that were subsequently fixed by tenacityteam.
Expected Behavior
-> Update Database
Actual Behavior
-> Updates Database until import failes when importing a certain mp3 files.
Version
Log