SlimDX / slimdx

Automatically exported from code.google.com/p/slimdx
MIT License
96 stars 39 forks source link

Frame::LoadHierarchyFromX throws an AccessViolationException #140

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Frame::LoadHierarchyFromX throws an AccessViolationException

The first error occures inside the implementation of 
Direct3D9.IAllocateHierarchy.CreateMeshContainer when 
SkinInfo.ConvertToIndexedBlendedMesh is called. It doesn't check for 
adjacencyOut being NULL or empty. However, even when this is fixed another 
AccessViolationException is thrown later on (outside of 
ConvertToIndexedBlendedMesh). I haven't tracked this down further yet.

It would also be great to have something like the SimpleAnimation sample 
for SlimDX since the implementation is a littlebit different from MDX.

Original issue reported on code.google.com by hazar...@gmx.net on 18 Dec 2007 at 5:24

GoogleCodeExporter commented 9 years ago
OK, two issues here. First, we would love to provide every sample under the 
sun, and
plan to do so eventually, but for now if you want one you have to write it 
yourself,
as we are just too busy with the main project.

Second, the AccessViolation issue was reported on the GDNet forums, but has not 
yet
been tracked down. It appears that this may happen on MDX as well. If this 
could be
tested and confirmed, we would much appreciate it. Also, any testing and 
debugging
you could do to track this down would be a great help. My guess is that it has 
to do
with some parameter being passed as NULL to the DX function, which tries to 
access it
and therefore an AccessViolation occurs, which .NET will wrap into an exception 
for us.

Original comment by Mike.Popoloski on 18 Dec 2007 at 8:03

GoogleCodeExporter commented 9 years ago
(I was the one who posted the similar issue on GDNet) It's a weird problem. I 
have 
just come back to the project with this in it, and still have no clear answers 
- 
except my prob has mutated from the first poster's - I get a 
SlimDX.GraphicsException now when CheckHResult fails with LoadHierarchyFromX. 
The 
AccessViolation vanished (after I think fixing the adjacencyOut thing, but I'll 
see 
if I can reproduce the exception to be sure).

'My guess is that it has to do
with some parameter being passed as NULL to the DX function, which tries to 
access it
and therefore an AccessViolation occurs' Wouldn't that be more a 
NullReferenceException?

'It appears that this may happen on MDX as well' I've never experienced it in 
MDX, 
but others may have. 
I'll see if I can make any progress with this.

Original comment by Luke124...@googlemail.com on 19 Dec 2007 at 12:11

GoogleCodeExporter commented 9 years ago
I haven't had such problems in MDX. All parameters passed as NULL are the 
AnimationController (which is created in the function) and the userDataLoader, 
which 
can be NULL (at least in MDX).

Original comment by hazar...@gmx.net on 19 Dec 2007 at 12:26

GoogleCodeExporter commented 9 years ago
It would be a NullReferenceException if managed code attempted to access a null
pointer. However, if the unmanaged code tries to access a NULL pointer, I 
believe an
AccessViolation will occur, which .NET will wrap for us inside an
AccessViolationException. That is my guess anyway.

Original comment by Mike.Popoloski on 19 Dec 2007 at 2:08

GoogleCodeExporter commented 9 years ago
Ah - yes, MSDN does say that an AccessViolationException is 'when the code 
attempts 
to read or write to memory that has not been allocated, or to which it does not 
have 
access' and can only happen in unmanaged code. But myGraphicsException is a 
SlimDX 
exception - does this wrap a useful DirectX error code, or something like that?

Original comment by Luke124...@googlemail.com on 19 Dec 2007 at 11:45

GoogleCodeExporter commented 9 years ago
Well the first thing to sort out (it may be the source of the prob) is that 
indeed 
if you give an empty array of integers to ConvertToIndexedBlendedMesh it won't 
fill 
it out for you, it will just complain with an AccessViolation (or as I seem to 
experience a NullReference) which is illogical since it's meant to be empty.

'pin_ptr<int> pinnedAdjIn = &adjacencyIn[0];
        pin_ptr<int> pinnedAdjOut = &adjacencyOut[0];

        HRESULT hr = m_Pointer->ConvertToBlendedMesh( mesh->MeshPointer, 0, 
reinterpret_cast<const DWORD*>( pinnedAdjIn ),
            reinterpret_cast<DWORD*>( pinnedAdjOut ), NULL, NULL, &mvi, 
&bcc, &bct, &result );
        GraphicsException::CheckHResult( hr );'

Is the AdOut actually being stored in the pointer supplied by the user here?

Original comment by Luke124...@googlemail.com on 19 Dec 2007 at 8:58

GoogleCodeExporter commented 9 years ago
I'm not sure what you are asking here. I can't seem to find anything wrong with 
the
code snippet. Have you tried stepping through it and seeing exactly where the
exception is thrown and the values of the variables around it? 

Also, either of you can send me your project all zipped up by email and I will 
take a
look at it from this end.

Original comment by primeval...@gmail.com on 20 Dec 2007 at 11:30

GoogleCodeExporter commented 9 years ago
Er, that we me.

Original comment by Mike.Popoloski on 20 Dec 2007 at 10:05

