Activity for Ziggy
-
Ziggy posted a comment on ticket #2192
Wow, thanks for the quick response compyx! I've done several tests and it now works great with respect to the load/save dialogs. Great work! For quickload/quicksave, I think I agree with you. They are "throwaway" files which probably shouldn't be mixed with the snapshots saved via save dialog. quicksave files are definitely loaded/saved in the user profile dir on Windows...I tested that as well just now. I'm very happy with your fix! I think we can close this ticket now if you agree!
-
Also want to add that I'm using VICE 3.10.
-
Step 2 above should read: 2) Run "x64sc -eventsnapshotdir VICE_Snapshots" Step 7 above should read: 7) Load and save snapshot file dialog shows contents of current working dir instead of "VICE_Snapshots"
-
Load and Save Snapshot File Dialog Default Directory
-
I have run several tests with the newest official VICE 3.10 release and x64sc no longer crashes with the problem reported by this ticket. This ticket can be closed.
-
Hmm, I just tried the latest version of VICE (GTK3VICE-3.9-win64-r45709) released last week and it now works fine. I ran x64sc 40+ times and it never crashed! I just tried the official version 3.9 (GTK3VICE-3.9-win64) released back in December 2024 and it crashes every 5 to 10 runs. I've been trying VICE versions released at https://github.com/VICE-Team/svn-mirror/releases every once in a while this year and no luck...the x64sc crashes continued to occur. Last time I tried it was ~2 months ago maybe....
-
I've been trying newer versions of VICE and have the same intermittent crash as described above. The latest version I just tried (GTK3VICE-3.8-win64-r45265) will occasionally log 2 additional lines after the "Unit 8: RESET" log before crashing that I didn't see before. For example, on one run where it crashed, I saw the following after "Unit 8: RESET": Warning - Sync is 1149.860 ms behind VSync: Sync reset These 2 logs don't appear all of the time. Most of the time, I just see "Unit 8: RESET" and...
-
Researched a little more. As you said, this is a "heap corruption" issue. Several discussions I found from google searches indicate this is a memory corruption issue in the application (x64sc in this case) that just show up later in ntdll.dll (or something similar). The source of the problem is somewhere else in the application. A few years ago, I was a Software Engineer working on several large programs for Linux. We had to troubleshoot problems like this all the time. Now, on Linux we had access...
-
I'm wondering if faster computers might encounter this problem more frequently if it's a timing issue. I'm running on an Intel Core i9 12900K and you said your computer is older. I'm wondering if someone else could help test this out as well on a faster computer to see. It makes sense. x64sc also crashes as frequently on my other computer (Intel Core i9 10900K). If so, it might be easier to troubleshoot this in the debugger on a faster system, etc. Just some ideas...
-
Hoping it's somehow related. Something to also think about...running with the debugger affects timing (i.e. x64sc runs slower). Thus, if this is a timing issue, it may be harder to reproduce the problem with the debugger.
-
Yes, sounds like a lot of changes between 3.7 and 3.8. Do you still have any builds stored between 3.7 and 3.8? If so, I could help test them. In other words, if you have monthly builds stored, it would help you narrow it down more as to which time frame it occurred if say it happened between March and April of that year. Just trying to help you out if I can.
-
Thanks for investigating so quickly! The Event Viewer shows a red "Error" each time x64sc crashes. The "Faulting module name" is "ntdll.dll" and the "Exception code" is "0xc0000374". It looks like every crash occurrence has that same module and exception code.
-
x64sc 3.8.x GTK3 for Windows crashes randomly at startup
1
