tracker-extract crashed

Another crash followed, explaining that "The problem cannot be reported: Crashes in tracker-extract are intended so that tracker-extract doesn't consume many resources."

I can upload the crash report, but it's quite big, about 20mb, I've archived it in case you need it

As the message explains, crashes in tracker-extract are the consequence of limiting its resources (cpu, memory...), so there's no need to file those bugs.

Let me know if the wording in the message isn't clear or can be improved.

Well it could be a silent crash, there should be no prompts from apport to report the bug :)

Plus, the first crash said that it is damaged and can't be reported, hence I reported that it can't be reported

Savvas Radević escribió:
> Well it could be a silent crash, there should be no prompts from apport
> to report the bug :)
>

That should be a wishlist against apport ;) We're doing what apport let's us do...

Very well, I've added the package for apport, let's see what the apport people say, I really hope they won't bounce back the ball to you in an endless loop.

We don't want to pile up special cases in apport, that's why we have package hooks.

If you want to ignore a particular class of crashes, please add an apport hook to tracker. Please see /usr/share/doc/apport/package-hooks.txt.

Ah, I see what you mean, I was too quick, sorry. Package hooks should have the ability to completely suppress a report without even the dialog box.

Still, can't tracker-extractd fail a little more gracefully instead of triggering a core dump in the kernel? If you don't have apport, then you'll still get core dumps onto your disk. IMHO you should install a signal handler and properly _exit() extractd if it gets such a signal that indicates OOM or another limit.

apport (0.104) hardy; urgency=low

  [ Martin Pitt ]
  * apport/crashdb_impl/launchpad.py, get_source_version(): re-escape the
    package name so that it doesn't stumble over '+' and similar characters.
  * apport/ui.py tests: assert that ProcEnviron is also included into bug
    reports where we do not have a PID, since having the local information is
    interesting and important (and acceptable in terms of personal
    information).
  * apport/report.py: Split out method add_proc_environ() for getting
    ProcEnviron, so that we can call it separately.
  * apport/ui.py, run_report_bug(): Add ProcEnviron if we do not have a pid to
    file a bug against. This way, bugs filed against packages or distro also
    get locale information. (LP: #198514)
  * apport/fileutils.py, mark_report_seen(): Do not crash if the file does not
    exist any more, because it was removed underneath us. (LP: #199932)
  * apport/ui.py, test_collect_info_exepath(): Add a tuple argument and a
    CompressedValue to the test report. This reproduces LP #199349.
  * apport/report.py, anonymize(): Only work on string values. (LP: #199349)
  * apport/ui.py: If a report has a field "Ignore", entirely ignore the report
    without even presenting an explanatory error dialog (as
    "UnsupportableReason" does). Document this in doc/package-hooks.txt.
    (LP: #198863)
  * debian/control: Bump Standards-Version (no changes necessary).
  * debian/control: Fix wrongly spelt project names (Python and GTK+). Thanks
    to lintian's scrutiny.
  * gtk/apport-gtk-mime.desktop.in, qt4/apport-qt-mime.desktop.in: Add a main
    category.

  [ Kees Cook ]
  * apport/report.py: fix module license checking logic (LP: #199927).
    - nonfree_modules: being unable to find a module should not mean the
      module is non-free.
    - test_module_license_evaluation: check modinfo reporting.
  * problem_report.py: Skip atime test case if file system is mounted noatime.

 -- Martin Pitt <email address hidden> Thu, 13 Mar 2008 14:01:30 +0100

It looks like both sides could cooperate to solve this :) I know this is a minor "bug", but I've reported it in order to avoid further reports from other users.
A more graceful failing would be great

Hi,

Savvas Radević [2008-03-13 15:09 -0000]:
> It looks like both sides could cooperate to solve this :) I know
> this is a minor "bug", but I've reported it in order to avoid
> further reports from other users. A more graceful failing would be
> great

I just uploaded an apport which understands an "Ignore" tag, which
tracker should use in its apport hook instead of "UnreportableReason".
However, that'll still waste a lot of resources for dumping core,
calling apport, and throwing it all away. Thus it would be even better
to change tracker to not crash in the first place. :)

Thanks! There must be a way to halt the indexing service more gracefully too, maybe by limiting the resources it uses step by step? Let's here what they have to say.

not an issue anymore