errors indicates a retraced crash but isn't showing a stack trace

Bug #1267112 reported by Jean-Baptiste Lallement
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Daisy
Fix Released
High
Brian Murray

Bug Description

Several crash of Ubiquity (really libautopilot-gtk) have been uploaded to errors.ubuntu.com [1]. The page on errors.u.c indicates a retraced crash but isn't showing a stack trace for it.

These crashes are uploaded automatically with whoopsie-upload-all when automated tests [2] find a crash file.

[1] https://errors.ubuntu.com/problem/8ff8c9bfa3317b35d4a1af984e0e4208acd7af42
[2] https://jenkins.qa.ubuntu.com/view/Ubiquity/view/All/?

Related branches

Evan (ev)
Changed in errors:
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Brian Murray (brian-murray) wrote :

I've looked into this a bit and manually queried the error tracker in an attempt to find the stack trace. One thing of note and that needs fixing is that get_stacktrace_for_bucket in errors/cassandra.py (https://bazaar.launchpad.net/~daisy-pluckers/errors/trunk/view/head:/errors/cassandra.py#L168) only checks 10 crashes. I manually changed my version of cassandra.py to get 300 crashes but I was still unable to find a Stacktrace or ThreadStacktrace for this particular problem.

Additionally, I grep'ed the retracing logs for the two instances (4b5ea464-a941-11e3-b525-2c768aafd08c, d25d6b60-a943-11e3-ae27-2c768aafd08c) of the crash that jibel reported the other day and did not find them being retraced at all.

Revision history for this message
Brian Murray (brian-murray) wrote :

Additionally stacktrace_cf.get(sas, colums=cols) always returns a NotFoundException for any StacktraceAddressSignature associated with the crash.

Revision history for this message
Evan (ev) wrote :

We really should at some point create a direct mapping of bucket to Stacktrace (maybe as a new CF called bucket_stacktrace with a key of the bucket, column names of the SASes, and column values of the stacktraces). This going via all the OOPSes to get an SAS to get a Stacktrace was an awful mistake on my part.

Revision history for this message
Brian Murray (brian-murray) wrote :
Revision history for this message
Brian Murray (brian-murray) wrote :

Curiously, most of these first appeared with trusty.

Revision history for this message
Brian Murray (brian-murray) wrote :

After looking at the retracer code for a while, I think these could be disappearing as a result of the the general exception handling in the retracing process.

https://bazaar.launchpad.net/~daisy-pluckers/daisy/trunk/view/head:/daisy/retracer.py#L538

In the event that there is any exception the .new file will be removed and then if the .new file does not exist we'll go to failed_to_process() and remove it from retracing and delete it from the queue.

Revision history for this message
Brian Murray (brian-murray) wrote :

The log message associated with .new not being there is '.new did not exist' and:

brian@snakefruit:/srv/app-logs/cassabanana/production-crashdb-retracer-logs$ grep 'new did not exist' * | wc -l
1328

this is a significant number as in the same log file 2455 were successfully retraced.

Revision history for this message
Brian Murray (brian-murray) wrote :

I've landed a logging change to daisy that might reveal the problem, jibel could you re-run the tests with the workaround disabled?

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :
Revision history for this message
Brian Murray (brian-murray) wrote :

Well, the error message I'd expect to see in the logs hasn't appeared at all. Can you give me a .crash file from one of those failing install tests so I can try manually retracing it?

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :
Revision history for this message
Brian Murray (brian-murray) wrote :

I was able to manually retrace this using canonistack and the following command:

PYTHONPATH=$PYTHONPATH:/srv/daisy.staging.ubuntu.com/production/apport /srv/daisy.staging.ubuntu.com/production/apport/bin/apport-retrace -v -S /srv/daisy.staging.ubuntu.com/production/daisy/retracer/config ~/_usr_lib_ubiquity_bin_ubiquity.0.ubuntu_nonenglish_lvm_amd64_103.crash -o /tmp/updated.crash

Revision history for this message
Brian Murray (brian-murray) wrote :

Ah-ha! Loading the .crash with apport reveals that:

ipdb> report.crash_signature()
'/usr/lib/ubiquity/bin/ubiquity:11:GtkNode::MatchStringProperty:xpathselect::XPathQueryPart::Matches:SelectNodes:GetNodesThatMatchQuery:Introspect'

Because crash_signature exists the crash is treated as a python one and bucketing then fails.
https://bazaar.launchpad.net/~daisy-pluckers/daisy/trunk/view/head:/daisy/submit.py#L167

affects: errors → daisy
Changed in daisy:
assignee: nobody → Brian Murray (brian-murray)
status: Confirmed → Fix Committed
Revision history for this message
Brian Murray (brian-murray) wrote :

This has landed now, please regenerate the crashes and we should be able get a Stacktrace for them now.

Revision history for this message
Brian Murray (brian-murray) wrote :
Changed in daisy:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.