PDA

View Full Version : Complicated QwtPlotZoomer crash, possible bug? Help request.



philwinder
2nd October 2008, 15:35
Hi guys,
I have a really annoying bug in my program that is hard to track down.
The situation is that when I repeatedly zoom in/out/in/out many times, at a certain point the program crashes. It looks like parts of the GUI are placed all over the desktop until after another couple of clicks windows reports an error and you have to end the program.
The point at where it crashes is unknown, but it does seem to crash quicker when a PC has less memory; i.e. the more memory, the longer it will take to crash. On a 512mB PC it takes about 20 zooms and on a 1G PC it must take around 80 or something (those are a complete guess though!).
I dont mean this in any disrespectful way because I think Qwt is excellent, and I use it all the time, but I've checked my program and I dont think that there is anywhere for my program to cause the crash, since all the data is passed to the plot via the setData function. So I can only assume that there is a pointer/allocation related bug somewhere in the QwtPlotZoomer code.

If you have any thoughts/questions I will be glad to help.

Uwe
2nd October 2008, 17:15
Start your debugger and tell us about the stack, when your application has crashed. If you think you are running out of memory use a memory profile ( f.e. valgrind on Linux ).

Without additional informations you can't expect any useful hint.

Uwe

philwinder
2nd October 2008, 18:40
Ok I'll try, but I havent got Qt installed for debugging so I will have to go and sort that out. I also have no idea how to look at the stack, so I'm afraid you will have to give me a while to get to grips!

Cheers,
Phil

philwinder
4th October 2008, 19:13
Hi Uwe,
Ive now had some time to look into this further. Below are the error messages I received.

When in release mode, the QT console returns:

convertHIconToPixmap(), failed to GetIconInfo()
QPixmap::fromWinHBITMAP(), failed to get bitmap info (The handle is invalid.)
QPixmap::fromWinHBITMAP(), failed to get bitmap info (The handle is invalid.)
When in debug mode I get:

Program exited with code 03.
(gdb)
QFSFileEngine::open: No file name specified
convertHIconToPixmap(), failed to GetIconInfo()
QPixmap::fromWinHBITMAP(), failed to get bitmap info (The handle is invalid.)
QPixmap::fromWinHBITMAP(), failed to get bitmap info (The handle is invalid.)
ASSERT: "m_hdc" in file painting\qpaintengine_raster.cpp, line 4286

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
warning: Lowest section in C:\WINDOWS\system32\xpsp2res.dll is .rsrc at 00011000
warning: Lowest section in C:\WINDOWS\system32\odbcint.dll is .rsrc at 00401000
BFD: C:\WINDOWS\system32\wmvcore.dll: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .reloc
BFD: C:\WINDOWS\system32\wmvcore.dll: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .reloc
(gdb)

Uwe
5th October 2008, 09:08
Well, only starting the gdb is not enough, you have to analyse the stack after the crash. F.e. enter "where" to see the stack. With "up" and "down" you can navigate on the stack and check the local variables.

Uwe

philwinder
5th October 2008, 11:31
Hi Uwe,
Ok I tried, but when I typed "where" it said there was no stack. Is that because the program has ended?
Because I dont know where the crash is occuring, so I can't stop it just before it ends.
Thanks,

Uwe
6th October 2008, 21:52
Guess you were running on an exception that terminated the program. If true catch the exception in the debugger an look at your stack then.
I'm afraid you have to spend some time on the gdb manual - but this time is definitely not wasted.

Uwe

philwinder
10th October 2008, 15:54
Hi again Uwe,
I've been doing some more research on this bug, and although I couldnt find it via debugging (hard work!) I did manage to replicate the bug in a simple program.
The code attached was compiled with Qt 4.4.3 and the Qwt from the svn repository which I believe was Revision 417: version 5.2.

To get the program to crash, you have to use your mouse to zoom in and out many times. I believe the faster you zoom in and out, the faster it will crash. So I was repeatedly left clicking then right clicking at a fair pace. Make sure to do small circles too so it actually zooms in. (Note: this may cause your hand to ache!).

On a Dual core 2GHz laptop with 2G of RAM, it takes about 1.5 minutes to crash. On lower spec PC's (tested with a P4 3GHz, 512Mb RAM) it can sometimes only take 30 seconds worth of clicking.

Hopefully you can compile and run the attached code, but if you have any problems let me know.

Many thanks,
Phil Winder

Attached: qwtCrashTest.zip - source files, ui file and a pro file.

Uwe
12th October 2008, 09:25
I've tried your demo on Linux/X11 with Qwt 5.1/Qt 4.4.2 without problems.

But your demo code does not much, so you can expect, that the reason for it is Qt downwards and Windows specific.

I recommend to upgrade to Qt 4.4.3 build it in debug mode and rerun your demo under gdb control. And again: try to learn/understand your debugger - whenever an applicaton crashes you can see it in your debugger.

Uwe

philwinder
13th October 2008, 09:28
As stated in the above post, it was compiled in 4.4.3, so I cannot update any more.
But yes, it does seem to be windows specific.

philwinder
21st October 2008, 16:13
A quick update, unfortunately, I still haven't got round to debugging the code, but the crash is applicable to all of Qwt's examples with a zoom in. E.g. Bode, errorbars, etc.

It crashes on Xp and Vista.

I'll try and find some time to go through it this week. Hopefully. Debugging somebody else's code is a nightmare!

Cheers,
Phil

Uwe
22nd October 2008, 10:49
I'll try and find some time to go through it this week. Hopefully. Debugging somebody else's code is a nightmare!
Phil, I didn't mean, that you should debug someones code. Believe me its completely impossible to understand ( I never tried myself ) the graphics pipeline of Qt without spending a lot of time before.

