Created attachment 372941 [details] Crash report generated by MacOS when GnuCash crashed Since I just installed the "latest stable" version, and haven't even entered transactions yet, this seems a crash worth reporting. Attached is the crash report that automatically popped up with the "Send to Apple" option, but obviously this should go to the GnuCash developers more than to Apple. This is running GnuCash 3.2 on MacOS 10.11.6; full details in attachment. All I've done so far is create some accounts (a few days ago), left GnuCash open the last few days, and created one more account today. I believe just before the crash I right-clicked on one of the accounts in the list, but it could have been something else equally innocuous.
Hmm, looks like the stack got trashed and tried to jump to an invalid address. Is it at all reproducible?
(In reply to John Ralls from comment #1) > Hmm, looks like the stack got trashed and tried to jump to an invalid > address. Is it at all reproducible? Unfortunately, looks like yes. I left GnuCash open for several hours today after I created some more accounts (and still haven't entered any transactions). Just now when I got your comment, I right-clicked on an account in the list and it crashed again. I'll attach the second crash report.
Created attachment 372942 [details] Second crash report
That one's better, the bad address wasn't in the stack space so it didn't get whacked. Looks like GnuCash's (really Gtk's) monitor array is somehow getting corrupted. Do you have an auxiliary monitor? Are you running GnuCash fullscreen? Do you use Spaces? The crash report said that time-since-sleep was 43000 seconds, a bit over 12 hours. Is that right? This doesn't have anything to do with what's going on in GnuCash, BTW. It's all down in the monitor-handling code in the Gtk+ graphics toolkit.
Yes, I am using an external 4K monitor over HDMI, and sometimes unplug it or plug it back in. MacOS handles scaling of the windows quite well but it wouldn't surprise me at all if this is related to the crashes. Here is the info on my displays, taken from the "System Information" app: AMD Radeon R9 M370X: Chipset Model: AMD Radeon R9 M370X Type: GPU Bus: PCIe PCIe Lane Width: x8 VRAM (Total): 2048 MB Vendor: ATI (0x1002) Device ID: 0x6821 Revision ID: 0x0083 ROM Revision: 113-C5670E-777 gMux Version: 4.0.20 [3.2.8] EFI Driver Version: 01.00.777 Displays: Color LCD: Display Type: Retina LCD Resolution: 2880 x 1800 Retina Retina: Yes Pixel Depth: 32-Bit Color (ARGB8888) Mirror: Off Online: Yes Built-In: Yes DELL U2718Q: Resolution: 2560 x 1440 @ 30 Hz Pixel Depth: 32-Bit Color (ARGB8888) Display Serial Number: 4K8X77A60H8L Main Display: Yes Mirror: Off Online: Yes Rotation: Supported Television: Yes
Well, do you remember if you'd disconnected and reconnected the external monitor between starting and crashing? Can you test to see if doing so reproduces the crash? If this is the problem I don't think that there's anything we can do about it from GnuCash, it will require a change in Gtk.
(In reply to John Ralls from comment #4) > That one's better, the bad address wasn't in the stack space so it didn't > get whacked. Looks like GnuCash's (really Gtk's) monitor array is somehow > getting corrupted. > > Do you have an auxiliary monitor? Are you running GnuCash fullscreen? Do you > use Spaces? Yes, I have an auxiliary monitor; I've just included the details in comment #5. I haven't run GnuCash fullscreen and I don't use Spaces except for having a fullscreen Terminal open most of the time. Unplugging and replugging the monitor and then right clicking didn't cause a crash all by itself. No idea what other factors are involved. If it crashes again I'll post another crash report. > The crash report said that time-since-sleep was 43000 seconds, a bit over 12 > hours. Is that right? Not sure. The number is suspiciously even. I believe my laptop was sitting on my desk for those 12 hours, plugged in to my monitor and to a power source, and I was out of the house for the most part. I would have thought it was "asleep" in that time period. > This doesn't have anything to do with what's going on in GnuCash, BTW. It's > all down in the monitor-handling code in the Gtk+ graphics toolkit. Good to know. Is GnuCash using the latest version of Gtk? I've linked to this issue from https://gitlab.gnome.org/GNOME/gtk/issues/1247 so Gtk+ developers can have a look. (I would look deeper myself if I knew C well enough.)
(In reply to John Ralls from comment #6) > Well, do you remember if you'd disconnected and reconnected the external > monitor between starting and crashing? Can you test to see if doing so > reproduces the crash? I've tried that and it didn't crash again. (I tried a few variations, such as: having GnuCash hidden while disconnecting, having it visible while disconnecting, leaving it hidden for the whole time external monitor is disconnected, or making it visible again before reconnecting.) > If this is the problem I don't think that there's anything we can do about > it from GnuCash, it will require a change in Gtk. Roger that. Anyway, I'm just setting up GnuCash for the first time; I'll keep using it and of course if I get another crash I'll try to see if I can reproduce it more deterministically and will post the crash report. (https://www.xkcd.com/242/)
We don't need any more crash reports unless there's a different stack trace. If you find a reliable way to reproduce the problem that will help a lot in debugging. Since disconnecting and reconnecting the monitor doesn't get it to reproduce, maybe sleeping it does? GnuCash 3.2 was built with Gtk+-3.22.29 because I had trouble compiling 3.22.30 on MacOS 10.9, but there weren't any changes to gdk/quartz between the two.
(In reply to John Ralls from comment #9) > We don't need any more crash reports unless there's a different stack trace. > If you find a reliable way to reproduce the problem that will help a lot in > debugging. > > Since disconnecting and reconnecting the monitor doesn't get it to > reproduce, maybe sleeping it does? Hmmm, I reproduced it two more times, but still haven't gotten a 100% reliable procedure. I experimented with different methods of putting it to sleep - setting the screensaver to a short period and waiting, setting the energy saver "turn off display" value to a short period and waiting, clicking the "show login window" option in the menu bar. The only two times I successfully produced a crash, I was using my usual method for locking the computer, which involves trigger BetterTouchTool's "Lock Screen" action. But, trying this a few more times didn't produce a crash. I suspect it was just coincidence rather than a difference in how BTT locks the computer versus other methods. Sleep does seem to be the key, though, or at least A key - in all four crashes observed thus far, the computer had been locked/asleep between the time GnuCash was started and the time it crashed.
Maybe this upstream issue is related? https://gitlab.gnome.org/GNOME/gtk/issues/1312 I had a similar crash report with the NSScreen visibleFrame method being the culprit.
Yes, it's the same stack trace, so a duplicate of Bug 796867. Although this one is a bit older there's more information over there so closing this one as the dupe. With luck I'll be able to close the other soon. *** This bug has been marked as a duplicate of bug 796867 ***
Sigh, wrong one. Bug 796879. *** This bug has been marked as a duplicate of bug 796879 ***
