Those using VS 2005 pro, we need your help

rastaman

02-06-2006 15:57:34

If you have VS2005 express follow the wiki instructions and on the part "Using the OgreDotNet Wrapper in your project" use release mode.
http://www.ogre3d.org/wiki/index.php/Installing_OgreDotNet#Using_the_OgreDotNet_Wrapper_in_your_project

With the Express version Debug mode will not work because the Bindings dlls that Visual c++ 2005 express makes will not run outside the IDE. There may be some project setting that needs to be changed to allow this. But I have not figure it out yet; I've comparing OgreMain settings to OgreBindings but could not find anything significant.

If anyone has VS2005 pro please build the c++ Bindings dlls so that someone with express can test it out to see if it’s just VC++ express.

Avalon

02-06-2006 22:34:36

Took me longer than planned as I had to correct all the inconsistent line endings in many (too many to list) of the .i files. (They were in MAC format??).

However when I had done that, and therefore made SWIG stop chucking errors at me, OgreBindings and CeguiBindings build fine. GangstaBindings does not build a s i dont have gansta installed so the $(ganstawrapper) variable is undefined.

OgreBindings_Cegui however fails to build with just the message with no file reference:

error PRJ0019: A tool returned an error code from "Performing Custom Build Step"

If you need either of these built I would be happy to do so provided you can help me solve the problem with OgreBindings_Cegui

Here are the DLLs (built with VS.net 2005 Pro):

http://storage.na3alf6.net/OgreDotNet/vs2005pro_build_bindings.zip

rastaman

02-06-2006 23:21:47

Avalon, thanks :)
I will try it out with just the OgreBidnings.

I think the problem with OgreBindings_Cegui is that the OgreSDK change location of OgreCEGUI*.h to ogresdk/samples/include. Just copy them to ogresdk/include.

I also did some google searches and came up with 2 things to check in the project settings.
1 make sure the linker command line does not have "/manafest:no" in it.
2 try linking staticly to the CRT dll. Runtime Library=Multi-threaded Debug (/MTd).
I will also try those out for express.

Avalon

02-06-2006 23:31:44

You were right, it was the location of the OgreCEGUI*.h header files that was the problem. I moved them in the the root includes and OgreBindings_Cegui built correctly:

http://storage.na3alf6.net/OgreDotNet/OgreBindings_Cegui.zip

I would have been nice if SWIG had given a bit more feedback as to what the problem is, At least now this problem is solved i might be able to build the whole pg OgreDotNet myself rather than using the precompiled Binaries.

Since that changed wokred fine I didnt look into the other suggests. I will if you want though.

Also did you want me to build GangstaBindings by installing Gansta? you'll have to tell me where to get this (I presume a quick google would tell me though).

I've Just had a thought though.... did you want me to build these as with Debug Configuration? I built them with Release....

rastaman

02-06-2006 23:51:20

:lol: yes debug

well I'm getting the same thing with the first dlls you posted

C:\Dev\ogre\odnt\ogredotnet\Bin\Debug>demoskybox
### Exception The type initializer for 'OgreDotNet.OgreBindingsPINVOKE' threw an exception.
OgreDotNet
at OgreDotNet.OgreBindingsPINVOKE.new_Root__SWIG_3()
at OgreDotNet.Root..ctor()
at OgreDotNet.ExampleApplication.Setup()
at OgreDotNet.ExampleApplication.Start()
at SkyBox.SkyBoxApplication.Main(String[] args)
### Exception in Dispose Object reference not set to an instance of an object.
OgreDotNet
at OgreDotNet.ExampleApplication.Dispose()
at SkyBox.SkyBoxApplication.Main(String[] args)


edit :
we don't need test with gangsta. here is the link http://sourceforge.net/projects/gangsta/

Avalon

02-06-2006 23:54:09

Yeah sorry about that - I'm just rebuilding as debug. :oops:

Avalon

03-06-2006 00:11:23

OK The debug version are up in the original Zip Now, Sorry about that:

http://storage.na3alf6.net/OgreDotNet/vs2005pro_build_bindings.zip

I have Gansta installed and the Enviroment variables setup. Now ive just got to build Gansta Before I can build the Bindings.

