FLTK logo

Re: [fltk/fltk] FLTK crashes on Apple M1 (Issue #373)

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.issues  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: [fltk/fltk] FLTK crashes on Apple M1 (Issue #373) "Pierre Ossman (Work account)" Jan 19, 2022  
 

Alright, so we've gotten a bit further. We've seen the crash once on x86 now as well. But just once. So it seems to happen more often on M1, but is not exclusive to that platform.

A crash dump can be found here for those interested:

https://community.thinlinc.com/t/thinlinc-4-14-0-beta/288/2

It's not too helpful though as it seems it crashes way after the issue has been triggered.

The path we investigated was instead these warnings that we got whenever a FLTK binary was run under lldb:

2022-01-19 12:24:11.563263+0100 unittests[2853:668914] [unittests] CGContextRestoreGState: invalid context 0x600003711080. If you want to see the backtrace, please set CG_CONTEXT_SHOW_BACKTRACE environmental variable.
2022-01-19 12:24:11.563284+0100 unittests[2853:668914] [unittests] CGContextRestoreGState: invalid context 0x600003711080. If you want to see the backtrace, please set CG_CONTEXT_SHOW_BACKTRACE environmental variable.
2022-01-19 12:24:11.563293+0100 unittests[2853:668914] [unittests] CGContextFlush: invalid context 0x600003711080. If you want to see the backtrace, please set CG_CONTEXT_SHOW_BACKTRACE environmental variable.

Googling it unfortunately gave mostly hits that this was false errors on some version of iOS. But one place mentioned that this could be because drawing is done outside of drawRect:.

A second clue was enabling CG_CONTEXT_SHOW_BACKTRACE. It unfortunately didn't give us a full trace, but it did tell us the calling function which was Fl_X::q_release_context().

So we did some more tracing and discovered that the graphics context was grabbed from the system in drawRect:, but it was released much later, outside of drawRect:. It seems those cleanup calls are enough to trigger the issues.

Next step was seeing if things would work better if we made sure the context is released before drawRect: returns. And apparently it already. Provided you have a recent enough SDK. Which we don't have, since we're stuck on an ancient one (for various practical reasons).

Moving that line so it is always included seems to fix the bug. We're still testing as this thing is a bit random. It does get rid of the complaints you get via lldb though.

diff --git a/src/Fl_cocoa.mm b/src/Fl_cocoa.mm
index 3ce77f95b..c3b7b8abe 100644
--- a/src/Fl_cocoa.mm
+++ b/src/Fl_cocoa.mm
@@ -2474,8 +2475,8 @@ static FLTextInputContext* fltextinputcontext_instance = nil;
       CGImageRelease(img);
     }
   }
-  Fl_X::q_release_context();
 #endif
+  Fl_X::q_release_context();
   if (!through_Fl_X_flush) window->clear_damage();
   through_drawRect = NO;
   fl_unlock_function();

This was tested with the current state of the 1.3 branch. From what I can tell 1.4 still has the same code though.


Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.Message ID: <fltk/fltk/issues/373/1016407907@github.com>

Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.