| Message |
 |
- Date: 2010-08-29 19:48
- Sender: Dalai Felinto
- Can you run it from the console? There will probably be errors when it crashes. Also are you building your own Blender or getting it from graphicall?
Assigning to our OSX master Damien :)
|
- Date: 2010-08-29 21:04
- Sender: Geoff Gollmer
- I can't reproduce this bug. Resizing the main window on my computer works although during the resize the window doesn't update, and produces a few graphical errors. When did you download the graphics driver update?
2008 iMac 20"
OSX 10.6.4
2.66 GHz Core 2 Duo
2 gb ram
ATI Radeon HD 2600
|
- Date: 2010-08-29 21:12
- Sender: Damien Plisson
- Thanks Dalai :)
But I can't reproduce the issue, either with the 2.53beta or the svn #31642.
Using any of the two GPUs of my mbp : 9400M or 9600M GT.
Only minor bug I'll look at later is that after resizing a blender window that has a scroll bar going to bottom right, it is stuck in scroll mode until pressing the left mouse button.
@Cole: have you experienced any other issue recently on your system ?
Do you have multiple monitors, blender windows open when it crashes?
What is the crash? A kernel panic, or a system not responsive ? If last one, can you have something running in the background (e.g. video...) to check if the system is really frozen or if it is only the input (kbd + mouse). FYI, that was a previous bug that I fixed monthes ago.
Do you have anything in the system logs?
I have a system close to yours except for the GPU mainly (nVidia vs ATI).
MBP Unibody late 2008
OSX 10.6.4 with latest patches (gfx + last security one)
2.8GHz C2D
4GB RAM
nVidia 9400M + 9600M GT
|
- Date: 2010-08-29 21:49
- Sender: Geoff Gollmer
- I just used system update, and a driver update was available. After applying it I am able to reproduce the bug. So it's definitely an issue with the new drivers.
I tried creating the crash with the console open, but nothing is printed at all. I can still move my mouse around, but other than that nothing is responsive. Seems like a pretty big issue.
|
- Date: 2010-08-29 22:41
- Sender: Cole Reed
- Damien, my system becomes completely unresponsive, the only thing I can do is move my mouse around. I opened a video in the background before the crash and it freezes as well. I'm using a single monitor, and other than this no issues so far.
One other thing I noticed is that if I resize the window really slowly it wont crash right away, although sometimes it still does. If I resize by a lot and fast it will freeze every time though. Also if I just hit the maximize button blender will go fullscreen without crashing, but if I then hit it again to pop it out of fullscreen it will freeze after the resize.
Thanks Geoff, at least I know it's not just me now.
|
- Date: 2010-08-29 22:44
- Sender: Cole Reed
- Oh, forgot to add that I have tested with both my own builds from svn, one off of graphicall and the last official beta release. All give the same freeze result, although as I mentioned 2.49b has no issue.
|
- Date: 2010-08-30 21:33
- Sender: Damien Plisson
- Cole & Geoff, can you try with an OpenGL app from XCode examples, like the "From A View to A Movie", or any other that displays OpenGL in a window. And try to reproduce the bug.
If this is the case, that's a definitive proof of a driver bug with Cocoa.
Have you tried with the 32bit version ?
Are you running the 32bit or the 64bit kernel ? You may want to try with the other one (press 6 and 4 at boot to launch 64bit kernel, or 3 and 2 for 32bit).
FYI, I'm running the 64bit kernel.
|
- Date: 2010-08-30 22:13
- Sender: Cole Reed
- Hey Damien, I run a 64bit kernel as well. I did all of the tests you recommended, used a 32-bit blender from graphicall, and tried booting in 32 bit mode, both resulted in the same freeze when i resized the blender window. I also ran the view to a movie app "PlasmaExhibitsII", but had no problems displaying it or resizing the window.
|
- Date: 2010-08-31 20:21
- Sender: Damien Plisson
- Hi Cole, it's becoming hard to debug without having the bug on my machine... And when a code review doesn't give an obvious clue...
Anyway, can you trying building the Carbon version (32bit, and disabling the WITH_COCOA) ? It'll help to know if it is something with 2.5 GL code, or with Cocoa.
|
- Date: 2010-08-31 21:09
- Sender: Cole Reed
- Hey Damien I get errors when trying to build with Carbon. If you link me to a build I will test it out though.
|
|
- Date: 2010-08-31 21:57
- Sender: Cole Reed
- Sorry, Damien no luck. Still freezing with the Carbon build.
|
- Date: 2010-08-31 22:03
- Sender: Damien Plisson
- @Cole: Ok, so this doesn't seem to be part of ghost (Carbon or Cocoa). There must be some OpenGL function that the new ATI drivers don't like... And that's beyond my expertise...
@Dalai: Do you know a GL guru who has access to a Mac running 10.6.4 with ATI ?
|
- Date: 2010-08-31 23:28
- Sender: Dalai Felinto
- @Damien, Brecht used to have a "OSX 10.4, PPC G4, ATI Radeon 9600 (Mobility 9700)". I got it from the contributor list of Blender 2.49. I have no idea if he updated his machine to 10.6.4 though.
Ton used to have a OSX too. I have no idea of the graphic card/OS. I'm assigning this to Brecht first. But if he doesn't have it he will know if Ton does it.
|
- Date: 2010-09-15 21:20
- Sender: Brecht Van Lommel
- I don't have that computer anymore, and resizing works fine on intel mac here.
|
- Date: 2010-09-22 11:37
- Sender: Ton Roosendaal
- I still use this PPC G5, OSX 10.5, with ATI 9600. The official 2.54 binary on blender.org runs fine and allows window resize. The difference is that for OSX 10.6 and cocoa, a resize makes life updates possible (while sizing it sends draws to Blender). Here a syncing issue with opengl context might be the problem.
The fact that it used to work fine before driver upgrade is evidence we're having another OSX bug again... we have had this several times before, and unfortunately only a new Mac update will solve that.
What's worth testing is if it's possible to disable live updating in our Ghost cocoa code, Damien?
(BTW: this report actually belongs in our opengl tracker, we can add a wiki todo item on the OpenGL issues list for it)
|
- Date: 2010-09-26 21:57
- Sender: Damien Plisson
- @Ton: Live resize was in fact piling up resize messages that were sent to the window manager after the user had released the mouse button.
I've disabled this so that only one message is sent.
In addition, the Cocoa GL view is also redrawn (seemed to have no effect but may be also cause for the crash) only once, at the end of the resize.
Changes committed in svn #32134
@Cole: Tell me if this fixes it...
|
- Date: 2010-09-27 01:39
- Sender: Cole Reed
- @Damien, unfortunately no change, still freezes when resizing. One thing I have noticed is that if I only change the window size by a small amount it will not freeze. So if I slowly resize it by say 20px, it usually will not freeze up. Any sort of large quick resize will freeze it though. This was possible before your update as well though.
|
|
- Date: 2010-09-27 22:13
- Sender: Damien Plisson
- @Cole, can you try resizing with the Maximize button only (just to check if size change w/o any live resize works)?
One way to ensure the size change (as Blender starts maximized) is to hide the dock after you started Blender. Thus pressing the maximize button will have effect.
In addition, is the freeze happening while you resize the window, or just after releasing the mouse button ?
|
- Date: 2010-09-27 23:07
- Sender: Cole Reed
- @Damien, I can confirm that when manually resizing the window by dragging the freeze does not accure until after mouse release.
The maximizing thing is a little harder to answer conclusively. I used your technique of opening blender with the dock open then closing the dock and maximizing blender and then returning it to the original size. I did this quite a few times with no freeze. However, when I tried this will a build (r31626) previous to your update everything froze as soon as I clicked the maximize button the second time to return it to the initial size. Other than it being an older build the other difference was that on starting that build, blender opened in a smaller window size. Soo, what I can't really conclude is whether the size of the change when clicking the maximize button can cause the freeze as well. Unfortunately, because of the freezing when dragging, I'm unable to resize the new builds down to a smaller size and then test the maximizing functionality.
|
- Date: 2010-09-28 08:56
- Sender: Dalai Felinto
- @Cole, I was going to suggest you to open Blender from the terminal passing the parameters --windows-geometry (e.g. blender --window-geometry 0 0 500 500 ). However it doesn't seem to be working on OSX (I happen to be on a Mac Air now). Maybe a bug to be tackled first? Later today I will test it in a windows to see where is the problem.
|
- Date: 2010-10-05 02:04
- Sender: Stephen Heward
- I second this, I have the exact same hardware specs. Kernel Panic with Crash log links it back to the graphic driver:
Kernel Extensions in backtrace (with dependencies):
com.apple.ATIRadeonX2000(6.1.8)@0x5cc4c000->0x5cdedfff
|
- Date: 2010-11-08 19:35
- Sender: Dan Johnson
- I have the same issue.
Blender 2.55 build
It happens for me when changing window size while in Sculpt mode.
It locks everything up, except mouse movement.
Force Quit doesn't even work.
Model Name: iMac
Model Identifier: iMac7,1
Processor Name: Intel Core 2 Duo
Processor Speed: 2 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 4 MB
Memory: 4 GB
Bus Speed: 800 MHz
|
- Date: 2010-11-24 19:36
- Sender: Ton Roosendaal
- Assigned to Damien (trying to do for all unassigned issues :)
|
- Date: 2010-11-24 19:39
- Sender: Cole Reed
- FYI, Apple's latest update(10.6.5), which included some graphic card driver updates, produced no change in the resize freezing.
|
- Date: 2010-12-04 13:32
- Sender: Christopher Creutzig
- Unfortunately, I know very little about OpenGL, but I noticed no-one attached a backtrace yet, so I thought I could at least do that:
#0 0x00007fff81dba2da in mach_msg_trap ()
#1 0x00007fff81dba94d in mach_msg ()
#2 0x00007fff83d1370c in _CGSFlushSurfaceInline ()
#3 0x00007fff83d13479 in CGSFlushSurfaceWithOptions ()
#4 0x00007fff828e6927 in glcNoop ()
#5 0x0000000138092491 in gldFlush ()
#6 0x00007fff828e524d in CGLFlushDrawable ()
#7 0x0000000100b4cc7a in GHOST_WindowCocoa::swapBuffers
(this=0x135d00450) at intern/ghost/intern/GHOST_WindowCocoa.mm:910
#8 0x0000000100b388ad in GHOST_SwapWindowBuffers
(windowhandle=0x135d00450) at intern/ghost/intern/GHOST_C-api.cpp:683
#9 0x0000000100030a58 in wm_window_swap_buffers (win=0x135d0b158) at
source/blender/windowmanager/intern/wm_window.c:1120
#10 0x00000001000195a6 in wm_draw_update (C=0x12472b178) at source/
blender/windowmanager/intern/wm_draw.c:776
#11 0x000000010001671b in WM_main (C=0x12472b178) at source/blender/
windowmanager/intern/wm.c:348
#12 0x0000000100015efd in main (argc=1, argv=0x7fff5fbff998) at source/
creator/creator.c:1195
It seems that all of the GUI is locked up (including remote desktop connections), but ssh connections to the affected machine keep working.
|
- Date: 2010-12-15 14:25
- Sender: Ton Roosendaal
- I've built blender with Cocoa, and the refreshes during window-size are only done after releasing the mouse button.
This report is now getting too old, with inconsistant test info in it. Within 2 weeks we have an official release build for everyone. It's very important to have everyone using the same builds (or each others).
In case the crash remains in 2.56, just reopen or report a new bug!
|