EDIT: I cant get gangsta to build at the momoment, It is complaining about not being able to find Ogre.h but I've Checke the Linker and the correct Folder is linked (D:\OgreSDK\include). Im not really a C++ Programmer so I dont really know how to solve this, Its probably me being stupid somewhere alone the line.

rastaman

03-06-2006 00:54:55

OK The debug version are up in the original Zip Now, Sorry about that:
cool ill try it again.


EDIT: I cant get gangsta to build at the momoment, It is complaining about not being able to find Ogre.h but I've Checke the Linker and the correct Folder is linked (D:\OgreSDK\include). Im not really a C++ Programmer so I dont really know how to solve this, Its probably me being stupid somewhere alone the line.
for the linking you need to use the lib dir (D:\OgreSDK\lib) :)

rastaman

03-06-2006 00:58:16

the zip seems to be invalid I get this message form winzip

End-of-central-directory signature not found. Either this file is not a Zip file, or it constitutes one disk of a multi-part Zip file.

Avalon

03-06-2006 01:18:56

Try now.

It seems my FTP client decided to give up halfway the first time :).

On the Subject of Gangsta, I've also tried, D:\OgreSDK\lib with no luck. This is why I program in .net rather than C++ :)

rastaman

03-06-2006 01:47:59

:( no luck still same error with new_root and a messagebox about msvcp80d.dll. I found that dll and put it in the dir. Then it asked about msvcr80d.dll, found that and copyed it local. Then it gave me



edit: i also tryed the static link thing with vc8 express but same results :(

Avalon

03-06-2006 12:04:27

I think can solve that one for you... try putting this is the directory with the exe:

http://storage.na3alf6.net/OgreDotNet/DemoSkyBox.exe.manifest

Hopefully this should fix it, though it might not as that manifest file is based on a specific combination. You will also need to move the ms*.dll files you put in there back out as that is not a supported solution.

rastaman

03-06-2006 15:54:04

yes it works now :)

But where did you get that manifest? I don't see one when i build DemoSkyBox, not under bin or obj.


Hopefully this should fix it, though it might not as that manifest file is based on a specific combination. You will also need to move the ms*.dll files you put in there back out as that is not a supported solution.
Does that mean you made the manifest by hand?

Avalon

03-06-2006 16:33:59

Yes, I coded the manifest to link the x86 Microsoft C++ runtime Binaries. thats why I said it might not work as it *might* not work on a x64 system.

You can get VS.net to generate Manifests too but iI cant remember how of the top of my head.

Avalon

03-06-2006 17:47:02

I've done a bit more detective work and I 've now worked out why the manifest problem is occuring in the first place.

You will be pleased to know that it appears not to be a problem with ODN. The core OgreSDK debug binaries (Ogre*_d.dll), some of these files (notably OgrePlatform_d.dll) have incomplete Manifests embedded in them.

The Manifests embedded in them read:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1"></assembly>


With alot of white space afterwards (Strange). The Release binaries on the other hand have the correct manifest information:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>


With no excess Whitespace after them Which is Correct. Notice how the first one is missing the assemblyIdentity Element which links to the Microsft C++ Runtime.

The other files in which this occurs (exactly the same problem) are:

Plugin_CgProgramManger.dll
Plugin_OctreeSceneManager.dll


and in all cases it has only occured in the debug versions of these binaries.

When I corrected the Embedded Manifest information, the debug demos worked correctly without the need for an external manifest file (as they should).

However I am still unable to get the CEGUI demos working: they just crash with a generic error and nothing out of place that I can see in Ogre.log

Here are the Manifest Corrected Core OGRE Files for you to test:
http://storage.na3alf6.net/OgreDotNet/FixedManifest.zip

So it looks like this might not be an issue with the ODN Binding DLLs at all and might be something to talk to the Core OGRE team about.

rastaman

05-06-2006 23:41:02

wow thanks Avalon.

excuse the stupid question, I haven't had time to play with all the cool .net tools. But how did you get the embedded manifests?

Also what could cause this, a project property not set right?. We need to let the the Ogre team know so the next build is OK.

Avalon

06-06-2006 01:06:15

To view the embedded manifest (or any other type of embedded reasource), on the file menu, click open file and open the file in question.

When it opens it will show you a tree with folders for the different types of resources.

Embedded manifests appear under the folder "RT_MANIFEST" (runtime manifest)

As to what has caused this problem in the first, Im not sure off the top of my head and Unfortunately, I noticed your reply just as I was on my way to bed so I will have a look into what may have caused it tommorrow ( i will have to look at the OgreSDK project properties).
I'm not sure that this is the problem though as the large ammount of whitespace afterwards is highly unusual and makes me wonder if it was not a complier bt of some sort.
I will be able to answer this better when I build Ogre myself tommorrow.

I would like to be able to nail the cause so we can tell the core team exactly what is wrong.

However, closer to home, we still have the problem that the CEGUI demos are still not working for me, Could you check them with the manifest corrected Binaries and see if you get the same problem.

Thanks again.

rastaman

06-06-2006 05:28:10

what is the error you get? is there anything in the CEGUI.log ?

I was able to run DemoCEGUI with the dlls you posted and copy the demoskybox.exe.manifest to democegui.exe.manifest.

Avalon

06-06-2006 08:55:26

Im not at home at the moment and I stupidly forgot to enable Terminal Services so I cant look at the log right now, i'll have a look when I get back this evening. However if remember the Ogre.log file showed nothing and that the error given by the runtime was generic and gave no relavent information like the previous manifest errors were giving.

On the other note, the point of the embedded manifests is that you should no longer require the external manifest files (demoskybox.exe.mainfest or democegui.exe.manifest).

To test the fixed Binaries, could you delete both the manifest files and try the relavent demos without.

rastaman

06-06-2006 13:37:49

yes well I did run it befor i copied the manifest over and got the same error about as with demoskybox. :?

Avalon

06-06-2006 20:19:07

This is strange, the modified binaries that I posted work fine with me without the need for the manifest file, what file is it throwing the error for with you? (shouldbe listed in the console window behind the error).

demoCEGUI.log holds no information other than:

19:54:38: My new Log. Hells yeah!

and the last lines of ogre.log read:

19:54:38: Finished parsing scripts for resource group General
19:54:38: Parsing scripts for resource group Internal
19:54:38: Finished parsing scripts for resource group Internal
19:54:38: Texture: clouds.jpg: Loading 1 faces(PF_B8G8R8,256x256x1) with 8 hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,256x256x1.
19:54:39: Unregistering ResourceManager for type BspLevel

rastaman

06-06-2006 20:59:08

This is strange, the modified binaries that I posted work fine with me without the need for the manifest file, what file is it throwing the error for with you? (shouldbe listed in the console window behind the error).
Well it was late when i tried that. I'll try it again when i get home from work (2 hours).


demoCEGUI.log holds no information other than:

19:54:38: My new Log. Hells yeah!

and the last lines of ogre.log read:

19:54:38: Finished parsing scripts for resource group General
19:54:38: Parsing scripts for resource group Internal
19:54:38: Finished parsing scripts for resource group Internal
19:54:38: Texture: clouds.jpg: Loading 1 faces(PF_B8G8R8,256x256x1) with 8 hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,256x256x1.
19:54:39: Unregistering ResourceManager for type BspLevel

what about "CEGUI.log" not demoCEGUI.log
also it may just write the error message to the console.

Avalon

06-06-2006 23:38:39

There is no Cegui.log file created in the directory. It does out put an error to the console but it is just a generic PINVOKE error:

http://storage.na3alf6.net/ogredotnet/error.jpg

Unfortunately my time has been somewhat limited this evening so i havet had time to look into the root cause of the embedded manifests problem yet.

humantargetjoe

08-06-2006 13:03:10

C:\Documents and Settings\jmarion\My Documents\Visual Studio Projects\OgreInterm
ediate\OgreIntermediate\obj\Debug>demograss
### Exception The type initializer for 'OgreDotNet.OgreBindingsPINVOKE' threw an exception.
OgreDotNet
at OgreDotNet.OgreBindingsPINVOKE.new_Root__SWIG_3()
at OgreDotNet.Root..ctor()
at OgreDotNet.ExampleApplication.Setup()
at OgreDotNet.ExampleApplication.Start()
at DemoGrass.cGrass.Main(String[] args)
### Exception Object reference not set to an instance of an object.
DemoGrass
at DemoGrass.cGrass.Dispose()
at DemoGrass.cGrass.Main(String[] args)


Hmm I downloaded the dlls with the repaired manifests and stuck those in and still seem to be getting the same error that rastaman had. Think building the culprit libraries on my machine will fix the problem? For whatever reason, I can only get the PINVOKE exception data from the log, or when I run it through cmd; running it through the shell just opens and closes a console window with no exception dialog.

As an aside, this is one of my other projects set up (still uses ExampleApplication.h) with it's own relative resource paths and such so I know it works with the native C++ demos as well as the native C++ ogre apps I've built. It does the same thing when I put it in the OgreSDK\bin\debug folder.

humantargetjoe

09-06-2006 13:35:12

Building my own libraries hasn't fixed the problem...

Anyone have any ideas?

Avalon

10-06-2006 22:12:08

Hi HumanTargetJoe,

Sorry for the delay in responding to both you and rastaman, I have not abandoned this problem, However my main computer has catastrophically failed and I currently can only work on my laptop which currently does not have VS.net on it.

My computer should be functional again in the next few days when I can resume the research into this problrm and it's solution.

What I will do whe I have it working again is that I will post up my folders with all files in rather than just the corrected DLLs, then you can see exactly how I have it set up and therefore see if that same setup works for you.

Sorry again for the delay.

alphamax

11-06-2006 23:17:57

It works for me (I add the same problem)

When i compile in DEBUG mode, it works. Same in Release !!!


Thanks a lot.

I am rewriting a project from c++ to C#. Ill try some of the add ons :

DotScene, OPCode or Ode if it is better.

Edit orthograph

synaptic

12-06-2006 04:03:21

well everything compiles (VS2005 pro) i can run pretty much all of the demos in either debug or release except for DemoCEGUIMenus

a ogre.log is created, but no cegui.log from experiance with the cegui library its normal do with the window objects not being registered corretly, this is such a crazy thing since i can run the demoCEGUI so im going to leave it here for now and get some sleep with have another look in the morning when im fresh

humantargetjoe

12-06-2006 16:04:34

No sweat.

Using ExampleApplication (which the demos all do IIRC) had caused me no end of headaches when I started learning Ogre in native C++, and it seems the demos are doing it again :p.

Hopefully, seeing how you have yours set up will reveal the problem in mine.

Paladin_za

14-06-2006 14:42:52

Hi

I managed to get everything to compile, except gangsta, but I get the PINVOKE error. Has a fix for this problem been found yet?

Thanks.

humantargetjoe

14-06-2006 15:49:36

Have you rebuilt the native Ogre libraries?

Oddly enough, I've finally managed to rebuild everything, and it fixes the PINVOKE issue for the debug libraries. Unfortuneately, I now have the exact same problem, only this time with the Release libraries.

Edit:

Fixed the Release ones. For whatever reason, for me C# isn't building the wrappers properly, but C++ is. I rebuilt them with C++ 8.0 and it works fine.

Avalon

16-06-2006 10:05:13

Yes I have rebuilt the core libraries and it is now fully functional for me apart from CEGUI.

Like I sadi I will post by entire setup so you can test that as a whole, However you will have to wait until I my main computer is back on the internet (Fried Network card - still no idea how that happened).

humantargetjoe

16-06-2006 12:00:14

Well it seems were at the same place now... I can run all the non-Cegui stuff. The Cegui will compile, but all calls to the WindowManager, SceneManager, etc, all fail, including the demos in C#.

The worst part was that my compiler thought that CreateWindow was the windows method, so I had to #undef CreateWindow just to get it to compile.

Olivier

29-07-2006 21:06:22

2 cents contribution:
I use VC Express 2005
I had to recompile Ogredotnet and Ogre because of some custom modifications.

i was having same problem with pinvode and some objet construction
the were not associated with my modifications.

I recompile the whole framework a lot of times with all kind of OgreVersion (latest, 1.2.1, 1.2.0), uptodate and packaged ogredotnet source from forum, and all with no luck.

Then, the solution come:

1) I recompiled Ogre once again, but setting to 0 OGRE_DEBUG_MEMORY_MANAGER (initial value is 1):

