On 2010-10-10 05:39 , Sven Aluoor wrote:
Howto analyze that for non-programmes? Attached the crash logs. Please
give me tips in extracting useful infos out of crash logs.
I wish to help this Open Source project ;)
about the only way you can help an open source project is by getting
involved directly with the project, so why not get involved on the
Vienna forum? even if you are not a developer, quality bug reports,
documentation and testing are valuable contributions
in fact there are some discussions matching the pattern of your crash logs:
<http://www.cocoaforge.com/viewtopic.php?f=18&t=22387>
<http://www.cocoaforge.com/viewtopic.php?f=18&t=22215>
<http://www.cocoaforge.com/viewtopic.php?f=18&t=22050>
how do i know these are similar? the crash logs shown there have a
similar trace in the crashed threads in your logs; this similar pattern
is the "signature" of the crashlog, not always identical, but similar
enough that you can be pretty sure the crashes are related
for non-programmers, and even for programmers who aren't actually
working with the code, to read a crash log is a process of inference;
recognizing the "signature" so you can tell whether your crash is
similar to others' is the first step; beyond that it helps quite a lot
to understand how software runs (not just how code is written)
i look for the stack of the crashed thread (starting with "thread x
crashed"), and read the symbol names below for something meaningful,
bearing in mind that the topmost line in the thread stack is the most
recent (most deeply nested) call, where the crash actually happened; the
second item on each line is the library in which the call is found and
4th is the most interesting -- it's the symbolic name of the function
(sometimes these are numbers only, which is pretty useless for inference)
often the first line or lines in the trace will indicate a low-level
function which doesn't tell you much; the top few lines of your crashing
thread's stack are about hashing and dictionaries; this is typical stuff
that all apps do, and tells you very little unless you are actually
debugging the code
so you read down the stack (back through the sequence of calls) for
something more interesting; your crashes look like they occur in the
course of reading feeds (all the "URLConnection" symbols), probably
while finishing that process for either one feed or all the feeds
(inferred from the the "cleanup", "release" and "destroyReadStream"
symbols); so i was not surprised when the forum thread i found is titled
"Vienna Crashing on Refresh of Subscriptions" -- perhaps your
observation of Vienna prior to the crash would confirm this
so basically you have a problem that others have also had; if you look
through those threads you'll find that someone has already pinpointed
the problem:
"This is unfortunately an Apple bug, a regression in Mac OS X 10.6.3. I
actually discovered the bug while working on another project,
ClickToFlash. I've filed a report with Apple detailing steps to reproduce.
The crashes seem to occur when URLs do HTTP 301 permanent redirect. To
avoid the crashes, you need to find out which of your subscriptions are
redirecting."
and there are some suggestions there for mitigating it; so unless you
are actually going to write some code, the most you can do is help with
this particular bug is to test any future fixes, and/or to write a
tutorial to help other users learn how to weed out feed URLs that lead
to redirects
_______________________________________________
MacOSX-talk mailing list
[email protected]
http://www.omnigroup.com/mailman/listinfo/macosx-talk
