4. 32Bit Mac OSX issue

32Bit Mac OSX issue

  • H

    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

    0
  • H

    THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    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

    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

    0
  • H

    THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    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

    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

    0
  • H

    THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    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) : ...

    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.

    Best regards,

    Wilfried Behne

    0
  • H

    THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    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

    0
  • H

    THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    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)

    0
  • H

    THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    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 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.

    Best regards,

    Wilfried Behne

    0
  • H

    THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    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)

    Was this an emulation or a real PPC cpu (which one? G5, G4 MP?)?

    afaik it´s a real G5 PPC cpu but I´ll ask my tester.

    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.

    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:    __ZN5Fluid6Solver10AdvectGridERKiRKfRNS_13VelocityCacheEPNS_5EGridIfEES9_RKNS_8Vector3DESC_S9_ + 0x36c (SP: 0xf0284900 PC: 0xc30086c)

    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)

    Registers

    {

    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)

    Registers

    {

    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)

    Registers

    {

    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
              }

    Variables

    {

    ThreadName = RedrawThread BP

    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_3

    {

    libSystem.B.dylib:    _semaphore_wait_signal_trap + 0x8 [Bad_Frame] (SP: 0x0 PC: 0x9002bfc8)

    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)

    Registers

    {

    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
              }

    Variables

    {

    ThreadName = ViewScheduler

    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_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)

    Registers

    {

    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
              }

    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

    }

    }

    }

    Loaded_Modules[...]

    0
  • H

    THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 18/02/2010 at 11:24, xxxxxxxx wrote:

    Just to confirm it´s a real PPC G5.

    0
  • H

    THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    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.

    0
  • H

    THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    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).

    Best regards,

    Wilfried Behne

    0
  • H

    THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    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...

    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).

    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.

    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...

    argh, mist. :) Don´t have a quad G5 of course. Hmm, ok. Then it´s indeed getting hard.

    0
  • H

    THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    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.

    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.

    Best regards,

    Wilfried Behne

    0
  • H

    THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    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!

    0
Log in to reply