32Bit Mac OSX issue

Helper

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

Helper

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

Helper

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

Helper

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

Helper

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

Helper

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)

Helper

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

Helper

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

Helper

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.

Helper

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.

Helper

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

Helper

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.

Helper

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

Helper

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!