Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 12/02/2010 at 20:19, xxxxxxxx wrote:
User Information: Cinema 4D Version: 11 11.5 Platform: Windows ; Mac ; Language(s) : C++ ;
--------- My plugin seems to work quite well on Windows 32bit and also for Mac OSX 64 bit . There are no problems. However, for some strange reason, people are reporting that the 32bit mac version is crashing quite a bit. I am confused because the 32 bit windows versions never crashes. My plugin uses some high resolution images but I can't see them causing C4D to crash regularly. Are there some things I need to add in my code that are different between Macs and PC's?
I am confused as to why my plugin would work fine for 32 bit windows and not for 32 mac. especially when it works fine for 64bit mac. Does this indicate anything in particular to anyone? Can anyone think of why this might be occurring? What should I look for? Thanks in advance.
~Shawn
On 13/02/2010 at 00:05, xxxxxxxx wrote:
Originally posted by xxxxxxxx <ADDRESS> User Information: Cinema 4D Version: 11 11.5 Platform: Windows ; Mac ; Language(s) : C++ ; --------- </ADDRESS> My plugin seems to work quite well on Windows 32bit and also for Mac OSX 64 bit . There are no problems. However, for some strange reason, people are reporting that the 32bit mac version is crashing quite a bit. I am confused because the 32 bit windows versions never crashes. My plugin uses some high resolution images but I can't see them causing C4D to crash regularly. Are there some things I need to add in my code that are different between Macs and PC's? I am confused as to why my plugin would work fine for 32 bit windows and not for 32 mac. especially when it works fine for 64bit mac. Does this indicate anything in particular to anyone? Can anyone think of why this might be occurring? What should I look for? Thanks in advance.~Shawn
Originally posted by xxxxxxxx
<ADDRESS> User Information: Cinema 4D Version: 11 11.5 Platform: Windows ; Mac ; Language(s) : C++ ;
--------- </ADDRESS> My plugin seems to work quite well on Windows 32bit and also for Mac OSX 64 bit . There are no problems. However, for some strange reason, people are reporting that the 32bit mac version is crashing quite a bit. I am confused because the 32 bit windows versions never crashes. My plugin uses some high resolution images but I can't see them causing C4D to crash regularly. Are there some things I need to add in my code that are different between Macs and PC's? I am confused as to why my plugin would work fine for 32 bit windows and not for 32 mac. especially when it works fine for 64bit mac. Does this indicate anything in particular to anyone? Can anyone think of why this might be occurring? What should I look for? Thanks in advance.~Shawn
Things to check: - Do these crashes happen on Intel or PPC Macs. If it is only on PPC Macs, you likely have a problem related to byte ordering
- On the Mac you always have access to addresses > 2 GB in 32 bit mode (usually up to 3.6 GB), while most PCs are limited to 1.6 GB (< 2 GB). Could be that you're mixing ints and uints when using pointer arithmetics and therefore get into trouble (memory trasher) when addressing memory >= 2GB address.
Best regards,
Wilfried Behne
On 13/02/2010 at 07:48, xxxxxxxx wrote:
Originally posted by xxxxxxxx Things to check: - Do these crashes happen on Intel or PPC Macs. If it is only on PPC Macs, you likely have a problem related to byte ordering
Hi Wilfried,
could you give an example on this one? I have a similar issue where I get crashes only on PPC. This happens with loading of a scene into the material preview of a custom shader. The scene itself loads a custom file and reads out some information. However, the custom file is a hyperfile and only the usual suspects of the SDK like ReadLong, ReadReal etc. are used for loading. If I didn´t misunderstood these should be plattform independent right? (except for ReadMemory) It works fine on Intel MACs but crashes PPC. Byte ordering in this case shouldn´t make any problems I assumed.
Memory can´t be the issue, I am addressing only about 100MB in that case.
Unfortunately there is no bug report generated. The system just hangs. But this is what my tester sent me (not sure if it is of any help) :
this is something I could find in OSX 10.4.11 console log: CINEMA 4D(351,0x31e7200) malloc: *** error for object 0x300d000: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug CINEMA 4D(351,0x31e7200) malloc: *** set a breakpoint in szone_error to debug CINEMA 4D(351,0x3276800) malloc: *** error for object 0x300d000: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug CINEMA 4D(351,0x3276800) malloc: *** set a breakpoint in szone_error to debug MacOSException::PortListener: exception received MacOSException::PortListener: calling exc_server catch_exception_raise: Examine exception catch_exception_raise: Get thread list catch_exception_raise: Suspend running threads catch_exception_raise: call crash report generator C4DUnhandledExceptionFilter: writing machine info C4DUnhandledExceptionFilter: writing c4d info C4DUnhandledExceptionFilter: writing scene info C4DUnhandledExceptionFilter: writing exception info C4DUnhandledExceptionFilter: writing call stacks DoStackTrace: create stack trace DoStackTrace: create stack trace DoStackTrace: create stack trace DoStackTrace: create stack trace DoStackTrace: create stack trace DoStackTrace: create stack trace
this is something I could find in OSX 10.4.11 console log:
CINEMA 4D(351,0x31e7200) malloc: *** error for object 0x300d000: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug CINEMA 4D(351,0x31e7200) malloc: *** set a breakpoint in szone_error to debug CINEMA 4D(351,0x3276800) malloc: *** error for object 0x300d000: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug CINEMA 4D(351,0x3276800) malloc: *** set a breakpoint in szone_error to debug MacOSException::PortListener: exception received MacOSException::PortListener: calling exc_server catch_exception_raise: Examine exception catch_exception_raise: Get thread list catch_exception_raise: Suspend running threads catch_exception_raise: call crash report generator C4DUnhandledExceptionFilter: writing machine info C4DUnhandledExceptionFilter: writing c4d info C4DUnhandledExceptionFilter: writing scene info C4DUnhandledExceptionFilter: writing exception info C4DUnhandledExceptionFilter: writing call stacks DoStackTrace: create stack trace DoStackTrace: create stack trace DoStackTrace: create stack trace DoStackTrace: create stack trace DoStackTrace: create stack trace DoStackTrace: create stack trace
I am using LoadDocument() in MATPREVIEW_MODIFY_CACHE_SCENE to load the scene (I am passing NULL for the BaseThread member of that function) and free it with BaseDocument::Free() correctly. Otherwise there are no memory leaks I know of (c4d debug console on PC at least doesn´t give me anything and all other testers not on PPC also have no problems at all). It´s really just happening on PPC.
Anything else you might think of?
thanks ia
On 15/02/2010 at 03:45, xxxxxxxx wrote:
Originally posted by xxxxxxxx Originally posted by xxxxxxxx Things to check: - Do these crashes happen on Intel or PPC Macs. If it is only on PPC Macs, you likely have a problem related to byte ordering Hi Wilfried,could you give an example on this one? I have a similar issue where I get crashes only on PPC. This happens with loading of a scene into the material preview of a custom shader. The scene itself loads a custom file and reads out some information. However, the custom file is a hyperfile and only the usual suspects of the SDK like ReadLong, ReadReal etc. are used for loading. If I didn´t misunderstood these should be plattform independent right? (except for ReadMemory) It works fine on Intel MACs but crashes PPC. Byte ordering in this case shouldn´t make any problems I assumed.Memory can´t be the issue, I am addressing only about 100MB in that case.Unfortunately there is no bug report generated. The system just hangs. But this is what my tester sent me (not sure if it is of any help) : ...
Hi Wilfried,could you give an example on this one? I have a similar issue where I get crashes only on PPC. This happens with loading of a scene into the material preview of a custom shader. The scene itself loads a custom file and reads out some information. However, the custom file is a hyperfile and only the usual suspects of the SDK like ReadLong, ReadReal etc. are used for loading. If I didn´t misunderstood these should be plattform independent right? (except for ReadMemory) It works fine on Intel MACs but crashes PPC. Byte ordering in this case shouldn´t make any problems I assumed.Memory can´t be the issue, I am addressing only about 100MB in that case.Unfortunately there is no bug report generated. The system just hangs. But this is what my tester sent me (not sure if it is of any help) : ...
I was thinking of bugs like - having a void* (in 64 bit) and casting it to a long* to check its content for zero (these bugs won't be recognized on Intel as long as the content is <= 32 bit, while on PPC there are the high order bytes first and therefore such a check would deliver zero until the content is > 32 bit)
- Using sscanf/sprintf for reading/writing memory and assuming a certain memory order. This could lead to wrong indices which in return could cause memory trashers by writing before/beyond array boundaries.
... . If you use Cinema's functions, memory order should be no concern.
In your bugreport the most interesting parts (the ones below "DoStackTrace") are missing. If that bug is reproducable, you could use the Rosetta PPC emulation on your IntelMac to track this further down - you can't use the debugger there, but could old printf-debugging (via console) is possible.
On 15/02/2010 at 04:21, xxxxxxxx wrote:
ah I see. ok, as I am using cinema´s functions only that should work so I´ll do a good ol print debugging to catch the bugger.
thanks for the quick help
On 17/02/2010 at 13:08, xxxxxxxx wrote:
the crash is not easily reproducable, it happens at arbitrary location however always inside of my own MP thread. I finally got a crash report and it tells me the function it crashes in (though a second crash also gives a different crash location but always in that thread). However, I cannot locate the crashing cause. The code seems fine (but apparently I am missing something) and it´s strange it only crashes on PPC.
What bugs me is the last entries in the crash report. Here is the snippet. Does this tell you anything? HIToolbox and the TestBreak calls?
Exception { ExceptionNumber = 0x00000001 ExceptionText = "EXC_BAD_ACCESS" Address = 0x9335b838 Thread = 4 Last_Error = 0x00000000 } Call_Stacks { Call_Stack_Thread_4 { HIToolbox: \_NextEventInQueue + 0x4 (SP: 0xf02847b0 PC: 0x9335b838) HIToolbox: \_FindSpecificEventInQueue + 0x34 (SP: 0xf0284800 PC: 0x9336930c) CINEMA 4D: \__ZN10NoNoThread9TestBreakEv + 0x50 (SP: 0xf0284860 PC: 0x87dea0) CINEMA 4D: \__ZN13ViewScheduler9TestBreakEv + 0xb0 (SP: 0xf02848b0 PC: 0x180b60)
dpit.dylib: __ZN5Fluid6Solver10AdvectGridERKiRKfRNS_13VelocityCacheEPNS_5EGridIfEES9_RKNS_8Vector3DESC_S9_ + 0x36c (SP: 0xf0284900 PC: 0xc30086c)
On 18/02/2010 at 01:53, xxxxxxxx wrote:
Originally posted by xxxxxxxx ...The code seems fine (but apparently I am missing something) and it´s strange it only crashes on PPC.What bugs me is the last entries in the crash report. Here is the snippet. Does this tell you anything?
...The code seems fine (but apparently I am missing something) and it´s strange it only crashes on PPC.What bugs me is the last entries in the crash report. Here is the snippet. Does this tell you anything?
The snipet is too short (and can't be decoded in this shortened form). I just see that this is crashing inside of the OS (most probably stack trashed) and that this is no release version.
Was this an emulation or a real PPC cpu (which one? G5, G4 MP?)?
One thing that 's very sensitive on the PPC is the memory model. If you're using your own synchronization or linked lists in a multithreaded environment, there is a chance, that they don't work properly.
Contrary to the strict memory model of the x86 cpus, the PowerPC allows re-ordering of memory load/stores within one cpu and also might execute the load/stores on the bus of different cores in a different order than you might think (or wanted it) - unless you use explicit syncing commands.
On 18/02/2010 at 09:06, xxxxxxxx wrote:
Originally posted by xxxxxxxx The snipet is too short (and can't be decoded in this shortened form). I just see that this is crashing inside of the OS (most probably stack trashed) and that this is no release version.
thanks. Do you mean the os is no release version? (Please find the whole bug report at the end of this message)
afaik it´s a real G5 PPC cpu but I´ll ask my tester.
Ok, I take this into consideration. I still have an old G4 in my basement. I think I need to get it up and running again and check for myself if I can reproduce the crash to see if I can confirm any of this. I am not using an own syncing or linked lists though.
thanks for the hints and help so far!
ComputerInfo
{
OS_Type = OS X
OS_Version = 10.4.9
Machine_Model = PowerMac7,3
Processor_Type = PowerPC
Processor_Speed = 2500 MHz
Number_of_processors = 2
Graphics_card = Vendor: ATI Technologies Inc., renderer: ATI Radeon 9600 XT OpenGL Engine, version: 1.5 ATI-1.4.18
Loaded_Plugins = addons expressiontag graphviewcore modeling newman objects shader xtensions advancedrender bitmapfilter bp2lw bp2maya characteranim ca2 allplan browser compositing fbx6 flashex openexr relaxuv sla clothilde dynamics hair mocca settings.cof onlinehelp pyrocluster sketch sky thinkingparticles tpoperators dpit
}
ApplicationInfo
CINEMA_4D_Version: 10.111
Memory(Global) : 53508752
Memory(GlobalPeak) : 93096968
Memory(Total) : 717
Memory(Current) : 274
Memory(LowMemCnt) : 0
Opened Scenes
Active Scene: 0x9686b14 "Untitled 1"
Exception
ExceptionNumber = 0x00000001
ExceptionText = "EXC_BAD_ACCESS"
Address = 0x9335b838
Thread = 4
Last_Error = 0x00000000
Call_Stacks
Call_Stack_Thread_4
HIToolbox: _NextEventInQueue + 0x4 (SP: 0xf02847b0 PC: 0x9335b838)
HIToolbox: _FindSpecificEventInQueue + 0x34 (SP: 0xf0284800 PC: 0x9336930c)
CINEMA 4D: __ZN10NoNoThread9TestBreakEv + 0x50 (SP: 0xf0284860 PC: 0x87dea0)
CINEMA 4D: __ZN13ViewScheduler9TestBreakEv + 0xb0 (SP: 0xf02848b0 PC: 0x180b60)
dpit.dylib: __ZN5Fluid6Solver19GridStepAEiRKfRNS_13VelocityCacheEPNS_5EGridIfEES7_RKNS_8VecInt3DESA_ + 0x134 (SP: 0xf0284ca0 PC: 0xc303514)
CINEMA 4D: __ZN14MPPluginThread4DoItEv + 0x1c (SP: 0xf0284d50 PC: 0x90a26c)
CINEMA 4D: __ZN10BaseThread6ActionEv + 0xe8 (SP: 0xf0284d90 PC: 0x87cb98)
CINEMA 4D: __Z11BeginThreadPv + 0x10 (SP: 0xf0284df0 PC: 0x87cc50)
libSystem.B.dylib: __pthread_body + 0x60 (SP: 0xf0284e30 PC: 0x9002b908)
Registers
srr0: 0x000000009335b838 srr1: 0x000000000000f030 vrsave: 0x0000000000000000 cr: 0x0000000024000018 xer: 0x0000000000000000 lr: 0x000000009335b780 ctr: 0x00000000900011c8 r0: 0x000000000300d130 r1: 0x00000000f02847b0 r2: 0x000000000300d000 r3: 0x000000000300d000 r4: 0x0000000000000000 r5: 0x00000000000003e8 r6: 0x00000000ffffffff r7: 0x0000000000000005 r8: 0x000000000df02346 r9: 0x000000000300d010 r10: 0x000000000df00342 r11: 0x000000000300d250 r12: 0x00000000900011c8 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000 r16: 0x0000000000000000 r17: 0x0000000000000000 r18: 0x00000000f0284cec r19: 0x00000000bfffc0c4 r20: 0x000000000000000d r21: 0x0000000000000000 r22: 0x0000000000000000 r23: 0x0000000000000000 r24: 0x000000000d9dba24 r25: 0x000000000d9db964 r26: 0x0000000000000000 r27: 0x0000000000000000 r28: 0x000000000087c900 r29: 0x000000000300d000 r30: 0x000000000de1a130 r31: 0x000000009335b700 }
Variables
ThreadName = DPIT Transport Thread
Arg|DocumentOLE|Name =
Arg|GeLoadBitmap|Name =
Arg|GeLoadBitmap|Frame = 0
Arg|GeSaveBitmap|Name =
Arg|LoadDocument|Name =
Arg|LoadDocument|Flags = 0
Arg|CoffeeFile|Name =
Arg|CoffeeLine|Line = 0
Call_Stack_Thread_0
libSystem.B.dylib: _mach_wait_until + 0x8 [Bad_Frame] (SP: 0x0 PC: 0x90040df8)
libSystem.B.dylib: _nanosleep + 0x184 (SP: 0xbfffbe80 PC: 0x90040bc4)
libSystem.B.dylib: _usleep + 0x58 (SP: 0xbfffbf20 PC: 0x90044398)
CINEMA 4D: __ZN12MpThreadPool21WaitForAllHasFinishedEv + 0xc8 (SP: 0xbfffbf80 PC: 0x87daf8)
dpit.dylib: __ZN5Fluid23MoveControlThread4MainEv + 0x7bc (SP: 0xbfffbfd0 PC: 0xc1cbeac)
CINEMA 4D: __ZN12PluginThread4DoItEv + 0x1c (SP: 0xbfffc750 PC: 0x90a13c)
CINEMA 4D: __ZN10BaseThread5StartEil + 0x3c0 (SP: 0xbfffc790 PC: 0x87d680)
CINEMA 4D: __Z7BsStartP10BaseThreadili + 0x20 (SP: 0xbfffc800 PC: 0x393a20)
dpit.dylib: __ZN5Fluid6Solver17AdvectEi + 0x194 (SP: 0xbfffc840 PC: 0xc133964)
dpit.dylib: __ZN14FluidSimulator12UpdateFluidsEP13BaseContainerP10BaseObjectRKiS5_S5_ + 0xe38 (SP: 0xbfffdb20 PC: 0xc11b6e8)
dpit.dylib: __ZN14FluidSimulator17GetVirtualObjectsEP10BaseObjectP13HierarchyHelp + 0x10dc (SP: 0xbfffdc60 PC: 0xc11da0c)
CINEMA 4D: __ZN12PluginObject20GetVirtualObjectsNewER13HierarchyHelpl + 0x90 (SP: 0xbfffe060 PC: 0x3c0c70)
CINEMA 4D: __ZN10BaseObject20CreateVirtualObjectsER13HierarchyHelpl + 0x140 (SP: 0xbfffe0b0 PC: 0xda100)
CINEMA 4D: __Z16PreparePolyCacheR13HierarchyHelpP10BaseObject + 0x78 (SP: 0xbfffe180 PC: 0x1813a8)
CINEMA 4D: __Z15CalculateCachesP12BaseDocumentP10BaseThreadlil + 0x13c (SP: 0xbfffe240 PC: 0x181dbc)
CINEMA 4D: __ZN18SceneHookExecution7ExecuteEP8MegaPass + 0x2f0 (SP: 0xbfffe340 PC: 0x3c1b70)
CINEMA 4D: __Z12PrepareSceneP12BaseDocumentP8MegaPassP10BaseThreadll + 0x94 (SP: 0xbfffe3d0 PC: 0x3c2134)
CINEMA 4D: __ZN13ViewScheduler4DoItEv + 0x968 (SP: 0xbfffe440 PC: 0x183458)
CINEMA 4D: __ZN10BaseThread5StartEil + 0x3c0 (SP: 0xbffff520 PC: 0x87d680)
CINEMA 4D: __Z9DrawViewslP10ViewWindow + 0x410 (SP: 0xbffff590 PC: 0x181b60)
CINEMA 4D: __Z29EditorGePollLoopCallBackTimerv + 0x11c (SP: 0xbffff610 PC: 0x1465fc)
CINEMA 4D: __ZN6Editor11TimerNotifyEv + 0x58 (SP: 0xbffff660 PC: 0x148678)
CINEMA 4D: __ZN13CManagerFrame7MessageERK13BaseContainer + 0x6f0 (SP: 0xbffff6c0 PC: 0x689740)
CINEMA 4D: __ZN12CoffeeCFrame9CbMessageERK13BaseContainer + 0x70 (SP: 0xbffff8b0 PC: 0x5fea50)
CINEMA 4D: __ZN10XBaseFrame14BfTimerMessageEv + 0xe0 (SP: 0xbffff950 PC: 0x671e40)
CINEMA 4D: __ZN10XTimerList7DoTimerEli + 0xa4 (SP: 0xbffff9f0 PC: 0x6702e4)
CINEMA 4D: __Z13XDoFrameTimerli + 0x30 (SP: 0xbffffa50 PC: 0x6703c0)
CINEMA 4D: __Z14MacMessageLoopPVi + 0x22c (SP: 0xbffffaa0 PC: 0x16cdc)
CINEMA 4D: _main + 0x3b0 (SP: 0xbffffb30 PC: 0x19f90)
CINEMA 4D: __start + 0x2f8 (SP: 0xbffffc40 PC: 0x903c)
CINEMA 4D: start + 0x30 (SP: 0xbffffcc0 PC: 0x8d40)
srr0: 0x0000000090040df8 srr1: 0x000000000000f030 vrsave: 0x0000000000000000 cr: 0x0000000082002448 xer: 0x0000000000000000 lr: 0x0000000090040bc4 ctr: 0x0000000090040df0 r0: 0x00000000ffffffa6 r1: 0x00000000bfffbe80 r2: 0x0000000000010463 r3: 0x0000000000000000 r4: 0x000000000fdb52ac r5: 0x00000000000003e8 r6: 0x00000000ffffffff r7: 0x0000000000000000 r8: 0x0000000090040d28 r9: 0x0000000000000000 r10: 0x00000000001e8480 r11: 0x00000000a0006c10 r12: 0x0000000090040df0 r13: 0x00000000bfffdf00 r14: 0x0000000000000000 r15: 0x000000000000001b r16: 0x00000000bfffc0b0 r17: 0x0000000000000000 r18: 0x000000000d9dc8e4 r19: 0x000000000d9dcad4 r20: 0x000000000d9dccc4 r21: 0x0000000000000000 r22: 0x000000000087c8d4 r23: 0x00000000bfffc960 r24: 0x00000000901c0a50 r25: 0x0000000000000000 r26: 0x00000000a0010a50 r27: 0x00000000a0010a50 r28: 0x00000000000000e9 r29: 0x000000000fdb52ac r30: 0x00000000bfffbf58 r31: 0x0000000090040a50 }
Call_Stack_Thread_1
libSystem.B.dylib: _mach_msg_trap + 0x8 [Bad_Frame] (SP: 0x0 PC: 0x9000af48)
libSystem.B.dylib: _mach_msg + 0x3c (SP: 0xf007fbb0 PC: 0x9000ae9c)
libSystem.B.dylib: _thread_get_state + 0x98 (SP: 0xf007fc20 PC: 0x90052370)
CINEMA 4D: __ZN16CrashInfoHandler27C4DUnhandledExceptionFilterEjjiiPjj + 0x15f8 (SP: 0xf007fef0 PC: 0x8efae8)
CINEMA 4D: _catch_exception_raise + 0x204 (SP: 0xf00803b0 PC: 0x30dc4)
libSystem.B.dylib: __Xexception_raise + 0xbc (SP: 0xf00804f0 PC: 0x900a5fb4)
libSystem.B.dylib: _exc_server + 0xa8 (SP: 0xf0080540 PC: 0x900a5ea4)
CINEMA 4D: __ZN14MacOSException12PortListenerEPv + 0xd0 (SP: 0xf0080590 PC: 0x313a0)
libSystem.B.dylib: __pthread_body + 0x60 (SP: 0xf0080e30 PC: 0x9002b908)
srr0: 0x000000009000af48 srr1: 0x000000000200d030 vrsave: 0x0000000000000000 cr: 0x0000000048000404 xer: 0x0000000000000000 lr: 0x000000009000ae9c ctr: 0x000000009000af40 r0: 0x00000000ffffffe1 r1: 0x00000000f007fbb0 r2: 0x00000000000062af r3: 0x00000000f007fc58 r4: 0x0000000000000003 r5: 0x0000000000000028 r6: 0x0000000000000270 r7: 0x00000000000062af r8: 0x0000000000000000 r9: 0x0000000000000000 r10: 0x0000000000001c46 r11: 0x00000000a0006a28 r12: 0x000000009000af40 r13: 0x00000000008c0000 r14: 0x0000000000b30000 r15: 0x0000000008e7a000 r16: 0x0000000000000004 r17: 0x0000000000000006 r18: 0x000000000000005c r19: 0x0000000000000a07 r20: 0x00000000f007ff2c r21: 0x000000000000640f r22: 0x0000000000000001 r23: 0x0000000000000028 r24: 0x00000000f007fc58 r25: 0x0000000000000270 r26: 0x00000000000062af r27: 0x0000000000000000 r28: 0x0000000000000000 r29: 0x0000000000000003 r30: 0x0000000000000003 r31: 0x00000000900522e0 }
Call_Stack_Thread_2
libSystem.B.dylib: _semaphore_wait_signal_trap + 0x8 [Bad_Frame] (SP: 0x0 PC: 0x9002bfc8)
libSystem.B.dylib: _pthread_cond_wait + 0x1e0 (SP: 0xf0101d30 PC: 0x90030aac)
CINEMA 4D: __ZN10BaseThread6ActionEv + 0x120 (SP: 0xf0101d90 PC: 0x87cbd0)
CINEMA 4D: __Z11BeginThreadPv + 0x10 (SP: 0xf0101df0 PC: 0x87cc50)
libSystem.B.dylib: __pthread_body + 0x60 (SP: 0xf0101e30 PC: 0x9002b908)
srr0: 0x000000009002bfc8 srr1: 0x000000000200f030 vrsave: 0x0000000000000000 cr: 0x0000000022000224 xer: 0x0000000000000000 lr: 0x0000000090030aac ctr: 0x000000009002bfc0 r0: 0x00000000ffffffdb r1: 0x00000000f0101d30 r2: 0x0000000000000001 r3: 0x0000000000004b03 r4: 0x0000000000004c03 r5: 0x00000000000003e8 r6: 0x00000000ffffffff r7: 0x0000000000000000 r8: 0x0000000000000000 r9: 0x00000000a0001fa4 r10: 0x000000000477c710 r11: 0x00000000a0006bf4 r12: 0x000000009002bfc0 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000 r16: 0x0000000000000000 r17: 0x0000000000000000 r18: 0x0000000000000000 r19: 0x0000000000000000 r20: 0x0000000000000000 r21: 0x0000000000000000 r22: 0x0000000000000000 r23: 0x0000000000000000 r24: 0x0000000000b30000 r25: 0x000000000d21b3f4 r26: 0x00000000a00008dc r27: 0x000000000d21b410 r28: 0x00000000a0001fa4 r29: 0x000000000d21b3f4 r30: 0x00000000a0001fa4 r31: 0x00000000900308dc }
ThreadName = RedrawThread BP
Call_Stack_Thread_3
libSystem.B.dylib: _pthread_cond_wait + 0x1e0 (SP: 0xf0182d30 PC: 0x90030aac)
CINEMA 4D: __ZN10BaseThread6ActionEv + 0x120 (SP: 0xf0182d90 PC: 0x87cbd0)
CINEMA 4D: __Z11BeginThreadPv + 0x10 (SP: 0xf0182df0 PC: 0x87cc50)
libSystem.B.dylib: __pthread_body + 0x60 (SP: 0xf0182e30 PC: 0x9002b908)
srr0: 0x000000009002bfc8 srr1: 0x000000000000f030 vrsave: 0x0000000000000000 cr: 0x0000000024000204 xer: 0x0000000000000000 lr: 0x0000000090030aac ctr: 0x000000009002bfc0 r0: 0x00000000ffffffdb r1: 0x00000000f0182d30 r2: 0x0000000000000001 r3: 0x0000000000005003 r4: 0x0000000000004f03 r5: 0x00000000000003e8 r6: 0x00000000ffffffff r7: 0x0000000000000000 r8: 0x0000000000000000 r9: 0x00000000a0001fa4 r10: 0x00000000047da920 r11: 0x00000000a0006bf4 r12: 0x000000009002bfc0 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000 r16: 0x0000000000000000 r17: 0x0000000000000000 r18: 0x0000000000000000 r19: 0x0000000000000000 r20: 0x0000000000000000 r21: 0x0000000000000000 r22: 0x0000000000000000 r23: 0x0000000000000000 r24: 0x0000000000b30000 r25: 0x000000000d21b854 r26: 0x00000000a00008dc r27: 0x000000000d21b870 r28: 0x00000000a0001fa4 r29: 0x000000000d21b854 r30: 0x00000000a0001fa4 r31: 0x00000000900308dc }
ThreadName = ViewScheduler
Call_Stack_Thread_5
HIToolbox: _NextEventInQueue + 0x4 (SP: 0xf03057b0 PC: 0x9335b838)
HIToolbox: _FindSpecificEventInQueue + 0x34 (SP: 0xf0305800 PC: 0x9336930c)
CINEMA 4D: __ZN10NoNoThread9TestBreakEv + 0x50 (SP: 0xf0305860 PC: 0x87dea0)
CINEMA 4D: __ZN13ViewScheduler9TestBreakEv + 0xb0 (SP: 0xf03058b0 PC: 0x180b60)
dpit.dylib: __ZN5Fluid6Solver10AdvectGridERKiRKfRNS_13VelocityCacheEPNS_5EGridIfEES9_RKNS_8Vector3DESC_S9_ + 0x36c (SP: 0xf0305900 PC: 0xc30086c)
dpit.dylib: __ZN5Fluid6Solver19GridStepAEiRKfRNS_13VelocityCacheEPNS_5EGridIfEES7_RKNS_8VecInt3DESA_ + 0x134 (SP: 0xf0305ca0 PC: 0xc303514)
CINEMA 4D: __ZN14MPPluginThread4DoItEv + 0x1c (SP: 0xf0305d50 PC: 0x90a26c)
CINEMA 4D: __ZN10BaseThread6ActionEv + 0xe8 (SP: 0xf0305d90 PC: 0x87cb98)
CINEMA 4D: __Z11BeginThreadPv + 0x10 (SP: 0xf0305df0 PC: 0x87cc50)
libSystem.B.dylib: __pthread_body + 0x60 (SP: 0xf0305e30 PC: 0x9002b908)
srr0: 0x000000009335b838 srr1: 0x000000000000f030 vrsave: 0x0000000000000000 cr: 0x0000000024000018 xer: 0x0000000000000000 lr: 0x000000009335b780 ctr: 0x00000000900011c8 r0: 0x000000000300d130 r1: 0x00000000f03057b0 r2: 0x000000000300d000 r3: 0x000000000300d000 r4: 0x0000000000000000 r5: 0x00000000000003e8 r6: 0x00000000ffffffff r7: 0x0000000000000006 r8: 0x000000000df02973 r9: 0x000000000300d010 r10: 0x000000000df0096f r11: 0x000000000300d250 r12: 0x00000000900011c8 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000 r16: 0x0000000000000000 r17: 0x0000000000000000 r18: 0x00000000f0305cec r19: 0x00000000bfffc128 r20: 0x0000000000000014 r21: 0x0000000000000000 r22: 0x0000000000000000 r23: 0x0000000000000000 r24: 0x000000000d9dba24 r25: 0x000000000d9db964 r26: 0x0000000000000000 r27: 0x0000000000000000 r28: 0x000000000087c900 r29: 0x000000000300d000 r30: 0x000000000de4b7c0 r31: 0x000000009335b700 }
Loaded_Modules[...]
On 18/02/2010 at 11:24, xxxxxxxx wrote:
Just to confirm it´s a real PPC G5.
On 18/02/2010 at 13:11, xxxxxxxx wrote:
oh just as an addendum, my tester says he has 10.4.11 installed for sure unlike the bug report says.
On 18/02/2010 at 14:26, xxxxxxxx wrote:
Originally posted by xxxxxxxx Originally posted by xxxxxxxx The snipet is too short (and can't be decoded in this shortened form). I just see that this is crashing inside of the OS (most probably stack trashed) and that this is no release version. thanks. Do you mean the os is no release version? (Please find the whole bug report at the end of this message)
Ah, forget that remark. I assumed you're using r11.5 in that test (and the crashlog didn't look as expected) and not r10.111 as your user did (unfortunately I can't decode that old version's crashlog yet). He 's using a real G5 (dual core), which can have up to 128 instructions in flight (per core) and as there are several threads of your plugin active, I suspect you have a threading issue and not a problem with the ppc byte order.
Are these threads sharing data?
Most likely you will not be able to track that down on a single or dual G4 (e.g.: we had a threading problem in the renderer in r11.5 on quad G5s and had only be able to reproduce that on a real Quad G5 with release code and some specific scenes). Can be a though job to track that down...
What 's really strange is the OS version on your customers Mac. The crashreport gets the information from the OS (and if that on says 10.4.9, then it is 10.4.9).
On 19/02/2010 at 05:59, xxxxxxxx wrote:
Originally posted by xxxxxxxx Ah, forget that remark. I assumed you're using r11.5 in that test (and the crashlog didn't look as expected) and not r10.111 as your user did (unfortunately I can't decode that old version's crashlog yet). He 's using a real G5 (dual core), which can have up to 128 instructions in flight (per core) and as there are several threads of your plugin active, I suspect you have a threading issue and not a problem with the ppc byte order. Are these threads sharing data?
Among each other? Nope, no communication among them. They all work on a previously allocated array, however none of them accesses the same data. Each cpu processes a certain range of that array. But I think you are right it´s not a PPC issue anymore because today he reported the same problem on his Intel machine (which btw. also shows 10.4.9 in the bug report but the user says he´s got 10.4.11 on it). However, he is the only one who can reproduce the crashes. All my other MAC testers including me cannot reproduce the problem (I also checked on my Intel based MAC). All runs fine and stable for the rest of us. hmm...
Indeed! Could this be a potential source for the problem? I mean, maybe during an OS update, could this have screwed up his system somehow? And maybe that´s why his system shows a different version number although the update probably didn´t succeed but changed the version number already? Just a wild guess but it´s really strange I cannot find any culprit in code and noone can reproduce this but that one tester.
argh, mist. :) Don´t have a quad G5 of course. Hmm, ok. Then it´s indeed getting hard.
On 20/02/2010 at 02:00, xxxxxxxx wrote:
Originally posted by xxxxxxxx ]argh, mist. :) Don´t have a quad G5 of course. Hmm, ok. Then it´s indeed getting hard.
]argh, mist. :) Don´t have a quad G5 of course. Hmm, ok. Then it´s indeed getting hard.
Well you don't have to have a Quad in your case, as it seems to be reproducable on Duals too (but in our case it was Quad G5 only).
What really sounds a little bit fishy is difference between the OS version reported and the OS version claimed by your two customers. If the OS reports 10.4.9 but they have applied the 10.4.11 update (and can't apply it anymore via software update), it 's likely, that the update wasn't processed fully.
They might try to download ( http://www.apple.com/downloads/macosx/apple/macosx_updates/macosx10411comboupdateppc.html or http://www.apple.com/downloads/macosx/apple/macosx_updates/macosx10411comboupdateintel.html) and apply Apple's 10.4.11 combo updater again or - if that 's possible - I'd ask them to make a clean OS installation on a second partition (or external drive), update that with the OS X combo updater and then check it with your plugin again.
On 20/02/2010 at 05:29, xxxxxxxx wrote:
Jap, that´s exactly what I adviced my customer now to do. :) I report back here for completeness if that helped getting rid of the issue.
thx!