Thanks, I had done that originally, but I would get the crash if I was linking to release OSG from either the debug or release versions of my app. For the time being, I link to the debug versions OSG from both my debug and release versions of my app, which seems to work. I would of course like to get it worked out.
So I am not thinking it is a mixture of debug/release, but rather that I am not linking to some other runtime library properly, like msvcrt*.dll or whatever. As I have been porting Managed C++ projects from VS2003 to VS2005 I have been running into issues like this, so I think they might be related. We are using this example because we were having some problems getting osgDotNet to work. It would have these random memory corruption kinds of errors. osgDotNet only links to the release versions of OSG 2.0. I hope it is not something deeper with the release versions of OSG, but I imagine more people would have seen it if that were the issue. -- Rick On Wed, Mar 19, 2008 at 3:34 AM, Ralph Kern <[EMAIL PROTECTED]> wrote: > I guess you have a mixture of debug/release C Runtimes. malloc() and > free() have very different implementations in debug and release runtime, > so this would explain why in your stack trace the size=1 from operator > new() didn't get right through to malloc. > > Always link your debug version against debug OSG and release against OSG > release libraries. > > regards Ralph > > [EMAIL PROTECTED] schrieb: > > AHA!!! > > > > I found out that the problems I was having are only on the RELEASE > > versions. When I link to the debug versions of the OSG libraries, all > > seems to work well. Anyone know why? > > > > -- Rick > > > > > > On 3/18/08, [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>* > > <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > I just used the latest stable build, OSG 2.2.0, and I got a crash at > > precisely the same point. I do not think it is a versioning > > problem. Looking at the call stack, I wonder if there is something > > I am doing wrong with setting up memory, either in the OSG build, or > > in the managed code that uses the unmanaged code. I am new to > > VS2005 (have been using VS2003 for a long time), but I just followed > > the existing instructions, and everything compiles. > > > > The call stack seems to have a problem with a dynamic cast: > > > > kernel32.dll!7c812a5b() > > [Frames below may be incorrect and/or missing, no symbols loaded > > for kernel32.dll] > > kernel32.dll!7c812a5b() > > ntdll.dll!7c9106eb() > > > msvcr80.dll!malloc(unsigned int size=3765269347) Line 163 + 0x63 > > bytes C > > msvcr80.dll!_CxxThrowException(void * pExceptionObject=0x0012ea24, > > const _s__ThrowInfo * pThrowInfo=0x781b55e0) Line 161 C++ > > msvcr80.dll!__RTDynamicCast(void * inptr=0xcd010001, long > > VfDelta=0, void * SrcType=0x005cb25c, void * TargetType=0x005cc438, > > int isReference=0) Line 315 C++ > > osg25-osgViewer.dll!005a1516() > > osg25-osgViewer.dll!005a1a69() > > msvcr80.dll!operator new(unsigned int size=1) Line 59 + 0x8 bytes > C++ > > osg25-osgViewer.dll!005aa741() > > osg25-osgViewer.dll!005a1bfd() > > osg25-osg.dll!1007d866() > > [Managed to Native Transition] > > osgNETDemo.exe!osgNETDemo::osgNETDemoForm::InitOSG() Line 65 + > > 0x18 bytes C++ > > osgNETDemo.exe!osgNETDemo::osgNETDemoForm::osgNETDemoForm_Load > (System::Object^ > > sender = 0x0012ec40, System::EventArgs^ e = 0x0012ec4c) Line 330 C++ > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Check us out at http://fringe-online.com/
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
