Features Download
From: Alexandre Rebert <alexandre.rebert <at> gmail.com>
Subject: Re: Reporting 1.2K crashes
Newsgroups: gmane.linux.debian.devel.general
Date: Tuesday 25th June 2013 14:54:21 UTC (over 4 years ago)

Thanks for all the feedback and comments. I tried to address all them

> The crash.sh script seems to set LD_LIBRARY_PATH.  Is that actually
> needed?  I'd prefer something that doesn't need something like that,
> since being able to crash apps if you load a broken library isn't very
> hard.

The purpose of the custom environment is to run the program with the
same environment as it was set up when the program was analyzed with
Mayhem. This is not necessary to reproduce most crashes however. I
will remove the *LIBRARY_PATH from the environment, and re-confirm the
crashes without it.

> Since you're already running this under gdb, would you mind attaching a
> full backtrace with debug symbols installed too?

That is a good idea, but I'm afraid I cannot easily get the debug
symbols. As far as I know, binaries from debian packages do not
contain symbols. Additionally, for 91% of the packages where we found
a crash, there isn't any associated -dbg package. It should be easy
however for a developer that has a program with debug symbols to
generate the backtrace. I could include a backtrace without symbols,
but that does not seem particularly useful. What do you think?

> Would it be possible to initially publish all the bug reports on your
> web site under some random URL and then mail that to the maintainer
> with a clearly indicated date when they will be made public?

Good point. I will mail the maintainer the bug reports, and give them
1 week to prepare before submitting the bug to the Debian BTS.

> Can one also access, even before you go and file bugs, information for
> packages? I cannot actually find any reports for the package listed in
> dd-list under my name in your Packages, Runs, nor Programs pages. (And
the fact
> that the reported package is a transitional package does make this a
> suspicious.)

The reports are not public yet. Since you are a developer included in
dd-list, we will send you an email containing the crash information
for the programs you are developing. You will receive the email 1 week
before the crash is submitted to the BTS. Does that sound reasonable?

> Have you considered adding Mayhem to Debian so
> that it may be added to the usual battery of tests some developers run
> before uploads?

We are considering offering Mayhem as a web service as opposed to
adding it to Debian.  I'd love to see Mayhem check every package
release automatically, so that (some) crashes are detected and fixed
before the binary being released. Mayhem is however not open source,
so I'm not sure people will be willing to make use of it. Let me know
if you think otherwise, and we'll discuss how we can set this up.

> Are you aware of the firehose project and format that Fedora and some
> Debian folks have been working on? It is a standard machine-readable
> format for defect finding tools to report their findings so that sites
> like the Debian PTS can report those to developers.

I was not aware of firehose. This is a cool project. It would be great
to have a similar system for dynamic analysis of binaries, that allows
non-free software to submit reports. Even though Mayhem is not open
source, we still want to improve Debian's security and stability :)

The Mayhem Team
Cylab, Carnegie Mellon Univeristy
CD: 3ms