[Ohrrpgce] CrashRpt report summaries

[James Paige]

This crash reporting feature is great. I just read through a bunch of them.

I am not sure what is best re putting the reports in the wiki. Is the idea
that we want to be able to mark them resolved? Would it be better (if
noisier) to put them in the issue tracker?



On Sun, Aug 18, 2019, 10:11 PM Ralph Versteegen <teeemcee at gmail.com> wrote:

> I decided to added usernames to the listing and summary table because it's
> the easiest way to figure out which reports are coming from the same
> person, especially if they only give their email address or name once. And
> the username is typically visible in a lot of log output or .rpg path
> anyway. But we could, for example, instead generate a unique ID on each
> computer.
>
> On Mon, 19 Aug 2019 at 14:03, Ralph Versteegen <teeemcee at gmail.com> wrote:
>
>> An update.
>> http://tmc.castleparadox.com/ohr/reports20190819.txt
>>
>> We're currently up to 52 valid crash reports, and few empty or test ones.
>> Here's a listing. There's better summary information now at the bottom of
>> the file.
>> There are a few interesting crashes, such as three identical ones inside
>> in the Sell menu, with the comment "I was testing a game I was created, and
>> the game crashed when I selected the sell menu. This also occurs in other
>> games as well"
>> Many people are hitting the MIDI loop crash, which causes quite a lot of
>> different stacktraces.
>>
>> I'm still planning to create a page on the wiki with a table of the
>> summaries where we can add additional notes and triage them, and links to
>> the bug tracker (with detailed investigations of certain crashes). The wiki
>> seems the easiest place for that, since we need to be able to edit. I need
>> to write a script that can update it while preserving edits. But I don't
>> want to put the more detailed information than summaries on the wiki, it
>> would be too much. And what about privacy, should I even be putting
>> usernames, .rpg filenames, partially-masked emails, which are in the
>> summary table, in public view? What about the detailed version, which may
>> include, for example, locales and filenames encountered while browsing?
>>
>> On Fri, 15 Mar 2019 at 16:39, Ralph Versteegen <teeemcee at gmail.com>
>> wrote:
>>
>>> We've now collected a few crashes from CrashRpt. Currently showbug
>>> doesn't generate a report, but I will add that too. There are also many
>>> more errors that could be converted to showbug.
>>> Even with just a 10 reports so far, it's a pain to go through them, so
>>> I've written a tool, misc/process_crashreports.py, to analyse them.
>>>
>>> Generating a backtrace from the minidump was tricky -- I tried
>>> Microsoft's windbg and cdb and CrashRpt's own crprober but they all
>>> generated garbage, only Visual Studio's debugger (which is completely
>>> separate) worked. So I used Breakpad to analyse the minidumps instead,
>>> that's extra complexity but works great and is cross-platform and well
>>> maintained (Breakpad is used by both Chrome and Firefox and has associated
>>> client-side libraries to replace CrashRpt too not that I'm planning to)
>>>
>>> Unfortunately wine is still needed to generate the .sym files from the
>>> .pdb file, so the process couldn't really be done on the server
>>> automatically. We could easily generate the .sym files (eg during the
>>> nightly build) and upload them with the pdbs, but still, if we can't run
>>> git on the server, then we can't annotate the backtraces with source code.
>>> But aside from that git isn't really needed, so I guess we could generate
>>> and email nearly-full report summaries automatically with the crashrpt php
>>> script.
>>>
>>> But otherwise, I'll just manually run the tool on the reports from time
>>> to time.
>>>
>>> I've attached the generated summaries of those 10 reports.
>>> There is a summary of the summaries at the bottom of the file.
>>> Still not summarised enough. My summary of those summary-summaries is:
>>> -one is a crash in DESCRIBE_TAG_AUTOSET_PLACES, which I know about but
>>> have been lazy about fixing
>>> -two are new to me, they are in MAPEDIT_APPEND_IMPORTED_TILEMAPS. I
>>> found the cause of this. Hurrah! It was worth it!
>>> -three are crashes while playing a MIDI file. So that still happens,
>>> although I can't reproduce it anymore :(
>>> -the last four are from Charbile's gfx_sdl2 testing
>>> --one is inside SDL2.dll and is the crash he reported when fullscreening
>>> at 1280*720
>>> --the other three are in switch_gfx_backend, but this manifests as two
>>> different backtraces
>>>
>>> We're going to need a better way to keep track of all of these. A text
>>> file with annotations is probably good enough, plus filing bug reports for
>>> crashes so we have a bug number to refer to.
>>> But crashrpt actually has an accompanying web server/app for collecting,
>>> summarising and filing reports: http://crashfix.sourceforge.net/
>>> CrashFix is probably quite overwrought for this task though.
>>> (To my surprise, it can actually parse minidumps and pdb files to in
>>> order to produce stack traces, on linux. All other tools use Microsoft's
>>> libraries to read pdb files, including Breakpad.)
>>>
>>> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20190819/69c28246/attachment.html>