Project

General

Profile

Actions

Task #3189

closed

crash-reporting server access to analyze crash dump

Added by Miklos Vajna almost 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Tags:

Description

Hi,

Any chance you can get Lubos Lunak () some shell access to the crash-reporting server & some database pointers there? We want to grab the CPU identifier out of the raw dumps family 6 model 42 stepping - type thing - eg. https://crashreport.libreoffice.org/stats/crash_details/a0c7e859-d0c8-4bf0-a737-7cefad7114d5 - so that we can analyze our fleet (of crashers) and what CPUs we should be optimizing for.

Understanding the 32bit vs 64bit ratio, if SSE1 and SSE2 support is still useful -- these would be good to understand, and data is needed for that.

Thanks,

Miklos


Files

known_hosts.txt (794 Bytes) known_hosts.txt ~/.ssh/known_hosts snippet for crashreport Guilhem Moulin, 2020-04-21 16:26
Actions #1

Updated by Guilhem Moulin almost 4 years ago

  • Assignee set to Guilhem Moulin

Any chance you can get Lubos Lunak () some shell access

Can't find him in pillar so we need an SSH pubkey and a password digest for the shadow(5) database (use for instance `mkpasswd -m SHA-512`, from the ‘whois’ package on Debian). For obvious reasons please use for the latter (or both).

Actions #2

Updated by Guilhem Moulin almost 4 years ago

Might not need the password for read-only access though; but lacking an SSH key anyway.

Actions #3

Updated by Luboš Luňák almost 4 years ago

Mail sent.

Actions #4

Updated by Guilhem Moulin almost 4 years ago

Done Luboš Luňák, you should be able to login to `` (~/.ssh/known_hosts snippet attached) with that key, and run `psql crashreport`. You have read-only access to these tables:

base_version
crashsubmit_uploadedcrash
processor_*
symbols_*

Look at the `processor_processedcrash.raw` column for the crash_id or cpu_info you're interested in. There is no index on cpu_info though so filtering on it is gonna be terribly slow.

Actions #5

Updated by Guilhem Moulin almost 4 years ago

  • Status changed from New to Closed
Actions #6

Updated by Luboš Luňák almost 4 years ago

Would it be possible to get access to the actual dumps? The processed info lacks many things that are included in the dumps, such as the actual /proc/cpuinfo content. And figuring out things like sse2 would be much simpler if I could simply get it directly for the entries rather than somehow painfully try to figure that out from the CPU type.

Actions #7

Updated by Michael Meeks almost 4 years ago

My understanding is that the 'Raw' output is all we have from the client eg. the content of the 'raw dump' tab here:

https://crashreport.libreoffice.org/stats/crash_details/a735081d-6347-4f46-a9c8-dfaf4347b69e

And that anything else in the UI is built by looking up that address data in debugging symbols on the server.

I'd be surprised if we have more than what is there; I agree it is really sparse, and we'll need to do quite some typing and database of family/model/stepping etc. to determine CPU features - but there it is; we can't re-generate that data easily at all.

Actions #8

Updated by Luboš Luňák almost 4 years ago

The crashsubmit_uploadedcrash database refers to .dmp files in /srv/crashreport/temp, so I expect that's what we get from clients. It seems we keep only a month's worth of backlog, but analyzing that should be still better than doing all that manual work based just on the subset of data we extract from it.

Actions

Also available in: Atom PDF