/** Set this to 0 if you want to use the standard memory manager in Debug builds
Release builds always use the standard memory manager
*/
#define OGRE_DEBUG_MEMORY_MANAGER 0

From ogrenew/OgreMain/include/OgreConfig.h

I read somewhere (in the wiki i think) about this define, that it may cause problems when some source don't include Ogre.h (this is far beyond my knowledge).

2) I used the scripts in ogrenew/SDK to make an sdk.

I don't know which of these steps made it work (it take at lest 2 hours on my computer to go through the whole process), but now it works with all libs (debug or not).

From the comment of OgreConfig header, i believe that setting the value of OGRE_DEBUG_MEMORY_MANAGER would have effects only on debug version... So, this may be of no use.

Then, using the scripts to make the sdk seemed of no use to me, cause i was sure to do things quite perfectly without this script... Well may be not/


However, it may be of some use.
Hope it helps.

georgemarios

03-08-2006 20:12:37

may I post my (relevant) problem too?

I compiled Ogre and OgreDotNet and now I can run the debug version of demos. But there is a file named OgreLeaks.log in the same directory that sais that there are memory leaks in those apps

here is the file


----------------------------------------------------------------------------------------------------------------------------------
| Memory leak report for: 08/03/2006 21:42:26 |
----------------------------------------------------------------------------------------------------------------------------------


