Fullscreen crashes Blender on Mac OS X #46202

New Issue

Timo Takala · 2015-09-22T00:28:45+02:00

Timo Takala commented

2015-09-22 00:28:45 +02:00

Mac OS X, 10.9.5
MacBook Pro
with external display (crashes without too)

Broken: 2.76 RC1 & 2.76 hash: 034cc85 (buildbot Sept. 21)
Worked: 2.75a

Blender crashes on entering (or exiting) fullscreen mode.

I tried this a few times. Sometimes I am able to enter fullscreen mode, but get a crash on exit. If I load factory settings I am able to switch to fullscreen mode and back once, but crash on the next try. Also, It seems that if I press the hotkey Alt-F11 (or, since I'm on a laptop, Fn-Alt-F11) I'm more likely to get a crash than if I use the window menu option.

Mac OS X, 10.9.5 MacBook Pro with external display (crashes without too) Broken: 2.76 RC1 & 2.76 hash: 034cc85 (buildbot Sept. 21) Worked: 2.75a Blender crashes on entering (or exiting) fullscreen mode. I tried this a few times. Sometimes I am able to enter fullscreen mode, but get a crash on exit. If I load factory settings I am able to switch to fullscreen mode and back once, but crash on the next try. Also, It seems that if I press the hotkey Alt-F11 (or, since I'm on a laptop, Fn-Alt-F11) I'm more likely to get a crash than if I use the window menu option.

Timo Takala commented

2015-09-22 00:28:45 +02:00

Changed status to: 'Open'

Timo Takala commented

2015-09-22 00:28:45 +02:00

Added subscriber: @Timo-1

blender-admin commented

2015-09-22 00:28:45 +02:00

#46261 was marked as duplicate of this issue

Brecht Van Lommel commented

2015-09-22 11:16:38 +02:00

Added subscribers: @ideasman42, @brecht

Brecht Van Lommel commented

2015-09-22 11:16:38 +02:00

@ideasman42, this seems to be happening since 3056add though the underlying problem is older.

* thread #1: tid = 0x54abf, 0x00000001010cd887 blender`BLI_remlink(listbase=0x0000000104f34ba8, vlink=0x00000001159b3e88) + 71 at listbase.c:113, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x00000001010cd887 blender`BLI_remlink(listbase=0x0000000104f34ba8, vlink=0x00000001159b3e88) + 71 at listbase.c:113
   110
   111 		if (link == NULL) return;
   112
-> 113 		if (link->next) link->next->prev = link->prev;
   114 		if (link->prev) link->prev->next = link->next;
   115
   116 		if (listbase->last == link) listbase->last = link->prev;
(lldb) bt all
* thread #1: tid = 0x54abf, 0x00000001010cd887 blender`BLI_remlink(listbase=0x0000000104f34ba8, vlink=0x00000001159b3e88) + 71 at listbase.c:113, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x00000001010cd887 blender`BLI_remlink(listbase=0x0000000104f34ba8, vlink=0x00000001159b3e88) + 71 at listbase.c:113
    frame #1: 0x0000000100017235 blender`wm_event_do_handlers(C=0x0000000104f00228) + 2277 at wm_event_system.c:2503
    frame #2: 0x000000010000b86e blender`WM_main(C=0x0000000104f00228) + 30 at wm.c:487
    frame #3: 0x0000000100006f10 blender`main(argc=1, argv=0x00007fff5fbff710) + 1504 at creator.c:1935
    frame #4: 0x0000000100006924 blender`start + 52

Recursive calls to wm_event_do_handlers() means the same event gets handled and freed twice. I think BLI_remlink(&win->queue, event); should be moved to the start of the loop to avoid that, but then the last event before quitting Blender always leaks.

I can look into it further this evening but feel free to fix it before that.

@ideasman42, this seems to be happening since 3056add though the underlying problem is older. ``` * thread #1: tid = 0x54abf, 0x00000001010cd887 blender`BLI_remlink(listbase=0x0000000104f34ba8, vlink=0x00000001159b3e88) + 71 at listbase.c:113, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x00000001010cd887 blender`BLI_remlink(listbase=0x0000000104f34ba8, vlink=0x00000001159b3e88) + 71 at listbase.c:113 110 111 if (link == NULL) return; 112 -> 113 if (link->next) link->next->prev = link->prev; 114 if (link->prev) link->prev->next = link->next; 115 116 if (listbase->last == link) listbase->last = link->prev; (lldb) bt all * thread #1: tid = 0x54abf, 0x00000001010cd887 blender`BLI_remlink(listbase=0x0000000104f34ba8, vlink=0x00000001159b3e88) + 71 at listbase.c:113, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) * frame #0: 0x00000001010cd887 blender`BLI_remlink(listbase=0x0000000104f34ba8, vlink=0x00000001159b3e88) + 71 at listbase.c:113 frame #1: 0x0000000100017235 blender`wm_event_do_handlers(C=0x0000000104f00228) + 2277 at wm_event_system.c:2503 frame #2: 0x000000010000b86e blender`WM_main(C=0x0000000104f00228) + 30 at wm.c:487 frame #3: 0x0000000100006f10 blender`main(argc=1, argv=0x00007fff5fbff710) + 1504 at creator.c:1935 frame #4: 0x0000000100006924 blender`start + 52 ``` Recursive calls to `wm_event_do_handlers()` means the same event gets handled and freed twice. I think `BLI_remlink(&win->queue, event);` should be moved to the start of the loop to avoid that, but then the last event before quitting Blender always leaks. I can look into it further this evening but feel free to fix it before that.

Campbell Barton commented

2015-09-22 11:53:57 +02:00

Id like to look into this, but cant redo the error in X11. Even when commenting the #ifdef defined(__APPLE__) || defined(WIN32), Its not crashing when changing to full-screen, tested quickly switching many times.

Id like to look into this, but cant redo the error in X11. Even when commenting the `#ifdef defined(__APPLE__) || defined(WIN32)`, Its not crashing when changing to full-screen, tested quickly switching many times.

blender-admin commented

2015-09-22 23:20:17 +02:00

This issue was referenced by 1cae9c4af4

This issue was referenced by 1cae9c4af480e2ab674901c0933be3286f2ae2ca

Brecht Van Lommel commented

2015-09-22 23:21:45 +02:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2015-09-22 23:21:45 +02:00

Brecht Van Lommel commented

2015-09-22 23:24:48 +02:00

Avoiding the memory leak is a bit painful, P262 is as simple as I could get it but it's still too messy.

Instead I've just removed the code to do recursive event handling during window live resize. We can handle notifiers and redraw the windows, but events we can handle after live resize. There might be a bunch of mouse move events or even key presses batched up in the queue, but the event handling should be able to handle that fine.

Avoiding the memory leak is a bit painful, [P262](https://archive.blender.org/developer/P262.txt) is as simple as I could get it but it's still too messy. Instead I've just removed the code to do recursive event handling during window live resize. We can handle notifiers and redraw the windows, but events we can handle after live resize. There might be a bunch of mouse move events or even key presses batched up in the queue, but the event handling should be able to handle that fine.

Campbell Barton commented

2015-09-25 06:11:14 +02:00

Added subscriber: @hairygoatface

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Fullscreen crashes Blender on Mac OS X #46202