Re: [gtk-osx-users] crash on maximize/unmaximize

[John Ralls <jralls ceridwen us>]

> On Feb 11, 2016, at 7:00 PM, Allin Cottrell <cottrell wfu edu> wrote:
>
> I've recently had a report of crashes from a user of my gtk-based app on El Capitan. The gtk version I'm 
> using is 2.24.29. I'm able to reproduce the problem myself: it seems to happen only when you maximize then 
> unmaximize a window (or maximize then use the close button). And it doesn't happen every time; I had a work 
> away at maxing and unmaxing various windows for a few minutes before I got the crash.
>
> I'm attaching the Apple problem report. Not as informative as one would like, I know, but it does seem to 
> show that the problem lies with GTK rather than in my own code. When the crash occurs I'm not doing 
> anything substantive with the app, just resizing or closing windows. The segfault occurs in the function 
> updateTrackingRect in GdkQuartzView.c.
>
> Any suggestions for a fix would be much appreciated.

No suggestions for a fix, there's not enough information. Some debugging suggestions: Make a debug build of 
libgtk-quartz and glib then see if you can crash it. If you can, the crash report will have the line number 
in updateTrackingRect that's crashing and from that you might be able to tell the variable that has the bogus 
address. Glib will write a5a5a5a5a5 into deallocated memory which will tell you if you're trying to access a 
freed block. That seems the most likely reason for that stack trace. Look at malloc(3), there are a bunch of 
environment variables you can set to help with allocation debugging; you can use them in conjunction with the 
Leaks instrument (Instruments work fine with code that wasn't built in Xcode). MallocStackLoggingNoCompact 
will create a log that you can search for the corrupted address to tell you when it was allocated and freed. 
With that you can analyze the code to see how the deallocated block is getting used and figure out if it's 
your program or something in the library, and maybe isolate the problem.

Regards,
John Ralls