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
** Also affects: libpst
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libpst in Ubuntu.
https://bugs.launchpad.net/bugs/1130751
Title:
readpst reports success on crash
Status in LIBPST:
New
Status in libpst package in Ubuntu:
Fix Committed
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/libpst/+bug/1130751/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
