A Qt project gives a number of errors - that I do not actually consider errors I think:
Some examples:
Fontconfig error: "/etc/fonts/conf.d/65-khmer.conf", line 32: out of memory
// ?
QGraphicsItem::ungrabMouse: not a mouse grabber
// i think happens when the mouse grab didn't quite happen, user moved too fast...
A few others
the first one seems it has an answer here https://askubuntu.com/questions/421891/fontconfig-error-out-of-memory
So I cannot fix it through software, the user must fix it... since it is system dependent...
Even built in release, these errors will still show up on command line... Since they do not cause the application to behave abnormally, I don't think the user should see them.
How can I build/deploy the application without these errors showing ?
ideally of course there would be no errors in a deployed application, but I don't know what I can do about those types of errors...
It is possible to redirect a stream (in this case stderr) after the fact using
freopen("/dev/null", "w", stderr);
Just place this in your main before any other code runs and you should be good. Keep in mind that this might need more work on Windows.
If the error message is posted through the Qt Message infrastructure (qDebug etc.) you can set a new message handler through the function qInstallMsgHandler.
Related
It's an aspx web site. It's Huuuge. Oftentimes, we won't see errors until building the entire site. But it's always told us where the error is.
This time, I'm getting an Object reference not set to instance of an object. error with file, no line, no location. Double clicking on the error just does... nothing.
Error 3 Object reference not set to an instance of an object.
I've tried a few things that I've found here and elsewhere but nothing seems to be helping out or giving me more information. I've tried change the verbosity of compiler/build messages but those goggles don't seem to help.
Edit: Very specifically, the first time I try to build the site after opening the project, it says it builds just fine. Trying to build it again causes the error. Closing VS (2013) and reopening the project allows a first time build success and subsequent builds are failures. It should also be noted that it's not actually building anything because it completes far far too quickly - almost instantly.
Can anyone give me some ideas on how to track this down?
It turns out that the VS installation is completely broken. Banging on the keyboard like a monkey and then trying to build succeeds when it should not.
I'm trying to debug an issue on a clients machine. The problem is that the problem is a runtime error with very little clue as to where it is. It is an intermittent problem. I know ADL allows me to run the application in a debug mode. The problem is that to tell the user to download and manage the ADL invokation is going to be very difficult. It would be a lot easier if I could just give the end user one install/executable to install and run and then send me the trace of the issue. So what I'm looking for is easy steps for the client to be able to run the AIR app in debug mode. Downloading ADL and finding the install location of the app is going to be difficult to manage remotely with the end user.
Update:
You have to make sure you are working with AIR 3.5 and Flash 11.5 and also include the following flag "-swf-version=18" in additional compiler settings. You then have to catch the global error as mentioned in the answer and it will show you the location of the error. No line numbers of course. Just routine names. Thanks a milion to Lee for the awsome answer.
not a direct answer but if you publish for AIR3.5 (or 3.6 beta), you can get some debug info:
add a listener for uncaught RTEs to top level of your app:
this.loaderInfo.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR, globalErrorHandler);
and grab debug info from error in listener:
function globalErrorHandler(event:UncaughtErrorEvent):void
{
var message:String;
//check for runtime error
if (event.error is Error)
message = (event.error as Error).getStackTrace();
//handle other errors
else if (event.error is ErrorEvent)
message = (event.error as ErrorEvent).text;
else
message = event.error.toString();
//do something with message (eg display it in textfield)
myTextfield.text = message;
}
getStackTrace will return a stack trace even for release AIR apps (as long as you use AIR3.5 or above).
Without the SDK Tools; I don't think it is possible to run an aIR app in debug mode. But, here are a few alternatives to consider:
The client must have some idea what is going on to cause the error, right? Can you give them a special build with Alert Boxes or logging or something to help isolate the error to a line of code?
Can you listen for the uncaughtException event? The event will give you the full stack trace ( Error.getStackTrace() ); which you could then log--possibly with other information. Then you just have to tell your client to "Go here" and "send me this file." Or even display the info in some Alert and have the user copy and paste it into an email to you. More info on uncaughtException here and here
check my post. Maybe it helps you to get stack trace with line numbers in a AIR release build.
How can I get stacktrace for Adobe AIR global runtime errors in non-debug mode?
I use it in 2 big projects right now and it works very well.
Greetings
I get an EXC_BAD_ACCESS error at a place that doesn't have anything to do with the root cause. I fortunately found the reason to be an array that was too small for the following statement [data getBytes:&tcpBuffer length:i];.
Now my question: I tried all these theree methods - but without success:
Using NSZombiesEnabled did not change anything in the debug window printout
When I set the scheme to debug and to use Leaks instrument it starts the leaks instruments but I don't see the debugger.
When I just run the app in iPhone Simulator and the start Instruments separately, selecting the running app as a target (in the pop-up-menu in Instruments) it stops with an error saying something like "couldn't find the target ".
How does one find the root cause in cases like that? Keep in mind, at the end, it wasn't even a Zombie error! This error message is REALLY more confusing than helpful!
(luckily I just thought of my array, but surely, the next time this will haunt me somewhere else)
It's quite likely that the place you get the EXC_BAD_ACCESS will not be related to the root cause. It could be related and could therefore offer a clue. But that's not certain.
To answer your points:
NSZombiesEnabled will only have an effect if you invoke a method on an object that has been deallocated. That might not be the cause of your EXC_BAD_ACCESS.
Using Instruments is separate to the debugger. If you profile in Instruments, the debugger is not active. Basically, it's a different tool.
This should be ok. Check that your Build Configuration is set to "Debug" and not "Release".
Here's a great link on what causes EXC_BAD_ACCESS and how to track down the root problem:
Lou Franco's Understanding EXC_BAD_ACCESS
I've written a c# windows app, that performs some DB intensive operations. (MySQL connector v6).
When running the project in Debug mode, everything works fine. However, when I run the prject in release mode, it sometimes quits operation midway - with no error message, nothing in the event logs etc.
What would be the best way to debug release mode - when everything works in debug mode?
Thanks for any help,
Bob
You can create a log file and have the application write lines to it with information of your choice, similarly to how the console may be used for debug purposes in a windows form application. You can write values of certain variables to this file, or even just write distinct phrases in select places of the code that will help you detect where the program is in execution when it fails.
Bobby is correct in asking about Application Event Log. If it is bombing on a .NET error, it will likely be logged.
If that doesn't give you anything, wrap the entire app in a try/catch block. On your exception handling, log the error (application log, file, etc...). Make sure when you log it to capture the call stack.
I've got exactly the same problem - application running in debug mode and fail in release. Try the following:
Wrap everything in Program.cs in try{}..catch{} block and it will show a reason
I don't know why but my application failed on Program.SetCompatibleTextRenderingDefault() function with message that it should be called before any instances on IWin32Window or something like that
It is very strange errors for me cuz i didn't have any code before this function. But you can try - maybe it will show something useful for you
How many can relate do this?
Server Error in / Application
Object reference not set to an object
Description: Object reference not set to an object.
Exception Details: System.NullReferenceException: Object reference not set to an object.
Source Error:
Line 56: posts.Add(post);
On a more serious note, what are the first things you look for when you see the
yellow screen of death? Half the time the debug trace isn't actually telling you what the problem is (understandable I guess).
I must admit, I still use Response.Write more than I should. I just get lazy going through the debugger. What techniques do you use to debug the problem?
If I'm unable to identify/resolve the issue using the error message that the page presents to me, I will typically try to use the Windows Event Viewer to help me identify what is causing the issue.
For example, SharePoint errors are sometimes far less than descriptive. So, I'll combine what I'm seeing on the Y.S.O.D. with error messages from the Event Viewer to help me narrow down the cause.
I will do my best to ask a co-worker or other associate that I think might have some experience that might help. If I'm still unable to identify the cause, I will resort to Google armed with all the information.
Here's how I try to reduce the number of YSODs. One of the first things I do when starting work on an app is to create a custom exception class.
Add properties such as the SQL
statement being run. Two display
message text fields, one for display
to users, one for display to
developers (in debug mode) Who is
the logged-in user. Get all the form
variables so you know what they were
trying to enter.
Log the errors somewhere (event log
is good, if you can access the web
server; logging to the database is
less successful when so many
exceptions are inability to access
the database).
Create code in the MasterPage or web page base class Page Error events and Application Error events to do the logging.
Create a custom error page. When in
debug mode, the custom error page
displays everything. When not in
debug mode (production), display
only selected properties of the
custom exception.
Investing the time up front to do this will save you many hours of anguish later.
I usually do my debugging on my local machine with the Cassini web server (comes with VS 2005/2008). If I see an exception on my QA or, heaven forbid, my production box it's usually because I forgot to update my connection strings so that they point to the QA/production database instead of my local machine.
In other cases, I've found the stack traces to be very helpful in determining where to provide breakpoints so I step through it in the debugger and examine the data at runtime. The only time I've written any debugging information on the page was when trying to find some performance issues that I couldn't replicate on my developer instance. In this case I wrote some hidden fields that contained timing information about various parts of the render process.
the error info provided, assuming you are in debug mode, will give you information as to what line the error actually occurred on, along with the lines of code leading up to the error. This info should give you a good start on defining where to set your break points for debugging.
I was once in your shoes many moons ago, using response.write for debugging. Once you start using the IDE and debugger as it's intended you'll find yourself pulling out less hair and getting to the solutions much faster.
Also, opening up the immediate window while debugging is gonna make your life even more happy.
Use a decent logging framework such as log4net, and be liberal in your use of DEBUG-level logging.
It's essentially a neater version of your Response.Write approach, which can be left in your production code and "switched on" when required.