| Message |
 |
- Date: 2010-08-01 18:23
- Sender: Damien Plisson
- Checked on OSX 10.6.4 64bit with r30944, and works fine. Maybe it has been fixed in the meantime ?
Can you check again with a latest svn, and confirm ?
|
- Date: 2010-08-02 18:34
- Sender: Richard Marklew
- Tried with r30967 from graphicall and still have the same problem.
Start to comb and the and get spinning beachball.
|
- Date: 2010-08-04 00:25
- Sender: Tom Musgrove
- Confirmed current svn here, get the beachball of death. For comb, cut, haven't tried others.
OS X 10.6.4, 2.8GHz Intel Core 2 Duo, 2 GB Ram. ATI Radeon HD 2600 Pro
I did a backtrace during the freeze might help?
Program received signal SIGINT, Interrupt.
0x00007fff8222c2fa in mach_msg_trap ()
(gdb) bt
#0 0x00007fff8222c2fa in mach_msg_trap ()
#1 0x00007fff8222c96d in mach_msg ()
#2 0x00007fff8500015e in io_connect_method ()
#3 0x00007fff84fbe33d in IOConnectCallMethod ()
#4 0x0000000116b3a1f2 in gldUpdateDispatch ()
#5 0x0000000115a3a5cf in glReadPixels_Exec ()
#6 0x00007fff83521114 in glReadPixels ()
#7 0x00000001002ea7b0 in key_test_depth (data=0x7fff5fbff310, co=0x119db3240) at source/blender/editors/physics/particle_edit.c:405
#8 0x00000001002ea8d0 in key_inside_circle (data=0x7fff5fbff310, rad=50, co=0x119db3240, distance=0x7fff5fbff494) at source/blender/editors/physics/particle_edit.c:430
#9 0x00000001002eb290 in foreach_mouse_hit_key (data=0x7fff5fbff310, func=0x1002f26bf <brush_comb>, selected=0) at source/blender/editors/physics/particle_edit.c:608
#10 0x00000001002f529e in brush_edit_apply (C=0x10418c128, op=0x1043591d8, itemptr=0x7fff5fbff5c0) at source/blender/editors/physics/particle_edit.c:3386
#11 0x00000001002f5a37 in brush_edit_apply_event (C=0x10418c128, op=0x1043591d8, event=0x119e2af98) at source/blender/editors/physics/particle_edit.c:3579
#12 0x00000001002f5a78 in brush_edit_invoke (C=0x10418c128, op=0x1043591d8, event=0x119e2af98) at source/blender/editors/physics/particle_edit.c:3587
#13 0x0000000100158226 in wm_operator_invoke (C=0x10418c128, ot=0x115861e98, event=0x119e2af98, properties=0x119e04cb8, reports=0x0) at source/blender/windowmanager/intern/wm_event_system.c:613
#14 0x0000000100159500 in wm_handler_operator_call (C=0x10418c128, handlers=0x119d53440, handler=0x119e26db8, event=0x119e2af98, properties=0x119e04cb8) at source/blender/windowmanager/intern/wm_event_system.c:1158
#15 0x0000000100159c9a in wm_handlers_do (C=0x10418c128, event=0x119e2af98, handlers=0x119d53440) at source/blender/windowmanager/intern/wm_event_system.c:1376
#16 0x000000010015a86f in wm_event_do_handlers (C=0x10418c128) at source/blender/windowmanager/intern/wm_event_system.c:1675
#17 0x0000000100153cc4 in WM_main (C=0x10418c128) at source/blender/windowmanager/intern/wm.c:336
#18 0x00000001001534a9 in main (argc=1, argv=0x7fff5fbff8f8) at source/creator/creator.c:1153
|
- Date: 2010-08-11 09:09
- Sender: Mike Sloman
- tkroo build of BF 2.5 Trunk 2.53.1 r31223
on OSX 10.6.4 i7 8GB ram ATI Radeon HD 4850
Works like a dream, all brushes fine and very responsive repeating the above description.
Using the attached .blend file works the same.
|
- Date: 2010-08-11 09:37
- Sender: Mike Sloman
- Spoke to soon :(
Attempts to re-size brush (comb or all others) with "F" key causes crash. Using slider to change size works fine.
Date/Time: 2010-08-11 16:51:37.584 +0930
OS Version: Mac OS X 10.6.4 (10F569)
Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000000002c8
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 org.blenderfoundation.blender 0x0000000100022b3b wm_radial_control_paint + 75
1 org.blenderfoundation.blender 0x0000000100014516 wm_paintcursor_draw + 166
2 org.blenderfoundation.blender 0x000000010001532b wm_draw_update + 2347
3 org.blenderfoundation.blender 0x00000001000128f0 WM_main + 48
4 org.blenderfoundation.blender 0x0000000100011478 main + 504
5 org.blenderfoundation.blender 0x0000000100010950 start + 52
Attempting "SHFT-F" with comb and other brushes crashes as well with this dump. Using slider to change strength works fine.
Process: blender [6884]
Path: darwin-x86_64/blender.app/Contents/MacOS/blender
Identifier: org.blenderfoundation.blender
Version: 2.5-beta (2.5-beta, 2010-Aug-10, Blender Foundation)
Code Type: X86-64 (Native)
Parent Process: launchd [177]
Date/Time: 2010-08-11 16:58:57.679 +0930
OS Version: Mac OS X 10.6.4 (10F569)
Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000285
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 org.blenderfoundation.blender 0x0000000100022bb9 wm_radial_control_paint + 201
1 org.blenderfoundation.blender 0x0000000100014516 wm_paintcursor_draw + 166
2 org.blenderfoundation.blender 0x000000010001532b wm_draw_update + 2347
3 org.blenderfoundation.blender 0x00000001000128f0 WM_main + 48
4 org.blenderfoundation.blender 0x0000000100011478 main + 504
5 org.blenderfoundation.blender 0x0000000100010950 start + 52
|
- Date: 2010-08-16 13:11
- Sender: Mike Sloman
- Moved "F" and "shift-F" problems to its own bug #23336
|
- Date: 2010-08-29 13:08
- Sender: Richard Marklew
- Problem still evident in r31513. All the particle tools do work fine though if in wireframe mode, including the official beta build. Other view modes cause the freezing.
|
- Date: 2010-09-03 08:27
- Sender: Janne Karhu
- Damien, could you please look at this since you have an OSX machine? I have a feeling that this could be quite a simple bug, but since I only have access to an XP machine (which doesn't freeze) I have no way of knowing where to look.
|
- Date: 2010-09-03 22:32
- Sender: Damien Plisson
- Janne, unfortunately I don't experience this bug. So it's going to be hard for me to debug it...
Richard and Mike both have ATI GPUs, and I have nVidia. And the crash is happening during openGL operations.
It seems to be closely related to bug #23561. Can you both test if your system crashes when resizing the blender window ?
There already has been such a crash bug with Mac ATI drivers that do not support some kind of optimization. This may be the same.
Janne, do you know the kind of GL setting/operation is in progress during the function calls where the crashes happen (key_test_depth & wm_radial_control_paint) ?
|
- Date: 2010-09-03 22:44
- Sender: Richard Marklew
- Damian
I get no problems at all when resizing the blender window in the beta or any other builds I try.
|
- Date: 2010-09-03 22:52
- Sender: Damien Plisson
- Richard, have you installed the latest 10.6.4 patches (including the graphical one) ?
|
- Date: 2010-09-03 23:08
- Sender: Richard Marklew
- I have all the latest updates for 10.6.4. I know there was a driver update for the ATi HD5750 used in the latest i7 iMac but one doesn't seem to be available for the HD4850.
|
- Date: 2010-09-04 01:37
- Sender: Tom Musgrove
- Damien,
It was a commit between these two commits 30920 and 30948 - on irc someone suggested it might be communt 30937 - the 'G.main' changes by brecht.
|
- Date: 2010-09-05 21:48
- Sender: Tom Musgrove
- Ok tracked it down more precisely, typed in the wrong numbers above.
It is between commits 29920 and 29948 - more precisely between 29931 and 29940,
The only change is an update to the paths code.
I've attached a diff = hair_comb_freeze.diff
|
- Date: 2010-09-05 22:10
- Sender: Nathan Letwory
- Hmm, the backtraces all point to ogl drawing code. I strongly doubt that filepath changes have anything to do with this.
|
- Date: 2010-09-06 19:56
- Sender: Tom Musgrove
- Well the only changes in the commit logs between 29931 and 29940 are the changes related to doing pathes as can be seen in the diff.
I tested all of the following
29931, 29930, 29925, 29850, 29800, 29750, 29500, 29000, 28500, 28000 and they work fine. Nothing later works (for OS X the revisions before 29940 but after 29931 don't compile).
|
- Date: 2010-09-07 01:44
- Sender: Tom Musgrove
- I have a hair particle file that it is working fine with if I load it with its current UI, but if I disable 'load UI' I get the freeze again. So some default has changed maybe? I looked through the preferences and didn't see anything obvious.
I have attached the file 'editable particles'
|
- Date: 2010-09-14 12:16
- Sender: Janne Karhu
- Yup, it looks like some opengl bug to me too based on the backtraces.. I'll add this to my unsolved bugs list for now. A lot of strange mac crashes/freezes lately it seems.
Tom, I just committed a fix for your file. I had forgotten a conversion factor for the particle brush strength about a half year ago, so your "old" file could now be fixed.
|
- Date: 2010-09-25 10:05
- Sender: Richard Marklew
- r32106 from graphicall works fine without any freezing
|
- Date: 2010-09-25 23:47
- Sender: Tom Musgrove
- Richard, I overlooked your mention of wireframe earlier - I can confirm that in wireframe mode it works fine, so that provides a workaround anyway.
In solid mode I still get freezes build from svn 32123. Didn't try the build from graphical. Here is a backtrace. Same as earlier.
#0 0x00007fff872992fa in mach_msg_trap ()
#1 0x00007fff8729996d in mach_msg ()
#2 0x00007fff825a015e in io_connect_method ()
#3 0x00007fff8255e33d in IOConnectCallMethod ()
#4 0x00000001168f4002 in gldUpdateDispatch ()
#5 0x0000000115739fe2 in glReadPixels_Exec ()
#6 0x00007fff83b50114 in glReadPixels ()
#7 0x00000001002e00dc in key_test_depth (data=0x7fff5fbff300, co=0x11d0ebe20) at source/blender/editors/physics/particle_edit.c:405
#8 0x00000001002e83e6 in brush_cut (data=0x7fff5fbff300, pa_index=762) at source/blender/editors/physics/particle_edit.c:2828
#9 0x00000001002e0e12 in foreach_point (data=0x7fff5fbff300, func=0x1002e81d6 <brush_cut>) at source/blender/editors/physics/particle_edit.c:650
#10 0x00000001002eac94 in brush_edit_apply (C=0x103e8c118, op=0x11d3dd218, itemptr=0x7fff5fbff5b0) at source/blender/editors/physics/particle_edit.c:3402
#11 0x00000001002eb393 in brush_edit_apply_event (C=0x103e8c118, op=0x11d3dd218, event=0x119bab6c8) at source/blender/editors/physics/particle_edit.c:3579
#12 0x00000001002eb3d4 in brush_edit_invoke (C=0x103e8c118, op=0x11d3dd218, event=0x119bab6c8) at source/blender/editors/physics/particle_edit.c:3587
#13 0x000000010014b3ea in wm_operator_invoke (C=0x103e8c118, ot=0x10535fdf8, event=0x119bab6c8, properties=0x11977bd08, reports=0x0) at source/blender/windowmanager/intern/wm_event_system.c:621
#14 0x000000010014c6fc in wm_handler_operator_call (C=0x103e8c118, handlers=0x115625a20, handler=0x1156436e8, event=0x119bab6c8, properties=0x11977bd08) at source/blender/windowmanager/intern/wm_event_system.c:1167
#15 0x000000010014ce06 in wm_handlers_do (C=0x103e8c118, event=0x119bab6c8, handlers=0x115625a20) at source/blender/windowmanager/intern/wm_event_system.c:1394
#16 0x000000010014d9db in wm_event_do_handlers (C=0x103e8c118) at source/blender/windowmanager/intern/wm_event_system.c:1693
#17 0x0000000100146e20 in WM_main (C=0x103e8c118) at source/blender/windowmanager/intern/wm.c:341
#18 0x0000000100146610 in main (argc=1, argv=0x7fff5fbff8f8) at source/creator/creator.c:1151
|
- Date: 2010-11-11 20:30
- Sender: Ton Roosendaal
- Janne, poke me in irc to go over this in daytime. :)
|
- Date: 2010-11-12 16:39
- Sender: Ton Roosendaal
- I went over it with Janne, but none of the provided clues tell us anything. More over, the changes in code between the aforementioned revision numbers are all very much unrelated to brush drawing or combing.
There's a small chance that compiling older svns is not fully reliable, it would be much appreciated if either Tom or Richard can do a svn rewind and make clean on r30540 and r30553.
(Here, with OSX 10.5 PPC ATI 9600 no crashes)
|
- Date: 2010-11-23 17:09
- Sender: Brecht Van Lommel
- Closed duplicate bug:
http://projects.blender.org/tracker/index.php?func=detail&aid=24868&group_id=9&atid=498
Comment from Campbell there:
Some graphics card/driver combinations are slow at reading the
depth buffer.
Janne, could the depth update function only be called when its
needed?
if(!retopo && sculptparticle && !(obact
&& (obact->dtx & OB_DRAWXRAY))) {
view3d_update_depths(ar);
}
This is probably whats causing the slowdown. its running for
every redraw.
2 possible fixes are to update less often (only when editing
the view), or rather then getting the entire depth buffer you
could just read a part of the buffer.
See: view_autodist_depth_margin()
|
- Date: 2010-11-23 19:11
- Sender: Janne Karhu
- I don't really know why the view3d_update_depths call is even there, even less why it's there twice! For me combing goes just fine without either call, but I could be missing some special case where this is needed.
Assigned to Campbell as discussed on irc.
|
- Date: 2010-11-26 13:59
- Sender: Campbell Barton
- fixed in svn r33330.
Now only read the Z buffer once when the operator starts.
from the commit log
- glReadPixels() was running to get the depth on each pixel, this works fine one some cards but was locking up on OSX.
- Replace glReadPixels() call with a single call to view3d_update_depths() right after view3d_validate_backbuf(), so the depths are only read once.
- Unrelated to the changes above, but should improve performance: view3d_validate_backbuf() was being called on every redraw while combing, now only call once when combing starts.
|
