Jump to content

alphabit

Members
  • Posts

    9
  • Joined

  • Last visited

Posts posted by alphabit

  1. That's great news, Lazlo. Just tried it and it works as expected :-) Sometimes It can be so simple... after you know how it works :lol:

     

    I see that at the end it was a matter of keeping the delegate alive so that the GC wouldn't collect it. Since the delegate is now declared at class scope, it holds a valid reference that doesn't get GCed. Weird things happen, but in the end it has its good sides... If we ever will see such behavior again, we know what could be done to workaround it!

     

    Thank you for figuring this out.

     

    Cheers.

  2. Hi Lazlo,

     

    thanks for taking the time to investigate the problem. I see, it's one of the harder stuff to get rid off :)

     

    I also took some time these days to try to understand what could be the cause, but tbh I didn't dive into that much. Although I've collected a couple of links that I think might be helpful:

     

    Delegate Keep alive

    Marshal.GetFunctionPointerForDelegate

    Marshaling between Managed and Unmanaged Code

    Default Marshaling for Delegates

    Unmanaged Callbacks in .NET 2.0

    How to: Marshal Callbacks and Delegates Using C++ Interop

    Pinning a delegate within a struct before passing to unmanaged code

    Unmanaged function pointers / Marshal.GetFunctionPointerForDelegate

     

    I've been reading your post at stackoverflow and that you managed to run the wrapper crash free while in debug build mode. Could it be that it's a matter of build optimization (Build - Optimize Code) that makes the difference in this case? It's not a practicable solution (I don't know if it would even fit this case), but maybe marking some specific methods to not be optimized could be a raw idea of a workaround? I was thinking about something like: [MethodImpl( MethodImplOptions.NoInlining | MethodImplOptions.NoOptimization )].

     

    I hope the resources above help you a little bit...

     

    Best regards

  3. Hello and apologizes for the long post,

     

    I keep receiving the following exception while running a LE2 based C# application:

     

    CallbackOnCollectedDelegate

    A callback was made on a garbage collected delegate of type 
    'Leadwerks!Leadwerks.Core+EntityCollisionCallback::Invoke'. 
    
    This may cause application crashes, corruption and data loss. When passing delegates to unmanaged code, 
    they must be kept alive by the managed application until it is guaranteed that they will never be called. 

     

    According to the MSDN ( see http://msdn.microsoft.com/en-us/library/43yky316%28v=VS.100%29.aspx) access violations occur when attempting to

    call into managed code through function pointers that were obtained from managed delegates.

     

    These failures, while not common language runtime (CLR) bugs, may appear to be so because the access violation occurs in the CLR code.

     

    The failure is not consistent; sometimes the call on the function pointer succeeds and sometimes it fails.

    The failure might occur only under heavy load or on a random number of attempts (happens to me!).

     

    This error is thrown regardless of which LE version I try to wrap (2.32, 2.40).

     

    What I try is to track a collision on a sphere body like:

    sphereBody.Callback(SphereCollisionCallback, (int)EntityCallbackType.Collision);

     

    and simply handle that event:

    private void SphereCollisionCallback(IntPtr _entity1, IntPtr _entity2, Vector3 _position, Vector3 _normal, Vector3 _force, float speed){
    ...}
    

     

    The wrapped LE call that leads to the exception is:

    [DllImport(EngineDll, EntryPoint = "UpdateFramework", CallingConvention = CallingConvention.StdCall)]
    public static extern void UpdateFramework();
    

     

    Any special voodoo GC stuff I should consider? Do I have to configure something additionally in the Project settings? Is there anybody having similar experience?

    The implementation which shows the mentioned behaviour is available on my other post at MyOtherPost.

     

    Meanwhile I left the 2.0 Header because there I can't event use the CollisionCallback.

    The old headers don't work either (same problem as my implementation here).

     

    Atm, I practically cannot do anything decent in C# with LE which involves collisions, so any help and pointings into the right direction are very much appreciated :rolleyes:

     

    Edit:

    Just an additional technical note from an exception trace

    This happens when the exception occurs in the engine.dll - Exception Tracing
    
    First chance exception 0xC0000005 ACCESS_VIOLATION occurred at 0x001E2B9D, read of address 0x00000004 at 0x001E2B9D	788
      0x001E2B9D 	788	
      0x00DF0C3D 	788	
      0x1010E814 engine.dll	788	
      0x101121BC engine.dll	788	
      0x1015A10C engine.dll	788	
      0x1015A780 engine.dll	788	
      0x1019005E UpdateFramework + 0x12 in engine.dll	788	
      0x001E5D33 	788	
      0x001E5D97 	788	
      0x001E04B3 	788	
    
    First chance exception 0xC000001D ILLEGAL_INSTRUCTION occurred at 0x00DF0CD0	788
      0x00DF0CD0 	788	
      0x101121BC engine.dll	788	
      0x1015A0CA engine.dll	788	
      0x1015A780 engine.dll	788	
      0x1019005E UpdateFramework + 0x12 in engine.dll	788	
      0x001E5D33 	788	
      0x001E5D97 	788	
      0x001E04B3 	788	
      0x001E010B 	788	
      0x001E00A6 	788	
    
    Module loaded: C:\Windows\SysWOW64\version.dll;  Base address: 0x75320000  Size: 21504 Version: 6.1.7600.16385	788
    Module loaded: C:\Windows\Microsoft.NET\Framework\v4.0.30319\diasymreader.dll;  Base address: 0x53940000  Size: 688472 Version: 10.0.30319.1	788
    Second chance exception 0xC000001D ILLEGAL_INSTRUCTION occurred at 0x00DF0CD0	788

     

    Best regards

     

    ps: I am using Visual Studio 2010 Professional on Windows 7 Ultimate x64 and the project is based on .NET 4.0

  4. FatalExecutionEngineError

     

    I have attached a small test class that should reproduce the behaviour. Simply call it quick and dirty using:

     

    new TestCollisionCallback().RunTest();

     

     

    Edit:

    And press the "U" Key once or a couple of times, so that you see a sphere jumping up and falling down (I admit, it's way too fast).

    As soon as collision is detected, the error occurs.

     

    Best regards

     

     

     

    TestCollisionCallback.txt

  5. Hi and great work. It's good to see solid support for C# and continuity in development :) ... although I'm struggling with event callbacks, to be precise with the collision callback!

     

    I don't get it working. I always receive a FatalExecutionEngineError which reads as follows:

     

    The runtime has encountered a fatal error. The address of the error was at 0x662cee12, on thread 0x1950. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.

     

    Some code to it:

    var groundBody = new Body.Box(10, 0.1f, 5) {CollisionType = 1};
    var ground = new Mesh.Cube { Color = Leadwerks.Color.SandyBrown, Scale = { X = 5, Y = 0.2f, Z = 2 }, Parent = groundBody };
    
    groundBody.Position = new Vector3( 0, -0.5f, -1 );
    
    var sphereBody = new Body.Sphere(0.045f) {  Mass = 1, CollisionType = 1, Elasticity = 2f};
    var sphere = new Mesh.Sphere { Scale = new Vector3(0.05f, 0.05f, 0.05f), Parent = sphereBody, Position = sphereBody.Position};
    
    sphereBody.Position = new Vector3(0, -0.65f, 0);
    
    sphereBody.Callback(sphereCollisionCallback, (int)EntityCallbackType.Collision);

     

    The main loop:

    while (!Window.HasRequestedClose)
    {
         if ( Leadwerks.Keyboard.KeyHit(Key.U)) {
               sphereBody.Velocity = sphereBody.CalculateVelocity(new Vector3(0, 1, 0), 3.125f);
         }
    
        Timing.Update();
        Framework.Update();
        Framework.Render();
    
        Leadwerks.Graphics.Flip();
    }
    

     

    And the callback itself:

     

            public void sphereCollisionCallback(IntPtr entity1, IntPtr entity2, Vector3 _position, Vector3 _normal, Vector3 _force, float speed) {
               Core.HideEntity(entity2);
           }

     

    Is this a bug in the implementation of the headers when handling callbacks / delegates internally?

    Did I make some mistake somewhere?

     

    I am using Visual Studio 2010 Prof, Windows 7 x64 and the latest C# Headers 2.0 from Aug. 26th.

     

    Glad for any help I can get ...

     

    Best regards

    post-1460-019185200 1283137209_thumb.png

  6. Hi all...

     

    ... so what does it mean in the end? I.e.: I have purchased long time ago a license through TGC at the early beginnings of LE. So I have SDKs until 2.28?

    And what if I would like to upgrade to the new, do I have to pay the full price? So I can't use decent c# headers on my old SDKs?

     

    It's a little bit confusing with the version numbering although.

     

    Thanx for any correct pointings.

     

    Cheers.

×
×
  • Create New...