Good way to debug ODN?


06-04-2006 03:03:34

I'm trying to figure out the best way to debug a few hard to track down bugs in my app... For instance, I intermittently get the error:

### Exception Attempted to read or write protected memory. This is often an ind
ication that other memory is corrupt.
at OgreDotNet.OgreBindingsPINVOKE.Root_StartRendering(HandleRef jarg1)
at OgreDotNet.Root.StartRendering()
at Outcast.BaseSystem.BaseApplication.Start() in c:\dev\mmo_net\Outcast\Outca
st.BaseSystem\BaseApplication.cs:line 82
at Outcast.Client.Application.Main(String[] args) in c:\dev\mmo_net\Outcast\O
utcast.Client\Application.cs:line 170

Which I am pretty sure is being thrown because something I am trying to render must be getting invalidated in my app somewhere... the problem is I have a lot of state-switching going on, so the CEGUI interface items are being created/destroyed between states and such... Is there a decent way to debug things like this? Or am I out of luck since all the code is stuck in the binding dlls?

On a side note, thanks for all the help I've been getting on the forums with my recent problems, hopefully I'll be answering questions rather than asking them soon :D


06-04-2006 10:57:14

Hi ender81x,

This is my number one concern about ODN.

I mean, heck, if we’re going to be stopped at the wrapper PINVOKE calls with errors like this then we might as well be chasing memory leaks in the original cpp Ogre.

We need to find a better way to debug past the wrapper layer into the underling dll. I have been doing a little bit of research on this but I haven’t found a good solution yet.

What I’ve learned so far is vague, and it is only from message board talk, so it might not be accurate… please elaborate and correct if wrong.

1. You can debug dlls by setting break points in the Breakpoint Window. Unfortunately I am using VS C# Express Ed. So I couldn’t look into this further.

2. You can somehow attach to the errant process with the debugger. (But somehow I don’t think you’ll be able to step through the code…)

Now, I know that isn’t much, but it might give us a starting point to work from.

I am VERY interested in how you all are overcoming this challenge and I hope we can come up with an elegant solution.

I am also interested in how often this kind of error occurs.

If it is often, and we can’t find a good solution, I am going to be hard pressed not to find a different engine (or just go, *I shudder thinking about it*, back to cpp Ogre).

I think I would have to go to Axiom before I went cpp Ogre… but there is some interesting work being done by Bekas on a Pseudo wrapper with C++/CLI. It is being addressed in this thread: I am watching it closely.

Now, with that said, I am still working hard to get ODN running and hope to find a good debug solution. Anyone out there have any ideas on this?




06-04-2006 16:33:16

The best advice I can give you is that anywhere you use the new statement to create an object in one of the Bindings dlls then somehow add it to the scene make sure you keep a reference to the object for as long as it is to live in the scene. With any SharedPtr that is returned from a function call, like MeshManager.GetSingleton().CreatePlane, you will need to call MeshPtr.SetNull() when you done with the SharedPtr. Also any call that creates an object (not SharedPtrs) in a Bindings dlls checks the code in the proxy class to see how it creates the instance of the class. Look to see when it creates the class if it sends a true or false as the second parameter to the class’s constructor. A true tells the swig generated code to delete the c++ object when it is disposed. A false means that the class does not delete the c++ object when it is disposed.

As for debugging the only way I know to debug past the PInvoks are to add logging code in the bindings dll just send debug text to std::cout, or in the Ogre dlls.


18-10-2006 02:32:35

Rasta, those seem like some pretty important tips; maybe important enough for a sticky, with some sample code showing what you mean.

The first two tips of yours I followed and can mentally associate w/ code I've seen so far, but the third I haven't run into yet.