Windows only - Random crash, for version 2.2

[iksi4prs]

Description
App crashes.
See more information about optional cause in discussion/comment:
#654 (reply in thread)

To Reproduce
Random.
I've noticed that after first install, it works fine for few seconds.
But trying to run app again fails, namely crash is even before first window is created (or at least before it becomes visible)

Additional Info
Logs from "Windows's events viewer"

Application: Pinta.exe CoreCLR Version: 8.0.23.53103 .NET Version: 8.0.0 Description: The process was terminated due to an unhandled exception. Exception Info: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. Stack: at GObject.Internal.Object.RemoveToggleRef(IntPtr, GObject.Internal.ToggleNotify, IntPtr) at GObject.Internal.Object.RemoveToggleRef(IntPtr, GObject.Internal.ToggleNotify, IntPtr) at GObject.Internal.ObjectMapper.Unmap(IntPtr) at GObject.Internal.ObjectHandle.ReleaseHandle() at System.Runtime.InteropServices.SafeHandle.InternalRelease(Boolean) at System.Runtime.InteropServices.SafeHandle.Finalize()

Faulting application name: Pinta.exe, version: 2.2.0.0, time stamp: 0x65410000 Faulting module name: coreclr.dll, version: 8.0.23.53103, time stamp: 0x65411660 Exception code: 0xc0000005 Fault offset: 0x00000000001e337a Faulting process id: 0x0xBC80 Faulting application start time: 0x0x1DA3F1C8D463DE9 Faulting application path: C:\Program Files\Pinta\bin\Pinta.exe Faulting module path: C:\Program Files\Pinta\bin\coreclr.dll Report Id: fa0399c5-aff9-4e9b-b43c-0b1429429ed9 Faulting package full name: Faulting package-relative application ID:

Faulting application name: Pinta.exe, version: 2.1.1.0, time stamp: 0x63c9df9f Faulting module name: KERNELBASE.dll, version: 10.0.22621.2792, time stamp: 0x3091b6fb Exception code: 0x80000003 Fault offset: 0x000000000010cd82 Faulting process id: 0x0x6A54 Faulting application start time: 0x0x1DA3F1CC7555BDF Faulting application path: C:\Program Files\Pinta\Pinta.exe Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll Report Id: 8d3cb891-26e0-42d4-943e-630d861f029b Faulting package full name: Faulting package-relative application ID:

Version
Operating System:
Windows 11 Pro
Version 22H2
OS build 22621.2861

Pinta:
Pinta 2.2, from this branch: (not all dev branch have this problem)
https://github.com/PintaProject/Pinta/actions/runs/7405489857

[cameronwhite]

For Pinta 2.2, from this branch: (not all dev branch have this problem) does that mean that you haven't hit the crashes with the regular build from the master branch?

[iksi4prs]

@cameronwhite, the first version that I used with for 2.2, with narrow toolbar for tools and scroll bar, didn't crash.
I think it was from master (all versions show 2.2 in about, without date of build or branch information).
If you have list of branches/builds that you want me to check/compare, put the urls here and I will check.

[cameronwhite]

Thanks, yeah there isn't any additional info in the About window unfortunately

I think the main one to just compare against is the regular master branch, so the latest build there is https://github.com/PintaProject/Pinta/actions/runs/7470015712
I'm still trying to figure out why I'm not hitting these crashes on my Windows machine - another user had similar reports too

[badcel]

Those things are hard to debug as you are on the mercy of the gc.

For example in debug mode or with a debugger attached the gc will behave differently.

Perhaps your machine is more beefy and the gc does not need to collect objects as frequently.

You can try to force collection but from my experience this is not guaranteed to result in collection of the wanted object.

You can try to call:

GC.Collect();
GC.WaitForPendingFinalizers();

To force collection.

[iksi4prs]

test 1: master, latest build 7470015712 (narrow toolbar with scrollbar)
result - runs fine
test 2: test branch, 7405489857 (with 2 columns toolbar)
result: surprise... runs fine about 2 minutes and then crash.
ok, at least I wrote in the subject "Random crash."
I've checked the system memory, nothing special.
A few days I wasn't able to start the app at all (exited before window was visible)
Maybe as suggested by @badcel, this is GC dependent.
I will try use it and see if crashes again, based on general system memory, or some peaks/swaps when opening more apps.

[cameronwhite]

In 13ebeda I added a --debug command line argument that runs the GC more frequently

[iksi4prs]

From what I saw, the "-debug" was added in master, but I've encountered the problem in build from branch "toolbox-layout".
Can you please merge it into https://github.com/PintaProject/Pinta/tree/fix/toolbox-layout ?
(If possible, better also to merge/rebases all other changes from master)

[cameronwhite]

Sure, I've rebased it on the latest master branch: https://github.com/PintaProject/Pinta/actions/runs/7523936006

[iksi4prs]

still getting crash in exe from 7523936006
Application: Pinta.exe CoreCLR Version: 8.0.123.58001 .NET Version: 8.0.1 Description: The process was terminated due to an unhandled exception. Exception Info: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. Stack: at GObject.Internal.Object.RemoveToggleRef(IntPtr, GObject.Internal.ToggleNotify, IntPtr) at GObject.Internal.Object.RemoveToggleRef(IntPtr, GObject.Internal.ToggleNotify, IntPtr) at GObject.Internal.ObjectMapper.Unmap(IntPtr) at GObject.Internal.ObjectHandle.ReleaseHandle() at System.Runtime.InteropServices.SafeHandle.InternalRelease(Boolean) at System.Runtime.InteropServices.SafeHandle.Finalize()

[badcel]

Perhaps an idea is to have some print to the console somewhere in the stacktrace and print the name of the class which creates the problem?

[iksi4prs]

@badcel , as you wrote it maybe issue with GC, so I don't think it will help.
I've downloaded this app just to try and use, so I don't have a dev env.
I will try to download, build and debug on my machine as soon as I can.

[badcel]

The collection happens asynchronous, so there is no way back to the creating code. But if there is a way to detect the type of the handle which gets freed it is perhaps possible to narrow down the classes which could cause the problem.

[cameronwhite]

Perhaps an idea is to have some print to the console somewhere in the stacktrace and print the name of the class which creates the problem?

Yeah I think that would be really helpful for tracking down issues 👍