GoogleCodeExporter commented 9 years ago
What I meant was the adjacencyOut should be an output variable passed by 
reference, 
and should be null when you pass it in. Now, the parameter [Out] array<int>^ 
adjacencyOut of ConvertToIndexedBlendedMesh seems to suggest that everything is 
fine 
but Visual Studio expects a non null (is this the right term?) array of ints - 
which 
is why I thought that maybe something was wrong here.

Anyway I'll see if I can tidy up my code + put it into c# to send across.

Original comment by Luke124...@googlemail.com on 21 Dec 2007 at 12:06

GoogleCodeExporter commented 9 years ago
Hmmm, just on a hunch I checked the code again and may have found the problem, 
or at
least one of them. Try changing any case of "[Out] array<X>^" in the SkinInfo
functions to "[Out] array<X>^%". For some reason, it looks like I left the the 
% off
of some of the parameters.

I'll have an update out soon if you don't feel like messing with it. If you do,
remember to change both the header and source file to have the same signatures,
although that is all the changes that are needed.

Original comment by Mike.Popoloski on 21 Dec 2007 at 11:28

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Does anyone else see this? SkinInfo.ConvertToIndexBlendMesh is trying to pin a 
pointer to an array to a null array is that possible?

GrasshopperDotNet

Original comment by fivedesi...@hotmail.com on 22 Dec 2007 at 1:04

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Well, I fixed that % thing and it definitely did *something* as I got my 
AccessViolation back - but it is still throwing a null reference with an empty 
adjacencyOut variable passed in, which is just silly since it has to be empty.

edit... I actually think now that adjOut should be an 'in' variable which just 
complicates things.

Original comment by Luke124...@googlemail.com on 22 Dec 2007 at 6:31

GoogleCodeExporter commented 9 years ago
I've got the .zip. what email address should I send it to?

Original comment by Luke124...@googlemail.com on 24 Dec 2007 at 3:59

GoogleCodeExporter commented 9 years ago
mike.popoloski@(NO_SPAM_MONKEYS)gmail.com

Original comment by Mike.Popoloski on 24 Dec 2007 at 8:07

GoogleCodeExporter commented 9 years ago
Ok. This is long so I'll try to make it clear and to the point. Found quite a 
few 
bugs during my resent endeavour to finish the Skinned Mesh sample.

[Bug 01]  ExtendedMaterial::ToUnmanaged()
a null or empty texture filename, causes a zero-length array in 'nameBytes'.

[Solution 01] ExtendedMaterial::ToUnmanaged()
check for null or empty stirng.

[Bug 02] IAllocateHierarchyShim::CreateFrame()
*ppNewFrame = frame->Pointer;  

'AccessViolation Exception' thrown
frame  is local managed variable and when it is GC you loose its unmanaged 
member  'Pointer'; 

[Solution 02]
*ppNewFrame = new D3DXFRAME(*(frame->Pointer));

[Bug 03] IAllocateHierarchyShim::CreateMeshContainer(), doesn't fill the 
*ppNewMeshContainer;

[Solution 03] 
*ppNewMeshContainer = new D3DXMESHCONTAINER(*(meshContainer->Pointer));

After making all these changes to my local copy. I finally get a valid Frame 
from 
Frame::LoadHierarchyFromX(), with the correct frames and meshcontainers filled;
No Exceptions thrown, but when I try to cast it to my derived class D3D9Frame, 
a new 
exception is thrown.

Frame frame = Frame::LoadHierarchyFromX();
D3D9Frame root = (D3D9Frame)frame;         <--- Throws an exception. 
"Unable to cast object of type 'SlimDX.Direct3D9.Frame' to 
type 'SkinnedMeshSample.D3D9Frame'."

D3D9Frame root = frame as D3D9Frame,   <--- No exception, but root is null even 
though frame is valid. 

Any Ideas?

Thanks, GrasshopperDotNet

Original comment by fivedesi...@hotmail.com on 28 Dec 2007 at 11:18

GoogleCodeExporter commented 9 years ago
well done, you got much further than I did. I'll try this out now.

Frame frame = Frame::LoadHierarchyFromX();
D3D9Frame root = (D3D9Frame)frame;         <--- Throws an exception. 

"Unable to cast object of type 'SlimDX.Direct3D9.Frame' to 
type 'SkinnedMeshSample.D3D9Frame'."

D3D9Frame root = frame as D3D9Frame,   <--- No exception, but root is null even 
though frame is valid. 

The second line does not throw an exception becuase the C# 'as' keyword simply 
tries 
a cast and returns null if it fails, so it's the same problem - whatever that 
happens to be.

Original comment by Luke124...@googlemail.com on 28 Dec 2007 at 5:45

GoogleCodeExporter commented 9 years ago
Thanks, glad to see others working on the same problem.

Original comment by fivedesi...@hotmail.com on 28 Dec 2007 at 8:29

GoogleCodeExporter commented 9 years ago
Hey guys, good job on making it this far. I've been rather busy lately, and I 
just
got back from vacation, but it seems that this has become a rather important 
issue so
I will probably be devoting my full attention to it in the next few days.

Original comment by Mike.Popoloski on 30 Dec 2007 at 9:35

GoogleCodeExporter commented 9 years ago
OK, the problem has been fixed. Good work on this everybody.

Original comment by Mike.Popoloski on 4 Jan 2008 at 11:30