"Internal Server Error" when trying to load the information for a build

[ajburley]

When loading the information for a build, sometimes I get an internal server error. For example 4.0-732 works but 4.0-722 gives an Internal Server Error. I want to open the information for a build so I can find out what commit it corresponds to. Can someone look into this?

[KHg8m3r]

I don't know how you did it, but you managed to grab the single most fucked up build number to test.

On the Dolphin master branch download page where build 4.0-722 currently resides, you will see the numbers go backward from 752, 750, 748, 722, 721, 721, 746, 744, 741, 735, 733, 732, 722, 720, 719.

So the error stems from two issues:
The first is that the first time 722 was used was an actual build here and the second time here was a revert of some change. Somehow the buildbot reused a number.
The second issue is how you're looking for builds. When you type in https://dolphin-emu.org/download/dev/master/4.0-732/ to pull up a build, you run the risk of looking for a build number that might not be there. In which case you should get the "Page not found" response from the server (like say if you typed in https://dolphin-emu.org/download/dev/master/4.0-723/ ).

The only true way to prevent this issue is to do a search of the commit number.
First 722: https://dolphin-emu.org/download/dev/fab...e2160dde1/
Second 722: https://dolphin-emu.org/download/dev/f28...849ae3dea/

I had to go back to pages 219/220 to figure this out.

edit: the same issue happen if you look for build 721
edit2: don't end a url command with [/b]

[ajburley]

I don't know how you did it, but you managed to grab the single most fucked up build number to test.

On the Dolphin master branch download page where build 4.0-722 currently resides, you will see the numbers go backward from 752, 750, 748, 722, 721, 721, 746, 744, 741, 735, 733, 732, 722, 720, 719.

So the error stems from two issues:
The first is that the first time 722 was used was an actual build here and the second time here was a revert of some change. Somehow the buildbot reused a number.
The second issue is how you're looking for builds. When you type in https://dolphin-emu.org/download/dev/master/4.0-732/ to pull up a build, you run the risk of looking for a build number that might not be there. In which case you should get the "Page not found" response from the server (like say if you typed in https://dolphin-emu.org/download/dev/master/4.0-723/ ).

The only true way to prevent this issue is to do a search of the commit number.
First 722: https://dolphin-emu.org/download/dev/fab...e2160dde1/
Second 722: https://dolphin-emu.org/download/dev/f28...849ae3dea/

I had to go back to pages 219/220 to figure this out.

edit: the same issue happen if you look for build 721
edit2: don't end a url command with [/b]

Hi KHg8m3r,

I didn't deliberately grab a screwed up build number; I was trying to diagnose an issue in Dolphin and used the Dolphin Bisection Tool to do it. DBT reported to me that my issue was caused at some point between 4.0-722 and 4.0-732.

If 4.0-722 refers to the later build with that number, then this is a false positive, because that 4.0-722 actually comes after 4.0-732.

I don't have the commit number for the build I used and neither does DBT. All we know is that the "last" build which worked for me was the build located here:

http://dl.dolphin-emu.org/builds/dolphin...722-x64.7z

It is not clear to me if this artifact represents the original 4.0-722 or the later 4.0-722. Is there any way to find out?

If I had the commit number then I would definitely be searching using that. But I don't have it, and in fact the commit number is one of the things I'm looking for which is why I'm trying to open the build page on the Dolphin website, to find that out.

I looked back through the downloads history and verified everything you said but this still doesn't help me to know which build I actually have. Both the old and the new 4.0-722 build point to the same artifact when the download link is clicked (URL given above). But only one of them can be correct!

PS: I'm a contributor for DBT and once I resolve this I would be submitting a PR or at the very least an issue record to fix this in DBT itself.

[JosJuice]

If you open the About dialog in the Dolphin build you have, it will tell you the commit hash (labeled "revision") close to the top.

[KHg8m3r]

I'm surprised you've managed to pinpoint an error to the most messed up range in Dolphin's build numbers

If the error is between the first 722 and 732, then I don't think the build tool will help you since there's no build inbetween them. If it's between the second 722 and 732, then you may have more luck

[ajburley]

Thanks to both for your help!!

I did some more investigation into this.

By checking the "about" window:

4.0-721 build is the second 4.0-721 build on Dolphin's downloads page
4.0-722 build is the second 4.0-722 build on Dolphin's downloads page

The first 4.0-721 build has a commit hash that is not even known to GitHub. Presumably, the commit existed once, but was totally nuked from the repository at some point. However, the first and second 4.0-721 builds have identical commit messages, so the first and second 4.0-721 builds were likely almost the same.

4.0-721 was released after 4.0-746, but 4.0-721 is actually a fork of 4.0-720. This explains the version number. I imagine the build tool just checks the commit's parent and gets its build number, then increments it by the number of files changed in that commit.

4.0-722 (the second one) was released just after 4.0-721, and actually is just a revert of the changes made in 4.0-721 (second). That means that theoretically 4.0-720 and 4.0-722 are identical builds (except for the build/version number). So when DBT reported my Dolphin last worked in 4.0-722 (the build), actually it last worked in 4.0-720, as the build it is quoting as 4.0-722 is identical to 4.0-720.

This is significant because previously I'd been going crazy trying to work out why something broke between 4.0-722 (the original one) and 4.0-732, when all the changes I could see were Android-only changes and I'm on Windows. But now I know actually it broke between 4.0-720 and 4.0-732, which makes more sense as the commit made immediately before the original 4.0-722 (but after 4.0-720) appears much more likely to be related to my issue.

Meanwhile the second (/stored) 4.0-721 and 4.0-722 builds are actually not included in the ancestry chain of any modern release. If you followed the ancestry chain back far enough, you would see they (the modern releases) were based on 4.0-748, which is based on 4.0-746, based on ....... based on 4.0-732, which is based on the original (no longer available) 4.0-722 build, based on 4.0-720, etc. 4.0-721 and the second 4.0-722 would be nowhere to be seen. For the second 4.0-722 at least, this doesn't really matter though, as that build is identical to 4.0-720 as noted above, and 4.0-720 itself most certainly is in the ancestry chain.

(Note also that the second 4.0-721 and the second 4.0-722 have commit hashes that are displayed on GitHub but not actually stored in the git repository. These hashes will appear to be invalid objects when viewed in any clone of the GitHub repository. Someone on Stack Overflow has suggested that this probably happened because the underlying commits for 4.0-721(second) and 4.0-722(second) were under review, then made available through web access, then the review withdrawn without being approved.)





Having said all that, I still think that https://dolphin-emu.org/download/dev/master/4.0-721/ and https://dolphin-emu.org/download/dev/master/4.0-722/ should not trigger "internal server error"s. They should show information for the published and available builds for those two version numbers, which are basically the second of the two commits for each of the respective versions.