OCC 6.1 bug in visualization …

I can't say that my one is the same problem you described, however: I just realized that there is a memory leak problems in several of the MFC standard examples.
When you run it in debug mode, opening a new window on the same document produces a "user breakpoint called from code ..." error in NTDLL.dll. In the VCC output window, you can see "HEAP[xxxx.exe]: HEAP: Free Heap block xxxxxx modified at xxxxxxx after it was freed".
Running it outside the debugger is ok: the problem is seen only under debugger, because it is a hard-coded breakpoint
used by Debug Win32 heap to notify about heap problems.

An explanation of how to catch the error installing a debugging tool is in:
http://support.microsoft.com/default.aspx?scid=kb;en-us;286470..

But I've not yet applied it.

If you, or somebody already knows where is the bug ....

Thanks.

Thierry - have you managed to solve this yet.

It looks like a similar problem that has been experienced with my Qt4 application, but to help you need to tell me:-

1. What compiler is your OCC runtime compiled with - are you just using the default VS 2003 libraries?

2. What compiler is your application compiled with?

3. What else has changed?

Your symptoms are synonymous with memory leaks, and sometimes later verions of compilers detect these with greater efficiency. The problem is often in class destructors which don't release all the resources taken. I think this is pretty much of the cause of the leaks found in the standard demos - these show up as memory dumps when exiting the application. If your running with different versions of the MS runtimes for your app and the OCC libs, you may be allocating memory with one library (e.g. VC 8.0)and deallocating it with another (e.g. VC 7,1).

The only real way to debug many of these issues is to use a debug version of the OCC libaries and walk the code down through the window resize event. But the only way to really help you is to review the code in question. For that I would need to see the code - respond in this thread if your interested.

Pete

Hi all and thanks for your help,

Sorry for responding lately but I had tons of work to do last weeks. As I steped back to OCC 52, I must say that I treat this trouble as a background task.

I agree with both of you the trouble is certainly du to memory leaks... Tracking such errors is quite painfull as suggested.

However I'll install the Microsoft debug program next week and see what's come out.

By the way, to answer Pete's questions:
1) The OCC libraries used are straight "out of the box", i.e. they come from the OCC 6.1 default installation. They have not been recompiled.
2) I use VC6 SP5/6 (depending on the computer used)
3) Nothing changes beetween the OCC52 and OCC61 release of my application, i.e. the only things that change are the OCC libraries!. Moreover I get the trouble with the sample app...

Well, I'll give you some news as soon as possible.

Regards.

Thierry

So just to confirm.

Your OCC 6.1 libs are those from the vanilla installation. I believe these have been compiled with Visual Studio 2003 (VC 7.1) in release build. They will be using the VC7.1 runtimes

Your application is running VC6 SP5/6, and will be using the corresponding runtimes. It works fine when running against OCC 5.2, which was also compiled with VC 6 (SP?).

If you want to use 6.1 my simplest suggestion (if its available to you) is to migrate your application to Visual Studio 2003. If you jump over to VS 2005 you may experience the same problem with the OCC, although many of the examples work in this mode. Either that or stay on VC6 and keep OCC at 5.2, or try to recompile OCC 6.1 with the VC6 project files in the ros\adm\win32 folders - I haven't tried this.

My own solution was to migrate OCC 6.1 to VS2005, with both debug and release builds, which is compatible with my development platform. It took me some time to do this and not perhaps as cleanly as 6.1.1 does but that version costs money!.

Pete

Pete

Hi Pete,

Thanks for the advise, but it will be difficult to find a VS2003.
I should try to compile OCC6.1 with VC6...

See ya.

Thierry Lacombe

Actually its easier to get the VS2005 Express Edition http://msdn.microsoft.com/vstudio/express/visualc/ - you'll also need the Platform SDK

Pete

Hello Pete,

I am using the same QT example project that you gave me , and tried to incorporate more than one viewer contexts and more than one view widgets, and i am getting the same error when i switch between the views.

The output window may have more diagnostic information
HEAP[tabapp.exe]: HEAP: Free Heap block 732bd08 modified at 732bd18 after it was freed
Windows has triggered a breakpoint in tabapp.exe.

This may be due to a corruption of the heap, and indicates a bug in tabapp.exe or any of the DLLs it has loaded.

The output window may have more diagnostic information
The program '[3348] tabapp.exe: Native' has exited with code 0 (0x0).

however if i continue the execution of the code it shows the program in the correct state of display.

could you shed smoe light on how i could solve this error.

TIA
Commenter-3

Hi Harsh,

Is your Heap trouble solved ? If not, you could take a look at this thread "Bug in OpenGl_tXfm.c, function: loadTexFont". I did and got some interresting results...

By the way what's your computer's configuration, I mean OS, Visual Studio and graphic card ?

Regards

Thierry

The code I have been working on, when I get the time, has expanded the viewer model to use two tabbed views working on the same viewcontext. I haven't had any problem with this. However I haven't yet tried a model that uses two contexts yet. This is because I haven't yet got a design for a good application/document/view model yet. But this may indicate that your problem lies in the context rather the view switching. If you want I can take a look at your problem if you are able to email the source and a Qt project ("peter at dolbey dot freeserve dot co dot uk" as I feel partially responsible for the Qt viewer).

Thierry is right to query the graphics card as well. My original code derived its OCC widget from QGLWidget which worked well on both XP (ATI Radeon X300) and ported to Ubuntu Edgy. However on some XP systems the winId() property of the widget wasn't being initialised in the same way as mine did. Inheriting from QWidget directly fixed this on XP but failed on Ubuntu. This is a problem I really like to sort, with common code on both platforms but I still can't reproduce the problem with Radeon (and I can't afford to go out buying other graphice cards!).

Pete