How to handle unreproducible bugs - bug-tracking

Did you ever find yourself in this position - a bug is reported by the client but you are unable to reproduce the bug. Even the QA team is unable to reproduce the bug. We are facing such a situation with our desktop application(C#, windows forms). What do you suggest we should do to reproduce the bug, or track the scenario which generates the bug.

Yes, this is a common situation.
I find that the best way to handle this situation is to log as much as possible in log files and get the customer to send the log files to you for analysis, as well as their description of what they were doing when the problem occurred. The customer description is often very incomplete and misses out important details about what they were doing when the error happened. A detailed log can help fill out the holes in the story.
If you are lucky enough that the log file includes a stack trace it is often possible to reason about possible causes of the error even if it is a rarely occuring bug that you have not been able to reproduce yourself. In this situation a code review of the affected code can reveal flaws in the design of the code and suggest an alternative approach that is less likely to fail.

This all dependes on what kind of bug you are facing (Logic, User Interface, Multi Threaded, Or actual User).
Ensure that the client has given you
all the required info to reproduce
the bug.
If at all possible, have the client
show you how to reproduce the bug, or at the least send some screen shots of how it was done.
Ensure that you write some Unit Test
to try and cover the bug, try proving that it is there.

Related

Stackoverflow Exception raising only without Visual Studio [closed]

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
I have a difficult WPF application, which works with PTL, many third-party libraries and network. In developer workstation it works fine (in release mode too), but when I run it in client workstation - I got stackoverflow exception in same input data. Also app crashed always in different places.
So, my questions are:
I know, that its impossible to catch stackoverflow exception by try-catch-finally. But may be exists any workaround to understand which module generate this problem?
What different between client and developer environment, if all third-party libraries are equals?
I know, that its impossible to catch a StackOverflowError exception using try-catch-finally.
It is not impossible. Just highly inadvisable, and it probably won't fix the issue. (The best a handler could do would be to abandon what ever caused the problem and try to continue. But what if the application needed the result that was being computed? Or what if the application tries the same computation again?)
But may be exists any workaround to understand which module generate this problem?
Without knowing the real cause of the problem, there is no good workaround.
How do you find the real cause of the problem? Debug the application!
What different between client and developer environment, if all third-party libraries are equals?
In general it could be any of the following:
Different Java versions
Different OS versions
Containers and/or virtualization
Different networking environments
Different external tools installed
Different file system layouts
Different users or file permissions
Different Java application configs
Different input data / databases.
and probably a few more besides. In short there are potentially lots of things that could be different that could cause different behaviors. You might be able to discount some of these as not relevant, but it is also possible to be wrong about that.
IMO, looking for the differences is the wrong approach. A better idea is to debug your application in the client environment. Read the stacktrace, read the code, attach a debugger to the JVM and set breakpoints, etc to try and find out what is actually happening.

Should I wait before publishing App with Core-Data and iCloud until it is more stable?

(as at 1st June 2012)
A very simple question I would really appreciate input from others (I think we all could) who are either wondering the same or have decided to go with it (if so, any user experiences shared would be great).
I have 2 main issues which seem common on stackoverflow and on various blogs, so I know I'm not the only person experiencing them.
Occasionally my sync gets corrupted for one reason or another and the sync either fails on certain data or fails to sync altogether.
Pre populating data is essential for my app, there's no reliable way of doing this (without asking the user - which isn't reliable)
I've seen many good work arounds to both these issues but I can't help feeling that my users will encounter problems still.
I'd be really interested to learn of any experiences particularly from those that have decided to publish using iCloud and Core-Data.
iCloud has been around a while now but even on iOS 5.1.1 it doesn't seem stable enough, surely a more reliable version can't be too far away.
It is hard to answer this one without "Making statements based on opinion", but it's one worth giving partially backed up opinions on to hopefully save others some time and frustration.
My opinion is that it's just not ready. I unfortunately have an app in the wild at the moment based around CoreData + iCloud and even though we danced around a number of iCloud bugs to finally get it stable enough to pass reasonably thorough testing some users are still running into the corrupted sync states. I've spent a healthy portion of my recent life trying to make it work and am currently reluctantly reimplementing the app without Core Data. I really hope that it stabilizes soon as I genuinely like most of it.