35 memory leaks found:

Alloc. Addr Size Addr Size BreakOn BreakOn
Number Reported Reported Actual Actual Unused Method Dealloc Realloc Allocated by
------ ---------- ---------- ---------- ---------- ---------- -------- ------- ------- ---------------------------------------------------
055915 0x0BE5EE90 0x00000020 0x0BE5EE80 0x00000040 0x00000000 new N N ??(0) ??
055916 0x0BE5F628 0x00000010 0x0BE5F618 0x00000030 0x00000000 new N N ??(0) ??
034505 0x0D250500 0x00000004 0x0D2504F0 0x00000024 0x00000000 new N N ogresharedptr.h(59) Ogre::SharedPtr<class Ogre::ControllerV
034504 0x0D2AC858 0x0000000C 0x0D2AC848 0x0000002C 0x00000000 new N N ogrebindings_wrap.cxx(75224) CSharp_new_ControllerValueFloatPtr__SWI
041800 0x0D3EE9A8 0x000000FC 0x0D3EE998 0x0000011C 0x00000000 new N N eventhandler.h(269) Ogre::EventHandler::EventHandler
041801 0x0D3EEAF0 0x00000014 0x0D3EEAE0 0x00000034 0x00000000 new N N ??(0) ??
041802 0x0D3EEB50 0x00000014 0x0D3EEB40 0x00000034 0x00000000 new N N ??(0) ??
041803 0x0D3EEBB0 0x00000014 0x0D3EEBA0 0x00000034 0x00000000 new N N ??(0) ??
041804 0x0D3EEC10 0x00000014 0x0D3EEC00 0x00000034 0x00000000 new N N ??(0) ??
041805 0x0D3EEC70 0x00000014 0x0D3EEC60 0x00000034 0x00000000 new N N ??(0) ??
041806 0x0D3EECD0 0x00000014 0x0D3EECC0 0x00000034 0x00000000 new N N ??(0) ??
041807 0x0D3EED30 0x0000000C 0x0D3EED20 0x0000002C 0x00000000 new N N ??(0) ??
041808 0x0D3EED88 0x0000000C 0x0D3EED78 0x0000002C 0x00000000 new N N ??(0) ??
041809 0x0D3EEDE0 0x00000024 0x0D3EEDD0 0x00000044 0x00000000 new N N ogreeventprocessor.cpp(105) Ogre::EventProcessor::initialise
041810 0x0D3EEE50 0x00000170 0x0D3EEE40 0x00000190 0x00000000 new N N ogrewin32platformdll.cpp(91) Ogre::createPlatformInputReader
041811 0x0D3EF010 0x00000014 0x0D3EF000 0x00000034 0x00000000 new N N ??(0) ??
041812 0x0D3EF070 0x000000B0 0x0D3EF060 0x000000D0 0x00000000 new N N ogreinput.cpp(54) Ogre::InputReader::useBufferedInput
041813 0x0D3EF170 0x00000014 0x0D3EF160 0x00000034 0x00000000 new N N ??(0) ??
041814 0x0D3EF1D0 0x00000014 0x0D3EF1C0 0x00000034 0x00000000 new N N ??(0) ??
041815 0x0D3EF230 0x00000014 0x0D3EF220 0x00000034 0x00000000 new N N ??(0) ??
041816 0x0D3EF290 0x00000014 0x0D3EF280 0x00000034 0x00000000 new N N ??(0) ??
041818 0x0D3EF590 0x00000014 0x0D3EF580 0x00000034 0x00000000 new N N ??(0) ??
041819 0x0D3EF5F0 0x00000014 0x0D3EF5E0 0x00000034 0x00000000 new N N ??(0) ??
041820 0x0D3EF650 0x00000014 0x0D3EF640 0x00000034 0x00000000 new N N ??(0) ??
052584 0x0E9261E8 0x00000018 0x0E9261D8 0x00000038 0x00000000 new N N ogrebindings_wrap.cxx(3261) Ogre_StaticGeometry_GetRegionIterator
052585 0x0E926250 0x00000008 0x0E926240 0x00000028 0x00000000 new N N ogrebindings_wrap.cxx(3263) Ogre_StaticGeometry_GetRegionIterator
052842 0x0E932A38 0x0000000C 0x0E932A28 0x0000002C 0x00000000 new N N staticgeometrysubclassproxies.h(1313) Ogre::SGLODBucketVectorIterator::getNex
052840 0x0E932AA0 0x00000018 0x0E932A90 0x00000038 0x00000000 new N N staticgeometrysubclassproxies.h(1461) Ogre::SGRegion::getLODIterator
052841 0x0E932B08 0x00000008 0x0E932AF8 0x00000028 0x00000000 new N N staticgeometrysubclassproxies.h(1465) Ogre::SGRegion::getLODIterator
052846 0x0E932B60 0x0000000C 0x0E932B50 0x0000002C 0x00000000 new N N staticgeometrysubclassproxies.h(1115) Ogre::SGMaterialBucketMapIterator::getN
052844 0x0E932BC8 0x00000018 0x0E932BB8 0x00000038 0x00000000 new N N staticgeometrysubclassproxies.h(1713) Ogre::SGLODBucket::getMaterialIterator
052845 0x0E932C30 0x00000008 0x0E932C20 0x00000028 0x00000000 new N N staticgeometrysubclassproxies.h(1717) Ogre::SGLODBucket::getMaterialIterator
052850 0x0E932C88 0x0000000C 0x0E932C78 0x0000002C 0x00000000 new N N staticgeometrysubclassproxies.h(871) Ogre::SGGeometryBucketVectorIterator::g
052848 0x0E932CF0 0x00000018 0x0E932CE0 0x00000038 0x00000000 new N N staticgeometrysubclassproxies.h(1017) Ogre::SGMaterialBucket::getGeometryIter
052849 0x0E932D58 0x00000008 0x0E932D48 0x00000028 0x00000000 new N N staticgeometrysubclassproxies.h(1021) Ogre::SGMaterialBucket::getGeometryIter



