> On May 1, 2014, 1:23 p.m., Frank Reininghaus wrote: > > Note 1: an even better fix would probably be to repair or delete and > > re-create the broken database if a Xapian::DatabaseOpeningError exception > > is thrown, but my knowledge of the Baloo/Xapian internals is not sufficient > > for that. > > > > Note 2: https://bugs.kde.org/show_bug.cgi?id=333465 is about a crash due to > > an unhandled Xapian::DatabaseCorruptError, but without backtrace. Maybe > > it's thrown at the same location, I don't know. > > Vishesh Handa wrote: > Yes, deleting it is probably a good idea if it is corrupted. Hmm, we'll > need to restart the baloo_file process as well, and then tell it to reindex > everything.
Thanks for your feedback. It would be cool if this could be implemented at some point :-) I'll push this patch for the time being such that at least the crash is fixed. - Frank ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117930/#review57056 ----------------------------------------------------------- On May 1, 2014, 1:14 p.m., Frank Reininghaus wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117930/ > ----------------------------------------------------------- > > (Updated May 1, 2014, 1:14 p.m.) > > > Review request for Baloo. > > > Bugs: 333763 > http://bugs.kde.org/show_bug.cgi?id=333763 > > > Repository: baloo > > > Description > ------- > > https://bugs.kde.org/show_bug.cgi?id=333763 shows that the Xapian database > constructor can throw an exception, which is not handled at the moment. This > patch wraps all Xapian-related stuff in Baloo::FileFetchJob::doStart() in a > try {...} block and catches all exceptions. > > The alternative would be to only add a catch statement for the > Xapian::DatabaseOpeningError which seems to be thrown according to the bug > report, provided that we can be 100% sure that no other exceptions can be > thrown there. IMHO, a library that uses external libraries that can throw > exceptions should try as hard as possible to catch all exceptions. > > > Diffs > ----- > > src/file/lib/filefetchjob.cpp 21f5520 > > Diff: https://git.reviewboard.kde.org/r/117930/diff/ > > > Testing > ------- > > Unit tests still pass. > > > Thanks, > > Frank Reininghaus > >
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
