helios747 / dolphinbisecttool Goto Github PK
View Code? Open in Web Editor NEWWindows utility to automate the bisection process for issues in the Dolphin Emulator
License: GNU General Public License v3.0
Windows utility to automate the bisection process for issues in the Dolphin Emulator
License: GNU General Public License v3.0
It spits out an error when extracting the archive and I cannot continue bisecting. This can happen if the Windows build failed and doesn't exist (5.0-2409 is one such case), so this would need to be properly handled by falling back to another build.
While running DBT with first=6997 and last=9511, I got an exception:
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.
************** Exception Text **************
SevenZip.SevenZipArchiveException: Invalid archive: open/read error! Is it encrypted and a wrong password was provided?
If your archive is an exotic one, it is possible that SevenZipSharp has no signature for its format and thus decided it is TAR by mistake.
at SevenZip.SevenZipBase.ThrowException(CallbackBase handler, Exception[] e)
at SevenZip.SevenZipExtractor.OpenArchive(IInStream archiveStream, ArchiveOpenCallback openCallback)
at SevenZip.SevenZipExtractor.GetArchiveInfo(Boolean disposeStream)
at SevenZip.SevenZipExtractor.ExtractArchive(String directory)
at DolphinBisectTool.Backend.Download(String url, String major_version, Int32 version)
at DolphinBisectTool.Backend.Bisect(String boot_title)
at DolphinBisectTool.MainWindow.start_button_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
************** Loaded Assemblies **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1076.0 built by: NETFXREL3STAGE
CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
DolphinBisectTool
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///D:/Programs/Games/Platforms/Gamecube/Dolphin.Bisect.Tool/DolphinBisectTool.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1055.0 built by: NETFXREL2
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1075.0 built by: NETFXREL3STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1068.2 built by: NETFXREL3STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Configuration
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1055.0 built by: NETFXREL2
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1055.0 built by: NETFXREL2
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Xml
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1067.0 built by: NETFXREL3STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
Accessibility
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1055.0 built by: NETFXREL2
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------
SevenZipSharp
Assembly Version: 0.64.3890.29348
Win32 Version: 0.64.3890.29348
CodeBase: file:///D:/Programs/Games/Platforms/Gamecube/Dolphin.Bisect.Tool/SevenZipSharp.DLL
----------------------------------------
************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.
For example:
<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>
When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.
When testing is interrupted for any reason, it can be hard to determine which versions have been successfully tested and what the progress of the bisect is. A simple text log file showing build numbers and the user's selected result would make it easier to continue testing in the event the bisect is unexpectedly terminated early.
Hi, i try to start dolphin (yesterday work with no issue) and closes inmediately i open it, try to open again and closes again.
My windows is optimized so doesnt actualizate automatically, try with older versions and the same happened.
They're more modern (And effectively standard nowadays) game file formats offered by Dolphin that are pending support for bisecting purposes.
While bisecting it's possible to come across an unstable or otherwise a build that does not allow the bug to be tested. After closing the program, the bisect tool asks "Yes" or "no" whether the bug occurred. If the bug wasn't able to be tested this throws off the progression of the bisect. An "Unsure" option that simply ignored the results of that particular test and went on to another build would help.
the default WinForms icon sucks
DBT is currently worded to find "culprit" PRs, where a problem is introduced. Sometimes it is necessary to find "Solution" PRs that solve a problem too.
Perhaps a new menu could be added?
The PR in question:
If "Solves a problem" is selected, swap the "Select a development build that is broken" and "Select a development build that worked" labels. "GOOD" and "BAD" would need to be swapped in the log. And the message that identifies the "culprit" PR when finished should probably be changed to "solution."
For the first run Boot Title option will work. Afterwards, it produces error: "The specified file "/b" does not exist" when selecting to Start. Then Dolphin resorts to loading the usual title list. If its relevant this in the build range of 5.0-2000 to 5.0-4000. It's possible the /b option is just broken in those builds but I don't think so.
or find a way to make VS move it to External Libs
no idea whats causing this.
Delroth changed infra so that pulling index.html isn't possible anymore. A reasonable change, but this breaks DBT.
The solution is to implement support in the dolphin website to allow DBT to pull a list of builds. I have a PR for that that I need to finish. Putting this here for documentation
You can't determine a build download link from its version alone anymore:
For example, the format is no longer :
https://dl.dolphin-emu.org/builds/dolphin-master-[version]-[build]-[arch].7z
But is instead :
https://dl.dolphin-emu.org/builds/[two random hex digits]/[two random hex digits]/dolphin-master-[version]-[build]-[arch].7z
On some builds, the Dolphin filename is DolphinWX.exe, not Dolphin.exe. For example builds 298, 299, 300.
If DBT tries to start such a build, an exception is thrown as it cannot find Dolphin.exe.
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.
************** Exception Text **************
System.ComponentModel.Win32Exception (0x80004005): The system cannot find the file specified
at System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo)
at System.Diagnostics.Process.Start()
at DolphinBisectTool.RunBuild.Run(String title)
at DolphinBisectTool.Backend.Bisect(String boot_title)
at DolphinBisectTool.MainWindow.start_button_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
************** Loaded Assemblies **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1076.0 built by: NETFXREL3STAGE
CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
DolphinBisectTool
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///D:/Programs/Games/Platforms/Gamecube/DolphinBisectTool105/DolphinBisectTool.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1055.0 built by: NETFXREL2
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1075.0 built by: NETFXREL3STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1068.2 built by: NETFXREL3STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Configuration
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1055.0 built by: NETFXREL2
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1055.0 built by: NETFXREL2
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Xml
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1067.0 built by: NETFXREL3STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
Accessibility
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1055.0 built by: NETFXREL2
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------
SevenZipSharp
Assembly Version: 0.64.3890.29348
Win32 Version: 0.64.3890.29348
CodeBase: file:///D:/Programs/Games/Platforms/Gamecube/DolphinBisectTool105/SevenZipSharp.DLL
----------------------------------------
************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.
For example:
<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>
When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.
Every build that DBT downloads is marked "4.0.2" in the title bar and Help->About displays the commit hash as ...c3d4f and compiled on Nov 29 2013. Is this expected behaviour?? I feel worried that every single build downloaded by DBT is actually the stable 4.0.2, even though DBT "thinks" they are development builds.
The logic of the dropdowns are reversed. Top drop down asks for oldest version and bottom asks for newest version, but the program gives an error and expects them the other way.
Unfortunately this makes the program not work at all. I put in "Select a build before the issue occurred" -- 5.0-2690; "Select a build where you saw the issue" -- 5.0-3610. Get: "Error - Second build cannot be less than or equal to the first."
Okay, so i reverse them. Program accepts the numbers. But then it keeps testing in the range where the bug is already confirmed. (E.g., program tests 5.0-3000. Bug occurs? Yes. Then program tests 5.0-3300. It should be testing between 2690 and 3000 at that step.) It just keeps pulling confirmed buggy builds like 3400, 3500, etc..
Recently I have found several bugs in Dolphin's debugger. https://bugs.dolphin-emu.org/issues/10594 is an example.
If DBT could start builds with -d, that'd make bisecting a lot easier.
Build 4.0-722 is a bit strange.
Build 4.0-722 was originally generated as a result of a commit with parent 4.0-720, with two file changes. Subsequently, build 4.0-732 was generated as a result of a commit with parent 4.0-722, with ten file changes.
However, some time later (between builds 4.0-746 and 4.0-748), a commit was made with parent 4.0-720 with one file change. This build was therefore numbered 4.0-721, even though it came after 4.0-746. After that, another commit with one file change was made with parent 4.0-720. This build was also numbered 4.0-721 and the original 4.0-721 plus its commit ceased to exist outside of Dolphin's own database.
Now, another commit was made with a parent of (the new) 4.0-721. So this build was numbered 4.0-722 by the build tool. This overwrote the original 4.0-722, so that build is no longer available on the build server. However, the 4.0-722 commit was simply a revert of the parent 4.0-721 commit, so that this new 4.0-722 build is identical to 4.0-720. Furthermore, the two commits leading to the new 4.0-721 and the new 4.0-722 were subsequently nuked from the repository, even though they are still accessible on GitHub's database.
Since there are two builds called 4.0-721 and 4.0-722 on Dolphin's database, the Dolphin website (accessed by DBT via "dolp.in") cannot handle the situation and displays an "Internal Server Error" when trying to load the detail pages for these builds.
Numbering the first and second versions of 4.0-721/722 with "a" and "b" suffixes for clarity, the parent structure looks like this:
4.0-720 -> 4.0-722a -> 4.0-732 -> ... -> 4.0-746 -> 4.0-748 -> ... -> 5.0-xxx
\
\-> 4.0-721a
\
\-> 4.0-721b -> 4.0-722b
(NB: 4.0-721a, 4.0-721b and 4.0-722b are not ancestors of the current Dolphin versions.)
Whereas the chronological series looks like this:
4.0-720 -> 4.0-722a -> 4.0-732 -> ... -> 4.0-746 -> 4.0-721a -> 4.0-721b -> 4.0-722b -> 4.0-748 -> ... -> 5.0-xxx
The details of the builds' availability;
4.0-720, 4.0-732, 4.0-746, 4.0-748 (normal builds):
4.0-721a:
4.0-721b:
4.0-722a:
4.0-722b:
Due to the above anomalies, DBT exhibits some problems. In particular, I had an issue with Dolphin itself which was actually caused by the first Dolphin 4.0-722 (called "4.0-722a" above). DBT reported to me that the issue occurred between 4.0-722 and 4.0-732. This was confusing as the changes between 4.0-722 (the first one) and 4.0-732 were all Android changes, and I was running on Windows. The second 4.0-722 was not in the ancestry chain of 4.0-732 so it seemed DBT could not be referring to the latter build as this would not make sense. Furthermore, DBT provided me with a choice to open the details page of 4.0-722, but as mentioned above, this causes an internal server error.
Of course, what actually happened is that the build which DBT calls "4.0-722" is actually the second 4.0-722, which is identical to 4.0-720 in all but number. This is also not in the ancestry chain of 4.0-732, so it doesn't make sense to say "between 4.0-720 and 4.0-732" (or similar). Instead, the best DBT can say in this situation is that the issue occurred between 4.0-720 and 4.0-732.
Since the second 4.0-722 and both 4.0-721 builds are not in the commit ancestry chains of current Dolphin releases, it does not really make sense to include these in the bisection at all. However, if a user does get an issue (with Dolphin itself) which occurred between 4.0-720 and 4.0-732, this needs special handling. Normally, DBT assumes it has found a pair of consecutive builds which the issue occurred between, which means it's perfectly acceptable to suggest the user views the build details page for the lower numbered build. However 4.0-720 and 4.0-732 are not consecutive - it's just that the build in-between (the first 4.0-722) is no longer available on the build server and so cannot be tested. For example, DBT could display a message like:
"Your issue seemed to occur between non-consecutive builds 4.0-720 and 4.0-732. Do you want to open the build details page for 4.0-720 or the intermediate build 4.0-722?"
with two options. Of course, if the user elected to open the details page for 4,0-722, we would have to reference the build by the actual commit hash as opposed to the build number, as trying to reference by the build number triggers an internal server error as mentioned above, as the Dolphin website doesn't know which of the two 4.0-722 builds you want to load the details of.
Alternatively, we could even do a manual build of the first 4.0-722 based on the actual commit (still available in the Git repository) and make that available somewhere for DBT to pull instead of the 4.0-722 on the build server (which is basically 4.0-720 for all intents and purposes)?
I was investigating https://bugs.dolphin-emu.org/issues/10563 and verified https://dolphin-emu.org/download/dev/master/5.0-76/ is the culprit PR. DBT correctly identified 5.0-76 as the culprit in its notice message. The log however displays an incorrect PR.
If the bisect fails for whatever reason, the user can just pick up where they left off.
So the downloaded builds don't interfere with the user data.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.