readpst reports success on crash

Bug #1130751 reported by era
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
LIBPST
Fix Committed
Undecided
Unassigned
libpst (Ubuntu)
Undecided
Unassigned

Bug Description

I have had a couple of crashes with readpst, but the Makefile which runs the job just happily continues as if there had been no problem.

Unfortunately, these issues seem timing / threading related, so it is somewhat hard to repro. I am rerunning the failed jobs in a separate window while the Makefile continues the main job and they are succeeding when I rerun them.

I can understand if a parser for a murky file format does not always remain robust. I would grudgingly tolerate the crashes if they were duly reported. But the absence of an error condition when they happen is completely unacceptable, and could lead to grave mistakes in my processing results.

Steps to repro, as best I can describe them;

 1. Have a bunch of humongous PST files. I am processing the EDRM Enron corpus, http://www.edrm.net/resources/data-sets/edrm-enron-email-data-set-v2

 2. Run readpst on all the files. Pay attention to the menu bar. Observe every once in a while (twice so far today) a "Crash report detected" icon.

Expected outcome:

The Makefile should have stopped if there was a crash. In other words, readpst should have returned a non-zero result code in the event of a failure.

Actual outcome:

Processing continues as if there hadn't been a problem.

Workaround (painful version):

From the crash report "whoopsie" dialog, figure out which job failed, and rerun it. I have verified with diff that the results from one of the crashes lacked a number of output files which were created correctly when I ran the same command a second time from the command line, into a different output directory. As long as I am here to keep an eye on things, this works ...

Workaround (speculative):

The manual page hints at a "-j 0" option to disable parallel jobs. I speculate that the handling of parallel tasks is where the bug lies, but I do not yet have any proof that this actually helps.

$ lsb_release -rd
Description: Ubuntu 12.04.2 LTS
Release: 12.04

$ apt-cache policy readpst
readpst:
  Installed: 0.6.54-0ubuntu1
  Candidate: 0.6.54-0ubuntu1
  Version table:
 *** 0.6.54-0ubuntu1 0
        500 http://fi.archive.ubuntu.com/ubuntu/ precise/universe amd64 Packages
        500 http://mirrors.nic.funet.fi/ubuntu/ precise/universe amd64 Packages
        100 /var/lib/dpkg/status

$ apt-cache policy libpst4
libpst4:
  Installed: 0.6.54-0ubuntu1
  Candidate: 0.6.54-0ubuntu1
  Version table:
 *** 0.6.54-0ubuntu1 0
        500 http://fi.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status

Revision history for this message
era (era) wrote :

For what it's worth, I have submitted the whoopsie reports, but I was unable to find any reports for readpst at https://errors.ubuntu.com/ ... Maybe I lack privileges, or skills.

Revision history for this message
Ivan Zakharyaschev (imz) wrote :

The upstream maintainer turned out to coincide with the Redhat maintainer, namely, Carl.

So, I'd suggest to just report your problem at the Redhat bugzilla and reach the upstream this way.

Revision history for this message
Ivan Zakharyaschev (imz) wrote :

http://hg.five-ten-sg.com/libpst/rev/6abc3054cba2 in 0.6.67 must probably fix this:

libpst

changeset 358:6abc3054cba2

From Jeffrey Morlan:

If a readpst child process fails with a nonzero status code for
whatever reason (killed, segfault, out-of-memory, ...) the parent
process will continue and likely end up exiting with status 0,
tricking the caller into thinking readpst was successful when it was
not.

Changed in libpst (Ubuntu):
status: New → Fix Committed
Ivan Zakharyaschev (imz)
Changed in libpst:
status: New → Fix Committed
Olly Betts (ojwb)
Changed in libpst (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers