I have written an Qt application.
On Windows 7 x64/x32 app work's fine.
On Windows XP in qDebug() there are lots of messages.
QPixmap it is unsafe to use pixmap outside the GUI thread
After that the app crashes with sigfault
but:
1) I dont use QPixmap in my code at all
2) I have only one created thread for creating some type of file(but this error occurs just after a couple of seconds after start of app).
3) I use QIcon(May be it uses QPixmap) in reinplecated QStyledItemDelegate(but there is no external threads...only slots and signals for reporting state e.c.t.)
4)I have reimplemented QAbstractListModel to process my QStyledItemDelegate's
5)On form created with Qt designer there is a toolBar with Iconed actions
Qt version 4.8.1
I couldn't even imagine where I'm not right...
Does any one have any suggestions?
Solved by myself
in QMainWindow reimplementation i have QTimer for updating 2 QLabels
That was the error beacuse as i figured out QTimer creates a thread for each timout() signal
Solution i have decided to be best for me is to reimplement Item class with signal dataChanged which is sent ot slot OnItemDataChanged in reimplementation of QAbstractItemModel
The message is displayed by a function named qt_pixmap_thread_test() in src/gui/image/qpixmap.cpp.
Link to the debug Qt libraries (you may need to build them) and set a breakpoint where that warning is displayed. At least you'll be able to see what the thread situation is at that point.
Also, for the benefit of anyone else who might run into this problem and is trying to search on the error, the exact error message is:
QPixmap: It is not safe to use pixmaps outside the GUI thread
Related
I have an application I have been working on for the past year. It builds and runs normally in various machines (including Mac OS). I just got a Surface Pro X and was surprised I was having issues when rendering in a QVTKOpenGLWidget. The application runs, but when I open a window with a QVTKOpenGLWidget, it crashes and gives access violation error in Qt5Gui.dll.
I changed from QVTKOpenGLWidget to QVTKOpenGLNativeWidget which seemed to have improved somewhat the situation, but I can't render anything. The window opens and stays open so long as I don't add any actor or call to render.
From looking at the logs, Qt seems to have issues with creating a context. The VTK logs keep popping up the following error:
vtkGenericOpenGLRenderWindow (0CAD3408): GLEW could not be initialized: Missing GL version
I have tried the following with no positive results:
// First attempt
auto format = QVTKOpenGLWidget::defaultFormat();
format.setProfile(QSurfaceFormat::CompatibilityProfile);
QSurfaceFormat::setDefaultFormat(format);
// Second attempt
QSurfaceFormat::setDefaultFormat(QVTKOpenGLNativeWidget::defaultFormat());
Has anyone figured out how to get this working? I don't think the problem is specific to the Surface Pro X, but to any Windows GPU driver.
I am developing a GTK3 based application with OpenGL windows created using the GtkGLArea widget, to build the application on windows I use the msys2 64 bits system.
No problem to build the application, it works just with a single OpenGL window.
However my program is designed to handle multiple projects, and hence GtkGLarea, one for each project. This works perfectly for Linux.
However on window, it works with one GtkGLArea, but as soon as more than one are used only a single one (the first to be created) remains active, and no information is displayed in the other windows. If I click on any of the other windows then the content of the first window is updated with what should appear in the window I am interacting with ...
I noticed that I could open as many instances of my program each with one GtkGLAera working just fine, and therefore that the number of OpenGL context is not a problem, only the interaction / dialog / management within the same occurrence of my program is.
Is there any way to correct this behavior and how ?
Looks like it's a known GDK Win32 bug that has been fixed.
Bugzilla bug #789213
You should use wglMakeCurrent() analog to set current context, and after usage you should call wglMakeCurrent(NULL, NULL) to release context so the other widget will be able to use OpenGL.
I want to capture a stacktrace of an application which sometimes stops responding for few minutes.
When the application stops responding, the windows desktop also stops responding to mouse clicks, although some other already running applications are working fine at that time (for example windbg works fine, ProcessExplorer refreshes its screen, but does not respond to mouse events).
While the application is non responsive, it is actually taking about 80% of one CPU core. That is why I would like to get a stacktrace.
The misbehaving application usually takes about 2-3 minutes to do its strange job or if Ctrl+Esc is pressed it becomes responsive immediately (and the start menu opens of course...)
I have WinDbg attached to the misbehaving application and when I issue the Break command, the break-in does not happen until the application starts to respond again.
From what I understand the break-in actually creates a remote thread which pretty soon calls DbgBreakPoint.
What could be preventing debugger's thread from executing?
EDIT:
First of all thanks for your help!
I was also thinking that this might be caused by a bad device driver or something that installs a system wide hook somewhere.
I was thinking to enable kernel debugging and get a stack trace from the kernel for the offending thread or enable manual bluescreen trigger to produce a dump and look at that afterwards.
Process Explorer and Process Monitor does not reveal anything interesting. They also become unusable when the bug is triggered (updating their windows but not responsive to mouse or keyboard).
EDIT2:
Background info:
App uses QT, OpenGL and also DirectSound and runs on Windows 7 SP1 x64
I am currently suspecting something with the graphics part.
The strange thing is that if a system-wide lock is taken (like GDI Lock), this would prevent drawing of other Windows, but that does not happen. WinDbg on same machine works fine. ProcessExplorer updates but does not receive mouse clicks, Desktop updates but no mouse clicks.
I currently have a kernel debugger attached...
EDIT3
ETW was most useful for debugging. It turns out that Qt's main event processing loop goes crazy. PeekMessage and MsgWaitForMultipleObjectsEx (with 0 timeout) gets called in a tight loop. That is where the high CPU usage comes from.
It looks like the App is generating/getting loads of messages at that time. But it is not easy to see what the messages are (or I don't know how to access function parameters in ETW). Using a debugger also does not help much but, with a breakpoint in the QT's event loop leads me to believe that WM_TIMER messages are the culprit.
Given that the desktop also misbehaves during this time, it sounds like your app isn't necessarily misbehaving but merely aggravating a bug elsewhere (e.g., in a device driver or some crummy anti-malware code that has injected itself into other processes). Stack traces from your app may or may not be very revealing.
If the problem is easily reproducible, I'd set a breakpoint somewhere in the "middle" of the app and see if the problem happens before or after that. Then move the breakpoint until you find the last instruction your app executes before things go bonkers. Figuring out what your app does that triggers this behavior may give a clue as what's going on.
Another option is to try using some system-wide debugging tools. First, I'd peak in the Event Viewer to see if there are suspicious error or warning events posting in proximity to the moment the machine goes haywire. Then I'd try a tool like Sysinternal's Process Monitor or Process Explorer to get a better view of what's happening. You might also try ETW to capture a system-wide trace of what's happening on the system that you can study after the fact. (ETW can be hard to use, so check out Bruce Dawson's UIforETW.)
Use ETW to find the cause. Install the Windows Performance Toolkit (part of the Win10 v1511 SDK: https://go.microsoft.com/fwlink/p/?LinkID=698771 which is the last version that works in Win7), run WPRUI.exe, select CPU Usage and click on Start.
After you captured the hang, click on Save. Wait until WPRUI is finished, open the ETL in WPA, setup and load debug symbols in WPA.
Drag & Drop the CPU Usage (Precise) graph to analyse pane and look for WAIT (µs) max for your process to see that long hang and expand the stack to see where it happens.
I have written file picker code in my project. When i run the project in my windows phone by clicking on device button in visual studio, the app runs fine(I mean it opens pictures library and i can select a photo and preview it).
But when I disconnect my usb and then open the app in the phone and when i open pictures library on click of a button , the pictures library opens briefly and then the app crashes immediately(My app closes).
Can anyone please help me with this??
As written in the blog post , the AndContinue method run in a different process and to do so, the current running app goes into the background or even gets closed sometimes, that is what you are experiencing in your app as far i can tell but not sure why different things happening during debug & deploy.
There must be a callback inside app.xaml.cs specifically to handle the condition when calling application(which was sent into background) comes in foreground, read this blog post carefully & you'll understand as what you need to change in your code :
using-the-andcontinue-methods-in-windows-phone
http://blogs.msdn.com/b/wsdevsol/archive/2014/05/08/using-the-andcontinue-methods-in-windows-phone-silverlight-8-1-apps.aspx
I just dealt with this issue and one of the reasons why there are differences between debug and deploy is because of the suspending event.
During debug, the application does not actually get suspended until you manually do it through Lifecycle Events. This means that when you pick a file on debug and the app is put to the background to load the file picker, it is not actually suspended, while when the app is deployed, it actually gets suspended.
Look into your app_resuming method and OnSuspending methods in your app.xaml that may be causing errors not occurring during debug.
If a VB6 app is causing an Application Hang event to appear in the Event Viewer, how can I find out more about why the application is hanging?
Does an Application Hang event mean that the app has frozen and crashed, or just that it temporarily hangs?
All I get in the event log for this event is:
Hanging application [MyAppName].exe, version [MyAppVersionNo], hang module hungapp, version 0.0.0.0, hang address 0x00000000.
That is not enough and I want to be able to find out more about why it is hanging. What code changes or other steps need to be taken to cause the app to provide more details in the event log?
I recommend using the Windows Performance Toolkit. The best version to use is in the Windows Assessment & Deployment Kit, http://www.microsoft.com/download/en/details.aspx?id=28997
Once it's installed, what you do is start up Windows Performance Recorder (WPR) and click the Start button to begin recording. Next, reproduce the problem with your app. Then go back to WPR and press the Save button. Next, load up Windows Performance Analyzer and open that *.ETL file that was generated. Then you want to go to System Activity section in the Graph Explorer, expand it, and find the UI Delays graph (or it might be the first graph parked on System Activity). Double click on it to get the detailed version in an Analysis tab.
Once you find the UI delay you're interested in, you can add another graph such as CPU Usage (Sampled) from the Processing node in Graph Explorer. When the two graphs are in the same Analysis tab, their scrolling and selection will be synchronized. So you can click on the UI delay event and it will also highlight the corresponding range in CPU Usage.
The Application Hang event means that Windows has decided that the application is unresponsive. Since the event is generated by the operating system and not the application, your options for getting additional information in the event are extremely limited.
This is what seems to be available on an Application Hang event:
Message: Hanging application %1, version %2, hang module %3, version %4, hang address 0x%5.
From:
http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows+Operating+System&ProdVer=5.2&EvtID=1002&EvtSrc=Application+Hang&LCID=1033
If you believe the cause of the event is something that your application does (as opposed to something in the environment where the application is running), then instead of trying to pass info to the hang event, you should raise the level of log info to debug mode and look in your application's log file to see what it is doing just prior to becoming unresponsive.
If you lack logging information, or a logging framework in your application, then that is where you should be focusing your efforts. The upside is that you will benefit from better logging in the future as well. Use a logging framework however, so you can disable debug level logging in a production environment, when everything is running smoothly.
I would approach this by reviewing the code in the module that Windows has determined has hung, the name of which was written to the event log. Attempting to get more detail in the hang event will not be possible because when Windows has determined the app is unresponsive, it is too late.
Into the module that is hanging I would add multiple calls to DoEvents as well as logging status messages directly into the EventLog. Adding a logging framework at this point would introduce complexity and involve either a database or file access in which to store the logs.
Windows thinks the app has hung because it has stopped responding to messages. Unfortunately, implementing a second thread in your VB6 app is not trivial, unlike .NET. Never-the-less, adding another thread would keep the app responsive, but then you would likely still be left with answering the question, "why is the code taking so long to execute?"
Getting information from windows event perspective will not help. Try to have tracing in your application which helps you to get the exact cause.