@phillipgessert
Quote:
Originally Posted by phillipgessert
It's the official, I haven't installed those recent test builds.
|
It is a Chrome thread segfaulting in our Sigil URLInterceptorRequest where it asks the Qt fir a list of all its topLevelWindows.
That should not be crashing. So my guess is Monterey is sandboxing the Chrome/Qt and preventing it from accessing the main process.
That is new. This may be a new GateKeeper thing.
Please try the following in Terminal.app
(assuming Applications is where Sigil is:
cd /Applications
ls -a@lR ./ Sigil.app
Do you see anything about com.apple.quarantine in the output?
If so, you should try the following:
- download a fresh copy of Sigil.app-1.9.0-Mac.txz from our releases.
- do not unpack it, instead drag and drop it on your Desktop
- open Terminal.app and run the following:
cd
cd Desktop
xattr -d com.apple.quarantine ./Sigil.app-1.9.0-Mac.txz
Then unpack it to its Sigil.app on your Desktop and return to your Terminal.app session from above and run:
xattr -r -d com.apple.quarantine ./Sigil.app
when that is done you can close Terminal and drag and drop Sigil.app into /Applications
Then try recreating the crash.
Also, please post any other Crash Reports you get.
I can not recreate this on any of my boxes. I just can not figure out how the main thread was in Find & Replace at the exact same time the ChromeIO thread was in the URLInterceptor (in the middle of loading a link).
I also found this QTBUG bug that shows similar behaviour:
https://bugreports.qt.io/browse/QTBUG-83482
In it Qt does not check if w is non-null before trying to access its methods. Even current Qt code handles it that way. If this ends up being the problem we will create our own version of Qt's topLevelWidgets() if we see that same issue in your other CrashReports.
Hopefully if a fix is needed, we can squeeze it into Sigil-1.9.1