What you know is that Qt is running into an assertion in qpaintengine_raster.cpp, line 4286. Obviously CreateCompatibleDC(displayDC); returns NULL, what is the return value, when the method fails. Maybe its worth to read the MSDN docs (or google) about CreateCompatibleDC.

The assertion might have to do with the warnings before. If those are written immediately before the assertion ( do they happen in all Qwt examples too) try to find the code line, that writes them.

If you have a support license this should be enough information to contact the TrollTech support.

Uwe

philwinder
22nd October 2008, 17:18
Hi Uwe,
I've spent a bit of time looking thought the debug window and yes, the crash is due to the Assert statement. CreateCompatibleDC is some sort of memory management function, so I can only assume that it cannot allocate the memory for the device.

I dont know why it cant allocate the memory though, because according to my memory gauge there is loads left.

Do you think that this is a Qt problem? Or a windows problem? Its obviously not something to do with Qwt (How could I ever think it was!) but I am an open source user, and hence have no service contract. Shall I attempt to report a bug?

Cheers,
Phil

Uwe
24th October 2008, 07:19
I'm pretty sure, that it is a Qt problem. Could you please check the warnings, that were printed before the assertion happens ?
Together with this information I will contact the Qt support,

Uwe

philwinder
29th October 2008, 14:02
Hi Again Uwe,
Sorry, just seen your message. I didnt manage to find any specific errors, but it was just the windows related functions returned 0, meaning that they could not allocate any memory for whatever it was.

So, usually the function CreateDIBSection on line 4289 returns 0 meaning some sort of error, then the function CreateCompatibleDC returns 0 and finally crashes the program. However, the actual order of these two have been different, ie. sometimes the CreateCompatibleDC flags an error first, sometimes the CreateDIBSection does.

I already sent a bug report to Trolltech and they referred me back to you! Message as follows:

Hi Phil,

There is no way that I can see if this is a QWT problem or a Qt problem.
QWT is an external product. Please report this to Uwe in the
forum(which I can see you have done), and he will file a bug if the
problem is Qt related.

Thanks,
Morten

Thanks,
Phil

Uwe
3rd November 2008, 11:00
I will have a look at the problem the next time I will check Qwt on Windows ( what might take some time ).

Uwe

jomarin
12th December 2008, 08:36
Hi everyone,

I have a similar problem on Windows. My QwtPlot window crashes after a number of zoom in and out, that seems to depend on the machine used.

I did not experience the same problem on Solaris.

Any news on this subject ?

Thanks in advance,

Joel.

philwinder
12th December 2008, 08:40
Ah, I am glad it is not just me. I still have the problem, and I do think it is restricted to windows. They must handle their graphics memory management differently. Having you on board with the same problem may inspire Uwe to take a look at the problem.

gambr
26th January 2009, 09:22
Same problem on windows XP, VS 2003 7.1 SP1, Qt 4.4.0, Qwt 5.0.2 & 5.1.0 & 5.1.1.

Gianni

gambr
4th February 2009, 14:54
Qt support confirms there is a GDI leak on their part. It should be already fixed in Qt 4.5.0 coming but I didn't try that.

Gianni

Azraiyl
5th February 2009, 21:51
Same bug here. You can open the Windows task manager and watch the GDI objects. If a Zoomer (and on my computer a Picker as well) is enabled you are able to create about 1000 GDI objects per second. After about 10'000 GDI objects Windows isn't happy anymore.

(About 50% of the Qwt demos crash on my computer when I recompile everything with Qt 4.5.0 rc1 (when I move the cursor over a plot), but this is maybe my problem).

Uwe
6th February 2009, 06:57
(About 50% of the Qwt demos crash on my computer when I recompile everything with Qt 4.5.0 rc1 (when I move the cursor over a plot), but this is maybe my problem).
No, it's because of an changed API of Qt 4.5.0 that let's Qwt run into a NULL pointer.

I adopted the Qwt code yesterday, but didn't check the Windows platform yet. So with the code from SVN ( 5.1 branch ) there are chances to have a working combination.

Uwe

Azraiyl
6th February 2009, 09:31
Thanks. Examples now build fine and the Picker/Zoomer does not create tons of GDI objects anymore (at least with Windows XP).

gambr
9th February 2009, 15:07
I confirm the leak was on Qt side. Qt 4.5.0 release candidate are fixed but you need to download Qwt 5.1 from svn to play with that Qt version.

Gianni

philwinder
10th March 2009, 21:46
Great to hear you got it all sorted. Thanks Uwe, and everyone else!

dbrmik
20th March 2009, 10:28
Hi

I've read through this thread, and unless I'm missed something my setup should be OK. I am running qt4.4.3 and qwt5.1.1 on windows xp. However my setup is suffering from the same problem

warning: ASSERT: "m_hdc" in file painting\qpaintengine_raster.cpp, line 4286

Anyone any ideas why this is

Best regards

Uwe
20th March 2009, 11:37
I've read through this thread, and unless I'm missed something my setup should be OK. I am running qt4.4.3 and qwt5.1.1 on windows xp. However my setup is suffering from the same problem
Everything is wrong with your setup: it's a Qt 4.4 bug fixed in Qt 4.5 and you need Qwt 5.2 from SVN (will be released the next days) because 5.1.1 is incompatible with Qt 4.5.

Uwe

Sachtech
9th March 2010, 06:42
This problem seems to reoccur with

Qt 4.6.2
OS (Windows 7 Professional)
Microsoft Visual Studio 2008
Qwt v 5.2

Can some one confirm it.

Uwe
9th March 2010, 08:59
No this has to be a different one. Start your debugger, check where your application is crashing and post a bug report with more informations in a new thread.

Uwe