Should I land it on master or it seems good enough for the stable branch?

Just to clarify the email used is going to be public anyway in the commit history.

Emails on identity.kde.org are only public for developers or to sysadmins. Can you post it here?

Thanks for the patch.

Hi, thanks for the patch.

Hi, thanks for the patch. Hopefully this is the last calibration issue, unfortunately I can't really test/track them down because I currently don't have access to a screen tablet.
I should make a bugfix release with it in the next few days.

• do not ignore results of PostingDB::iter in case of an error/end of db

• fix MTimeDB::get loop

• review warning fixes

• fix ::del error logging criteria, don't return without closing cursor in

• update logging per review

is it now how it's supposed to look in the end? not really sure where .category syntax is defined

• update categories per review

• use new syntax for baloo.categories

• move new logging category to D18873: add baloo engine debugging category

• clean up rest of the asserts

In D18664#404173, @poboiko wrote:

1. Are we actually sure this is gonna fix all those crashes? Otherwise I would suggest using CCBUG instead of BUG inside the commit message.

I've chosen those bugs based on backtraces I could get myself but without core dumps I can't vouch for that, even with core dumps it'd be hard to tell. Alternatively I can CCBUG and after this gets into a release, ask in those bugs people if they still experience the crash and close them if they won't get back in a month or so.

1. For now, logging is the only way to know if there's something bad going on. In that case I would suggest to at least increase severity of those messages - it would increase chances users will notice it. For example, use qCCritical (but this would also require additional check for okayish/non-critical return codes, such as MDB_NOTFOUND)

These errors have good potential to flood users log files. I get around 30 megabytes of those on each boot. I'd rather see them disabled by default.
It might make sense to add a catch-all error message somewhere on higher level, that would get printed out once, but I haven't looked yet where such message could be placed.

1. Looks like this patch is composed of two parts - introducing new logging category and and improving error handling. It would be also nice to split those into two separate patches.
2. There are a lot of redundant Q_ASSERT_X left, which could be removed. I suggest just grep'ing over the code to catch'em all. I've started marking them here, but then I gave up - too many of them.
3. There are also several unchecked return codes as well, such as inside *DB::size() calls. Those can also be found by grep'ing over Q_ASSERT_X.

I'll look into these this week.

• unbreak documentdatadb::contains, oops :(

neither QWidget::adjustSize() nor QWidget::adjustedSize() seem to use devicePixelRatio (https://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/kernel/qwidget.cpp#n8665), but I can't test that to vouch that it works on HiDPI as intended
I can land it as is but I don't really want to break kcmshell further for HiDPI users

Landed it on 5.1, messed up with arc so it didn't close the diff
https://cgit.kde.org/ktorrent.git/commit/?id=2d73d5f25a1a364a2115fb1d3262377f7fdf99cd

Backtraces are a bit inconsistent, usually it ends with malloc aborting with invalid porinter or other memory error

• fix typo

I don't know, it's frameworks after all but I guess I can land it today since it's a popular bug. Should I just land it on master since there seem to be no other branches?

• add link to qt bug

I think it's this bug/suggestion: https://bugreports.qt.io/browse/QTBUG-10459

Context for the size hint limitation this patch is supposed to circumvent: https://code.woboq.org/qt5/qtbase/src/widgets/widgets/qscrollarea.cpp.html#403