apport doesn't include Package in report when invoked on core dump

Yes, ApportLog.txt shows I did the testcase twice (I usually do), but the second time no core was written in my local dir. Is this another problem perhaps?

Kind regards,

Alain

$ ls -l core
-rw------- 1 miki miki 290816 2009-11-24 19:02 core

Notice the signals causing the core dumps in the two runs are _different_.
If I would want to backtrace/debug the core locally, I would like to deal with the most recent event (also matching the crash report).

Kind regards,

Alain

Apport avoids expensive operations (such as finding the corresponding package, checking md5sums, etc.) at the time the core dump happens. This information is added when re-processing the .crash report in the UI. For apport-retrace you can use -R (see manpage).

Op woensdag 25-11-2009 om 10:44 uur [tijdzone +0000], schreef Martin
Pitt:
> Apport avoids expensive operations (such as finding the corresponding
> package, checking md5sums, etc.) at the time the core dump happens. This
> information is added when re-processing the .crash report in the UI.

Quite reasonable. Thanks for the information.

> For apport-retrace you can use -R (see manpage).

Sadly, the -R option actually isn't documented in the manpage for the
current released apport-retrace. I see it does show up when I run
`apport-retrace --help`.

Kind regards,

Alain

Op donderdag 26-11-2009 om 03:19 uur [tijdzone +0100], schreef Alain
Kalker:
> Op woensdag 25-11-2009 om 10:44 uur [tijdzone +0000], schreef Martin
> Pitt:
> > For apport-retrace you can use -R (see manpage).

How do I pass that option to apport-retrace from apport-chroot?

Kind regards,

Alain

Alain Kalker [2009-11-26 2:25 -0000]:
> How do I pass that option to apport-retrace from apport-chroot?

You can't: In a chroot (especially a minimal pbuilder-like one) the
system relies on _existing_ and correct Package: and Dependencies:
fields in order to be able to install the missing packages and
-dbgsyms. So you can't rebuild package information in a chroot, this
has to happen on the system where the crash happened.

Alain Kalker [2009-11-26 2:19 -0000]:
> Sadly, the -R option actually isn't documented in the manpage for the
> current released apport-retrace.

Fixed in trunk r1650, thank you!

Op vrijdag 27-11-2009 om 22:44 uur [tijdzone +0000], schreef Martin
Pitt:
> Alain Kalker [2009-11-26 2:25 -0000]:
> > How do I pass that option to apport-retrace from apport-chroot?
>
> You can't: In a chroot (especially a minimal pbuilder-like one) the
> system relies on _existing_ and correct Package: and Dependencies:
> fields in order to be able to install the missing packages and
> -dbgsyms. So you can't rebuild package information in a chroot, this
> has to happen on the system where the crash happened.

Ok, sorry for the misunderstanding. At the time I wrote down that
question, I didn't know enough of what apport-retrace -R is supposed to
do.
For proper crash analysis, it's important to gather as much evidence as
possible, as soon as possible, so I assumed apport's crash interceptor
would gather enough information to create a 1:1 mapping to an
application's requirements. Enough information to do offline analysis
on.

This does raise another question: why do you use a package's
Dependencies and not the actual libraries from ProcMaps (including that
is a very smart move BTW :-) ) to decide which -dbgsym packages to
install?
For crash analysis it is not that important which packages a package
_claims_ to Depend on, it matters which libraries were _actually in its
address space_ when it crashed.
For example, an application might have pulled in a library from another
package during dynamic linking, or it might have dlopen'ed a plugin
library either of which were not explicitly listed as a dependency.
Heck, even a piece of malware might have tricked the application into
loading a totally unrelated library.
That's what crash analysis is supposed to concern itself with, IMO :-)

Kind regards,

Alain

Op zaterdag 28-11-2009 om 12:27 uur [tijdzone +0100], schreef Alain
Kalker:
> This does raise another question: why do you use a package's
> Dependencies and not the actual libraries from ProcMaps (including that
> is a very smart move BTW :-) ) to decide which -dbgsym packages to
> install?

May I propose another (complementary) workflow?

- On the machine doing the retracing, use apt-file (package: apt-file)
to gather a list of all files in all packages available in the active
repositories on the crash machine.
- For the executable and all libraries listed in ProcMaps, do an
`apt-file search` to get the packages to which these libraries belong.
- Get the corresponding -dbgsym packages.
- If any library listed in ProcMaps doesn't show up in `apt-file
search`, trigger an update (`apt-file update`), and repeat the search
once more.
- If still no match, we're SOL (assume the library is
proprietary/unsupported and be done with it).
- Finally, do the retrace.

I do realize that this doesn't replace the current workflow (for
interpreted languages you will still need another dependency resolver),
but it can greatly enhance it.

Kind regards,

Alain

Alain Kalker [2009-11-28 11:27 -0000]:
> This does raise another question: why do you use a package's
> Dependencies and not the actual libraries from ProcMaps (including that
> is a very smart move BTW :-) ) to decide which -dbgsym packages to
> install?

It's actually doing both: It first installs all the packages in
Dependencies:, and then trawls through ProcMaps to grab some more on a
best-effort basis.

Dependencies is preferred because it contains the version numbers of
the library packages, so that we know why a retrace failed.
ProcMaps.txt doesn't provide that.

> For crash analysis it is not that important which packages a package
> _claims_ to Depend on, it matters which libraries were _actually in its
> address space_ when it crashed.

Right, but due to the way the shlibs system works in Debian/Ubuntu,
library dependencies are very reliable.

> For example, an application might have pulled in a library from another
> package during dynamic linking

These are included in Dependencies: (it's the full transitive
dependency tree).

> , or it might have dlopen'ed a plugin library

Those are collected from ProcMaps parsing indeed.

Op zaterdag 28-11-2009 om 12:54 uur [tijdzone +0000], schreef Martin
Pitt:
> Alain Kalker [2009-11-28 11:27 -0000]:
> > This does raise another question: why do you use a package's
> > Dependencies and not the actual libraries from ProcMaps (including that
> > is a very smart move BTW :-) ) to decide which -dbgsym packages to
> > install?
>
> It's actually doing both: It first installs all the packages in
> Dependencies:, and then trawls through ProcMaps to grab some more on a
> best-effort basis.

Wow, thanks for the info. You definitely seem to have covered all the
bases :-)

Kind regards,

Alain