Recommendations for automatically logging unexpected errors/stack traces to bug tracker

We have been looking at automatically logging all unexpected client errors to our bug tracker. For reference our application is written in Java/GWT/Guice/Hibernate/Jetty and our bug tracker is the hosted version of FogBugz which can create bugs programatically or via an email.
The biggest problem I see with doing this is stack traces that happen in a loop overload the bug tracker by creating thousands of cases. Does anybody have a suggested way to handle automatic bug creation like this?
If you're using FogBugz bugscout (also see up-to-date docs here) then it has the ability to just increase number of occurences of same problem, instead of creating new case for same exception again and again.
Are you sure that you want to do that?
It obviously depends on your application but even by carefully taking care of the cases that could generate lots of bug reports (because of the loops) this approach could still end up filling the bug tracker.
How about this?
Code your app so that every time an exception is thrown, you gather info about the client (IP, login, app version, etc) and send that + the stack trace (or the whole exception object .ToString()) by email to yourself (or the dev team).
Then on you email client, have a filter that sorts that incoming mail and throws it in a nice folder for you to look at later.
Thus you can have tons of emails about maybe one of more issues but then you don't really care because you input the issues yourself in the bugtracker, and easily delete that ton of mail.
That's what I did for my app (which is a client-server desktop app). It plays out well in this case.
Hope that helped!
JIRA supports automated issues creation using so called services: documentation.
Does anybody have a suggested way to handle automatic bug creation...?
Well, I have. Don't do that.
What are you going to gain from that? Tester's effort? in my experience, whatever effort one can save from that was lost multiple times with overhead transferred to developers who had to analyze and maintain the automatically created tickets anyway. Not to mention overall frustration caused by that.
The least counterproductive way I can imagine would be something like establishing a dedicated bugs category or issue tracker instance, such that only testers can see and use it.
In that "sandbox", auto-created bugs could be assigned to testers who would later pass analyzed and aggregated bug reports to developers.
And even in that case, I'd recommend to pay close attention to what users (testers) say about the system. If they, say, start complaining about the system, consider trying a manual way of doing things instead.

UIWebview issues

I am using a UIwebview in my iphone app. It is working fine. No memory leaks when you browse websites, google, news etc. But when you start a video in youtube then it shows me many memory leaks (Under AudioToolBox library). How do I fix them. I imported AVFoundation.h and audioToolBox.h and added these frameworks but I am still getting the same problem.
One more thing, I know apple checks no connectivity condition. Means when there is no internet available or connection problem then user must get some message about connection issues. How do you do that? How do i check internet is connected? what kind of message do you show? Alert or something else?
Do I also need to show activity indicator? How do you show that? can you please reply with sample code?
Apple's designated way of checking connectivity is "try it first". If you get connection problems, you can diagnose with their Reachability suite, available here. But always try first, because Reachability can give false negatives in some situations.
As far as UIWebView's memory problems, I don't think you're in a position to do anything about them. Hope they get fixed in iOS5, I guess. If you want to use AVMediaPlayer for rich media, like Safari and UIWebView do, use it directly, rather than going through WebKit.

Creating and Getting a Security Advisory Published

This question comes from my experience with the following question: https://stackoverflow.com/questions/492748/new-responses-icon-on-so-crashes-ie7-closed
In that question, you will see the effort I put fourth in debugging this crash in IE, and in doing so, I can see the potential threat of exploitation and remote code execution.
So, being that I spent the time already, I was wondering if anyone knows all the steps and proper process/procedures one has to take to actually get a real security advisory published? I've never done it, and a couple quick searches didn't turn up anything on the subject.
It's been a week since I posted the question, so this exploit has mold growing on it already, but I still haven't seen it addressed yet, so the threat still exists.
If you have done this type of thing before, would you be willing to help someone out?
The first step is to contact the vendor.
A quick google revealed this page, which, if you click on "I need to report a possible security vulnerability to Microsoft.", instructs you to send a mail to secure[at]microsoft.com. Honestly I'd give that a shot.
Note that after the initial "thank you" mail, you may or may not hear anything back from them until they make decisions about the severity and urgency of the issue, or even until you see the update notification pop up on your own machine.

Resources