Sigfault scanning MAME roms #6553
Comments
|
Your backtrace is not complete... You need to press something to continue and see the full backtrace. |
|
In my limited debugging experience, the inner part is more important but ok, it's not like this is expecially hard to trigger since it reproduces 100% of the time even now when scanning the tekken4 chd. The version is the latest master, i just cloned it. |
|
Thanks. Do you know if this was always present or is it a regression? |
|
no idea but since MAME chd V5 is not older than retroarch chd support (i think), i'd guess a 'regression' caused by mame switching to v5 chds. Ie: not actually a regression, just a format change from upstream. Segfaulting is still a harsh price to pay if you're not supposed to support chd v5. If you are, it's a bigger bug. |
|
chdman says this about the chd if you don't have it: |
|
My suspicion is there is a problem in the chd v5 support and I can reproduce it with a chd file here. |
|
Where are you installing RetroArch from? To be very blunt, if you bisected this when posting this issue it wouldn't of sat untouched 17 days... It appears to be a regression between Also what flac version do you have installed? I have Git bisect revealed this commit. |
|
The retroarch testing PPA (but the local build has the same problem). My ./configure says it's picking up |
|
That bisect makes no sense... if you look at the time i opened this issue, it's much earlier than the commit at 10 april 2018, when that commit is 22 april 2018. Also i didn't build RA with that flag, unless it's set automatically. I pretty much did I suppose i can try a bisect if you give me a 'early good build' with chd v5 support for me to check... would have to fetch some revisions because i did edit: |
|
Oh, you're using another file to bisect ofc. So it might be two bugs, joy. |
|
I fixed it on my side. It should use the builtin flac by default, but will check if its found or not regardless because the builtin flac may be disabled with the make argument It will still crash with |
|
Also, if the issue still persists, sharing the contents of |
You make your repo not shallow with: You're right that the commit I bisected happened after your initial failure. I suppose there is more than one issue lurking here... I unfortunately would need to source more chd files to help test further. |
|
Did not help. Here is config.mk: edit: opps wrong |
|
I don't see anything suspicious in your |
|
Also i tried a checkout of d41ea34 (which is one of the earliest libchd commits ) and it crashed on the same place (with line drift ofc). I think it was always there. edit: wait a sec, let me retry this... edit2: uh, no it didn't now. Time to bisect. |
|
The next question is if this is something that only happens in RetroArch's libchdr code or is upstream affected too? Assuming upstream is affected, has it since been fixed? I can try to find more chd files, but since you already have affected files it may be easier for you to investigate this. Do you have any chd v5 files that are not affected? I created mine manually from segacd redump files with chdman. |
this is the bisect result. A warning: before this the chd wasn't 'scanned' (that is inserted into a playlist) but it simply didn't crash with that backtrace. I don't know if this was because RA using different rdb files at the time or something deeper. edit: or because mame games need both the chd and and the rom file to scan... or just the rom file. |
|
Well that commit is unhelpful. |
|
As for others, most of them don't have this problem. The only other here is carnevil, which has the same backtrace and has chdman: i suspect (but didn't bother to confirm) this correlates with using FLAC or not |
|
Do you notice any patterns with working and non-working chd files? With the limited number of files here the only thing I notice is the and Do the differences in |
|
carnevil and tekken4, wcombat, sscopex crash: some have a sizable flac size, some have a tiny one - scopex is only 165 hunks but still crashes. sfrushrk.chd, crash: cvsgd (capcom vs snk millennium fight something), scan: jojo, scan: hotd3 scan: etc, so it appears you're right. |
|
I'm thinking that the libchd library chokes on 'chd' which aren't 'cd chd'. Thing is, i'm not sure it needs to scan them. Remember that MAME requires a pair (rom file, chd) in order to play rom files with chds iirc. That's why the chd are in a sub directory in mame. edit: turns out that the RA Scanner doesn't even 'need' the chds in the directory to 'scan and recognize' the playlist entry. So a ugly workaround is to move the subdirectories out of the directory, scan the rom directory and move them back in. Then if you start a game that didn't scan earlier (carnevil for instance) it actually runs (probably because MAME core has its own chd implementation). This is obviously going against the spirit of the Scanner whitelisting because the most important part of the game doesn't get scanned and could very well be outdated and fail at start... but that would be a much more involved fix. Can't RA just recognize MAME chd somehow and bail out of scanning them as unneeded, since it can't actually fail the corresponding game? Unless you're willing to do both this ignoring and following mame 'roms' you find to find their corresponding chd if any, which i suppose it's a better idea to 'maintain' the whitelisting, if much much slower. |
|
I have the same issue on Ubuntu 18.04 when I scan my Mame roms directory with Libretro (git from today). If I start retroarch with --verbose I obtain: [INFO] CHD '/home/legluondunet/Autres_applications/Jeux/Emulateurs/Mame/roms/kurucham/gdl-0034.chd' crc: bf716c3e |
|
You can do it by moving the chd subdirectories out of the mame rom folder then moving them back in once the scan is done. But you may also be hit by #6699 if you have a split set because of that bug and since libretro-database is not updating the split set checksums (afaict) and that bug will make much of the scanner useless for mame. Since the alternative is the games not appearing at all, i'm not sure i should be chuffed about a bug that makes them appear with wrong metadata, but it does make it impossible to tell which game is which for a large amount of them. |
|
I'm going to close this in favor of #6353 since both you and @retro-wertz agree its basically the same and that issue is slightly older with less noise from unrelated issues. |
First and foremost consider this:
Description
A segfault occurs while scanning current MAME roms. Namely a chd of Tekken 4. I triggered this by scanning the MAME rom dir but could also trigger by scanning the 'tekken4/tef1dvd0.chd' file.
File checksum is:
md5sum tef1dvd0.chd
5ab32b5d6342c48deb7af7e8973c8216 tef1dvd0.chd
size is:
du -b tef1dvd0.chd
735896857 tef1dvd0.chd
Expected behavior
Not to crash.
Actual behavior
Steps to reproduce the bug
Bisect Results
[Try to bisect and tell us when this started happening]
Version/Commit
You can find this information under Information/System Information
Environment information
The text was updated successfully, but these errors were encountered: