Sat, 10/21/2006 - 02:46
I’m developing an application based on OCC which is a 3D modeler with some functionalities dedicated to naval architecture. My UI is quite standard and composed of 4 views (top, right…), all connected to the same Viewer… The views are hosted in a slightly customized MFC splitter tested several times with genuine MFC views…
I started this project 2 years ago with an OCC 4.X release and, until now, succeeded in moving the project to 5.1 then 5.2 release without any troubles.
Over the past 2 years the developments were carried on various configurations at the same time: OS Win 2K and Win XP, VC++ 6 SP5/SP6, Desktop/ATI_RADEON_9600XT, Laptop/NVidia, so lets say the code is quite bug free…
Going straight to the point, I would said that the bug occurs when there are more than 2 OCC views opened at the same time, each one displaying at least one object. The bug seems to be linked the refreshing of the views, i.e. when resizing a splitter or when highlighting an object in a view which has not the focus…
In order to identify the bug, I used MyApp (of course) and the sample app Viewer 3d with 2 docs open at the same time. The 2 docs give 2 views (even if these 2 views are linked to different viewer it's quite similar to my App)... So here are the results of the tests.
> Desktop Win2K/ATI_RADEON_9600XT:
- Viewer 3D : can’t detect any troubles in release or debug mode when several docs (then several views) are open at the same time.
- MyApp : in debug and release I get the same trouble. At the beginning everything is fine, then after playing a little with the splitter (resizing the views), the application starts to slow down, selection highlighting is not synchro in all the views (one views refreshed after one other), rotating is painful and at the end the app freezes…
>Laptop Dell WinXP SP2 /Intel 915GM/GMS, 910GMLExpress:
- Viewer 3D : can’t detect any troubles in release mode when several doc (then several views) are open at the same time. But, in debug mode the app produce a Userbreak point in the IGLCD32 dll (Intel OGL dll) with the following message in VStudio : HEAP[Viewer3d.exe]: HEAP: Free Heap block e89f530 modified at e89f540 after it was freed. It always occurs when the mouse, starting from the view which has the focus, moves over an object in the second and unfocused (no click done) view. My opinion is that it breaks when trying to update the unfocused views due to the highlight option… In order verify whether the trouble comes from the selection process I put into comments the call to GetDocument()->MoveEvent. I reproduced the bug only when resizing the views (of course!)…
- MyApp : unable to start my app in debug mode, the app breaks in the IGLCD32 dll with the heap at the first display. In release mode, the App starts but rapidly freezes after having played (a little) with the splitter and view trsf functionalities (rotate, zoom…).
I updated all the video cards drivers without any success.
I hope this information will be useful to both community and OCC team and keep trying to sort this thing out.
Best Regards.
Thierry Lacombe
Mon, 11/13/2006 - 03:42
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.
Mon, 11/13/2006 - 17:34
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
Tue, 11/14/2006 - 14:54
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
Tue, 11/14/2006 - 17:50
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
Fri, 11/17/2006 - 20:57
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
Sat, 11/18/2006 - 15:38
Actually its easier to get the VS2005 Express Edition http://msdn.microsoft.com/vstudio/express/visualc/ - you'll also need the Platform SDK
Pete
Sat, 04/14/2007 - 12:58
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
Harsh
Wed, 04/18/2007 - 14:32
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
Wed, 04/18/2007 - 15:13
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