In our Qt5-based application, many messages like this are displayed in the console:
0x1beccb0 void QWindowPrivate::setTopLevelScreen(QScreen*, bool) ( QScreen(0xd25b80) ): Attempt to set a screen on a child window.
It does not prevent the application from running, but I would like to fix them, since it tends to indicate that there is probably something wrong that we are doing. The code is quite large (cannot be included in the post, it is there: http://gforge.inria.fr/frs/?group_id=1465). I cannot ask you to take a look at it (too big), but maybe you will have an idea with the following additional information:
The messages appear only under Linux, and not under Windows
Our application is a 3D modeler, that has several QGLWidgets for
displaying 3D content. If I remove the QGLWidgets, then the messages
disappear.
In the debugger, if I put a breakpoint on
QWindowPrivate::setTopLevelScreen(), it is called by:
kernel/qwindow.cpp:368
368 q->connect(screen, SIGNAL(destroyed(QObject*)), q, SLOT(screenDestroyed(QObject*)));
Update1:
I put a breakpoint on QMessageLogger::warning (qDebug() is a macro that uses this function), now I can better see the stack that looks like:
#0 0x00007fffefa50600 in QMessageLogger::warning() const#plt () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#1 0x00007fffefa851cb in QWindowPrivate::setTopLevelScreen (this=0xd330e0, newScreen=0x7201a0, recreate=<optimized out>)
at kernel/qwindow.cpp:371
#2 0x00007fffefa7f2f5 in QGuiApplicationPrivate::processWindowSystemEvent (e=e#entry=0x760600)
at kernel/qguiapplication.cpp:1608
#3 0x00007fffefa631f8 in QWindowSystemInterface::sendWindowSystemEvents (flags=...)
at kernel/qwindowsysteminterface.cpp:625
#4 0x00007fffeb7d4100 in userEventSourceDispatch (source=<optimized out>)
at eventdispatchers/qeventdispatcher_glib.cpp:70
(More stack frames follow...)
In QGuiApplicationPrivate::processWindowSystemEvent, it is handling a QWindowSystemInterfacePrivate::ThemeChange event:
1608 case QWindowSystemInterfacePrivate::ThemeChange:
1609 QGuiApplicationPrivate::processThemeChanged(
1610 static_cast<QWindowSystemInterfacePrivate::ThemeChangeEvent *>(e));
1611 break;
Update2:
Nearly there !! It is when I call setMinimumWidth() / setMinimumHeight() on a QGLWidget. Now I'd like to know why...
Update3:
More information: the messages are only displayed when I have two screens connected to my computer.
Finally, I understood what happens:
The warning messages occur whenever setMinimumWidth() / setMinimumHeight() are called on a QGLWidget under Linux with a dual screen display.
This is probably a bug in Qt. It will probably be not fixed, since it is recommended in the documentation to use the new QOpenGLWidget instead, that appeared in Qt 5.4 (note: "OpenGL" instead of "GL"), which I did and the warning messages disappeared.
Edit: I saw a message from someone that had problems with text not rendering properly with the new QOpenGLWidget which I answer here: When using the new QOpenGLWidget, one needs to take care that it no longer has an independent OpenGL context, it shares the OpenGL context with Qt (therefore, OpenGL states modified in the rendering function needs to be restored after exiting the rendering function, for instance blending mode).
Related
In Google Play Console on the dashboard of your application there
is a graph with Crashes & ANRs.
What is the best practice to solve
crashes to provide the best service to your users? My application is
written in Python in Kivy framework.
Navigate to Quality -> Android Vitals -> Crashes and ANRs.
This lists each event and on the right you will see a "->" arrow labelled "View Details".
Click this, scroll down past the graph and you'll see the Stack traces.
This is what you need to look at to fix your code.
The top line will be the error, then it'll show the line of code where the error occurred, for example:
[code]
java.lang.NullPointerException:
at com.test.MyApp.doSomethingCool (MyClass.java:123)
at com.test.MyApp.somethingElse (AnotherClass.java:321)
[/code]
Here you have some null value causing an issue in the "doSomethingCool" function of your app and that code should be on line 123 of "MyClass.java".
The trace lines after that show what called that function that failed, so above, this is showing that "doSomethingCool" was called from function "somethingElse" on line 321 and that code is in "AnotherClass.java".
This example is for Java.
--Updated--
If you are coding in Python, then the stack trace may not show you where in your own code the problem lies. Instead your best bet is to search on Google for the top line error and hope that the answer is online.
Separately from stack trace analysis I would highly recommend that you place your project into source control with GIT or SVN, specifically so that you can see what changes might have caused an error.
Update your code in the repository only when it's working and then you will always have a safe saved version that is known as working. You can then easily compare your current code and see what changes might have caused an error. This is especially useful for Android, which regularly updates versions of shared libraries.
I’ve encountered a strange problem during iOS AUv3 Instrument development which I’m having trouble finding information on. I’ve spent a couple weeks now attempting to debug this, and I was wondering if anyone else has encountered it. It feels more like an "OS killed the app" than a crash, so I use the term crash loosely. Here are the symptoms:
It doesn't seem to ever happen on initial instantiation; it's when a project is reloaded. But, you can comment out setFullState and it'll still occur.
The “crash” is inconsistent. Like a lot of slippery bugs, it’ll start happening consistently and then it’ll stop happening completely.
When it does happen, it initially appears to load fine: the view loads and looks correct, and it produces audio. But, after a couple seconds, the plugin view disappears and it stops producing audio. I see this in the console log:
viewServiceDidTerminateWithError:: Error Domain=_UIViewServiceInterfaceErrorDomain Code=3 "(null)" UserInfo={Message=Service Connection Interrupted}
You don’t have to generate any MIDI events to crash it. It would crash even after I commented out the processing block.
If anyone has any ideas, including how to get some useful debugging info out of this situation, let me know!
I tried to look at crash logs, but there are no crash logs generated
didReceiveMemoryWarning is not tripped. In fact, I did an experiment where I allocated 100 megs and memset’d it on startup, and it didn’t crash it.
I tried attaching a debugger, but it goes from “no debug session” to “waiting to attach” after it crashes-- at no point does it actually attach. It will attach if I then reload the plugin, but then it won’t crash. The Zombies and Leaks tools didn't reveal anything, nor did the memory sanitizers.
Using a Storyboard instead of a XIB didn't change the behavior (not sure why it would, but it was one of the last few differences between this and Apple's example).
I created a very tiny example project which exhibits the problem (unfortunately, I cannot post any code which shows the problem because I cannot find where exactly the problem code is-- maybe it's even a project setting?). It has a minimal GUI, no setFullState, and generates white noise:
https://drive.google.com/open?id=1dw3xTHn3qY411eXLaIb_9_S5PAtrr5Nk
Expected: It doesn't crash or disappear randomly
Actual results: After reloading a project file which uses this AUv3, the plugin will disappear after a few seconds. It initially produces audio normally and the GUI looks OK, but then vanishes.
I've noticed the following error popping up in the console when running my app on iOS 9 when using a storyboard. I'm using xCode7. Is this something I need to be concerned about?
-[UIApplication _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion:] ** unhandled action -> <FBSSceneSnapshotAction: 0x176bfb20> {
handler = remote;
info = <BSSettings: 0x176a5d90> {
(1) = 5;
};
}
There is nothing wrong with your code. This is a logging message internal to Apple, and you should file a radar about it.
There are two hints that show that this is probably Apple's code:
The underscore leading the method name _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion is a convention indicating that the method is private/internal to the class that it's declared in. (See this comment.)
It's reasonable to guess that the two letter prefix in FBSSceneSnapshotAction is shorthand for FrontBoard, which according to Rene Ritchie in "iOS 9 wish-list: Guest Mode" is part of the whole family of software related to launching apps:
With iOS 8, Apple refactored its system manager, SpringBoard, into several smaller, more focused components. In addition to BackBoard, which was already spun off to handle background tasks, they added Frontboard for foreground tasks. They also added PreBoard to handle the Lock screen under secure, encrypted conditions. [...]
I have no idea what the BS prefix in BSSettings is for, but
BS is shorthand for BackBoard Settings, and an analysis of this log message would indicate that it's not anything you did, and you should file a radar with steps to reproduce the logging message.
If you want to try and grab a stack trace, you can implement the category linked to here. Some would argue that overriding private API is a bad idea, but in this case a temporary injection to grab a stack trace can't be too harmful.
EDIT:
But, we still want to know what this action is. So I put a breakpoint on -[UIApplication _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion] and started printing out register values and found a class called FBSceneImpl which had a whole bunch of information about my application:
We are able to find out which private method is called next (stored in the program counter, instruction pointer, register 15.)
I tried finding the un-handled FBSceneSnapshotAction referenced in the log, but no dice. Then, I subclassed UIApplication, and overrode _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion. Now I was able to get at the action directly, but still, we don't know what it is.
Then, I looked at the FBSceneSnapshotAction again. Turns out it has a superclass called BSAction.
Then I wrote a tool similar to RuntimeBrowser and looked up all of the subclasses of BSAction. It turns out that there's quite a list of them:
The two method names we have (one from the log and one from the program counter on the devices) indicate that these actions are used under the hood for passing actions around the system.
Some actions are probably sent up to the app delegate's callbacks, while others are handled internally.
What's happening here is that there is an action that wasn't handled correctly and the system is noting it. We weren't supposed to see it, apparently.
AFAIK, the info above is related to iOS during snapshot the screen (i suppose for double click home multitask related behaviour).I deeply investigated my application and seems that it does not get any side behaviours. You can safely ignore it, for now.
You can use the following gist simple category to test yourself against the calls to the above function:
I have figured it out, it will happen when you have IBAction method declared in .h or .m file but you have not bind it to any control.
.m example:
- (IBAction)click:(id)sender{
}
but not assigned this method to any control in storyboard.
haven't find out why it happens in my app, but at least you can catch the exception, if you want to keep this from popping up in your log pane. It's not a solution, but it might give you more insight why it is happing by inspecting any of the arguments that are passed in the catch.
swift 2 version:
import UIKit
extension UIApplication {
func _handleNonLaunchSpecificActions(arg1: AnyObject, forScene arg2: AnyObject, withTransitionContext arg3: AnyObject, completion completionHandler: () -> Void) {
//whatever you want to do in this catch
print("handleNonLaunchSpecificActions catched")
}
}
I have console applicaiotn that currently uses CAsyncSocket.
I need to implement SSL so after some searching I found this project: http://www.codeproject.com/Articles/3915/CAsyncSslSocketLayer-SSL-layer-class-for-CAsyncSoc
For some reason same simple code that works fine on GUI code does not work in console app.
Has anyone exp. with CAsyncSslSocketLayer ?
Thanks.
CAsyncSocketEx uses a window as a sort of cheap thread to handle the event notifications that come from select(). Unfortunately, if you don't have a message loop, then the window which it creates will not receive these events.
http://support.microsoft.com/kb/90975
This article explains that a call to CreateWindow() needs to be called from a thread which has a message loop. And if you don't, then anything sent via PostMessage() won't get there.
I've recently started to tinker with this -- I want to remove the annoying hidden window and replace it with a normal thread. Their code relies on WSAAsyncSelect() in order to receive socket events... to a window. Yuk!
It's been a while since I had the same problem, but if I remember correctly, to use CAsyncSocket in a console app you need to add something like DECLARE_CONSOLEAPP (first two links shown below) to your console app. This should give your console a message pump to generate the socket notifications (OnReceive, etc.) GUI apps have these pumps but console apps don't, generally. The third (msdn) link below might also apply, it has more info and a different way.
If these still don't work, you should put breakpoints in your socket code and make sure your socket isn't instantiated in a thread or callback other than the main console app (the one that now has the message pump).
I think googling around for 'CAsyncSocket WinApp' or 'CAsyncSocket console app' would show more.
http://www.codeguru.com/cpp/misc/misc/consoleapps/article.php/c243/Console-app-using-MFC.htm
http://troels.knakkergaard.dk/code.htm
http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/a6f1b72a-21d8-4046-a3dc-d7d29ece2ef6
I'm trying to use a recent feature of the Scintilla component, which provides OSX-like text-highlighting effect (the yellow animated bouncing box), and I'm stuck with an error that pops up intermittently :
EXC_BAD_ACCESS
pointing to this particular line :
if (layerFindIndicator!=nil)
if ([layerFindIndicator animationForKey:#"animateFound"])
[layerFindIndicator removeAnimationForKey:#"animateFound"];
(the ifs are mine; just in case I caught the object layerFindIndicator being nil, or deallocated or whatever... Unfortunately, it doesn't help...)
layerFindIndicator is seemingly a subclass of CAGradientLayer. (You may see the full code for layerFindIndicator, here).
Since, I'm an absolute newbie to Quartz Core, could please give me any hint as to HOW this could be debugged?
Since, I'm an absolute newbie to Quartz Core, could please give me any hint as to HOW this could be debugged?
This doesn't have anything to do with QuartzCore specifically (at least, I hope not)—it's general this-object-has-been-killed-before-its-time-how-do-I-find-the-killer stuff.
In Xcode:
Edit your current scheme.
For the Profile action, set it to use the Debug build configuration.
Dismiss that and then hit the Profile command.
Xcode will build for that action and then launch Instruments.
Instruments will prompt you to choose a template; you want the Zombies template. Once you've chosen it, Instruments will create a trace document and run your application. Switch to your application (if it isn't already frontmost), then do whatever causes the crash.
If the crash really is a dead-object crash, Zombies will reveal it. You'll get a flag in Instruments's timeline saying something like “message sent to zombie object 0xd3c2b1a0”, and your program will probably exit shortly thereafter.
In that flag is a tiny little button that looks like this: ➲ except it'll be gray. Click on it.
That takes you to the history of that object (actually of that address, including any previous objects or other allocations that have started at that address). Show your Extended Detail Pane (the one that appears on the right showing a stack trace), then scroll down to the end and then move backward (upward) step by step through time, looking at releases and autoreleases, looking for the one that isn't balancing out the object's allocation or a retain.
The solution will probably involve one or more of:
Changing a property to be strong or weak rather than assign/unsafe_unretained
Adding a property where you previously did not strongly own an object
Rearchitecting some things, if it's not clear which of the above you need to do or if either one of them seems like a filthy hack
Switching to ARC to get weak properties and __weak instance variables (both of which get set to nil automatically when the referenced object dies) and to get local variables being implicitly initialized to nil
But it'll depend on what you find in Instruments. And, of course, there's the chance that your problem—the bad access—isn't a dead object at all and all of the above will not help you.
Try this:
if (layerFindIndicator!=nil){
if ([layerFindIndicator animationForKey:#"animateFound"]){
[layerFindIndicator removeAnimationForKey:#"animateFound"];
}
}
Also check to see if it is released else were.
EDIT:
Another thing I found was you didn't have an white space in the if. Your code should now look like this:
if (layerFindIndicator != nil){
if ([layerFindIndicator animationForKey:#"animateFound"]){
[layerFindIndicator removeAnimationForKey:#"animateFound"];
}
}