this file is generated after running DemoGrass.exe (the app runs fine btw). Other demos generate similar messages.

I also wrote a simple test app and it also leaves leaks behind (according the log file always)



using System;
using System.Drawing;
using OgreDotNet;
using Math3D;


namespace demoDotNET
{
class myProgram : ExampleApplication
{

protected override void CreateScene()
{
mSceneManager.SetAmbientLight(Color.White);

Entity ent = mSceneManager.CreateEntity("robot", "robot.mesh");
SceneNode node1 = mSceneManager.GetRootSceneNode().
CreateChildSceneNode("RobotNode");
node1.AttachObject(ent);
}

//[STAThread]
static void Main(string[] args)
{
using(myProgram app=new myProgram())
{
app.Start();
}
}
}
}


and the leaks log:



----------------------------------------------------------------------------------------------------------------------------------
| Memory leak report for: 08/03/2006 21:44:47 |
----------------------------------------------------------------------------------------------------------------------------------


22 memory leaks found:

Alloc. Addr Size Addr Size BreakOn BreakOn
Number Reported Reported Actual Actual Unused Method Dealloc Realloc Allocated by
------ ---------- ---------- ---------- ---------- ---------- -------- ------- ------- ---------------------------------------------------
037070 0x0907EDC8 0x0000000C 0x0907EDB8 0x0000002C 0x00000000 new N N ??(0) ??
037286 0x0D301C90 0x00000020 0x0D301C80 0x00000040 0x00000000 new N N ??(0) ??
037287 0x0D379018 0x00000010 0x0D379008 0x00000030 0x00000000 new N N ??(0) ??
037063 0x0E0269D8 0x000000FC 0x0E0269C8 0x0000011C 0x00000000 new N N eventhandler.h(269) Ogre::EventHandler::EventHandler
037064 0x0E026B20 0x00000014 0x0E026B10 0x00000034 0x00000000 new N N ??(0) ??
037065 0x0E026B80 0x00000014 0x0E026B70 0x00000034 0x00000000 new N N ??(0) ??
037066 0x0E026BE0 0x00000014 0x0E026BD0 0x00000034 0x00000000 new N N ??(0) ??
037067 0x0E026C40 0x00000014 0x0E026C30 0x00000034 0x00000000 new N N ??(0) ??
037068 0x0E026CA0 0x00000014 0x0E026C90 0x00000034 0x00000000 new N N ??(0) ??
037069 0x0E026D00 0x00000014 0x0E026CF0 0x00000034 0x00000000 new N N ??(0) ??
037071 0x0E026D60 0x0000000C 0x0E026D50 0x0000002C 0x00000000 new N N ??(0) ??
037072 0x0E026DB8 0x00000024 0x0E026DA8 0x00000044 0x00000000 new N N ogreeventprocessor.cpp(105) Ogre::EventProcessor::initialise
037073 0x0E026E28 0x00000170 0x0E026E18 0x00000190 0x00000000 new N N ogrewin32platformdll.cpp(91) Ogre::createPlatformInputReader
037074 0x0E026FE8 0x00000014 0x0E026FD8 0x00000034 0x00000000 new N N ??(0) ??
037075 0x0E027048 0x000000B0 0x0E027038 0x000000D0 0x00000000 new N N ogreinput.cpp(54) Ogre::InputReader::useBufferedInput
037076 0x0E027148 0x00000014 0x0E027138 0x00000034 0x00000000 new N N ??(0) ??
037077 0x0E0271A8 0x00000014 0x0E027198 0x00000034 0x00000000 new N N ??(0) ??
037078 0x0E027208 0x00000014 0x0E0271F8 0x00000034 0x00000000 new N N ??(0) ??
037079 0x0E027268 0x00000014 0x0E027258 0x00000034 0x00000000 new N N ??(0) ??
037081 0x0E027568 0x00000014 0x0E027558 0x00000034 0x00000000 new N N ??(0) ??
037082 0x0E0275C8 0x00000014 0x0E0275B8 0x00000034 0x00000000 new N N ??(0) ??
037083 0x0E027628 0x00000014 0x0E027618 0x00000034 0x00000000 new N N ??(0) ??




since I am newbie in ogre in general, could someone interpret those mesages to me? Is it those leaks ODN fault or is it false alarm?

jamison73

17-09-2006 22:50:21

Hi,

I've been working with 1.2.2. Lots and lots of PINVOKE errors. I've been trying to do Olivier's suggestion, but I have a question about:

2) I used the scripts in ogrenew/SDK to make an sdk.

What should I install so that I can run these batch files? Looks like it needs bash.

Thanks,
Jamison

PS. To my fellow VB.NET programmers/C++ Newbies. Downloading the Ogre Source, Dependecies, and DirectX SDK has gone super smooth. I highly recommend giving it a try. I'm using VS 2005 Pro