Created attachment 57531 [details] Checking KMimeType::Ptr on null to avoid crash Version: 4.6 (using KDE 4.6.0) OS: Linux Messing around with my shared mime info system, I noticed that KDE applications started to crash right after starting them. Even considering that the mime system was in an inconsistent state, this should not happen. Using the crash dialog's backtrace, I located the root of the problem in KFileItem. There are at least two functions which do not check if a KMimeType::Ptr is null and thus fail in calling "is(...)" on this Ptr: - QString KFileItem::iconName() const - static bool checkDesktopFile(const KFileItem& item, bool _determineMimeType) I will attach a patch which will check the Ptr on "isNull()" to avoid the crash (at least in my case). I suspect that more functions are affected as well (such as QString KFileItem::mimeComment() const ), so I suggest a review of this class. Reproducible: Always
KMimeType::findByUrl should never return null, on a correctly configured system. When it doesn't find the mimetype, it should return application/octet-stream. But indeed if even that mimetype is not available, then it returns 0, which crashes apps. However I don't think the solution is to add null checks everywhere. I'd rather fix KMimeType so that it creates application/octet-stream all by itself if it can't find it on the system, and return that. It would keep every 'application' code simpler (where kfileitem is an 'application' too, i.e. a user of KMimeType).
Git commit b16ce3737443a4e3f6dee54cdd519d5f409f3ffc by David Faure. Committed on 28/04/2011 at 15:08. Pushed by dfaure into branch 'master'. Test the case where there are no mimetypes installed at all. Surprisingly, it works: KMimeType::findByUrl does not return NULL, contrary to what the bug report says. There must be a subtle difference somewhere. CCBUG: 267179 M +1 -1 kdecore/io/kmessage.h M +1 -0 kdecore/tests/CMakeLists.txt A +75 -0 kdecore/tests/kmimetype_nomimetypes.cpp [License: LGPL (v2+)] http://commits.kde.org/kdelibs/b16ce3737443a4e3f6dee54cdd519d5f409f3ffc
Ah, the command "XDG_DATA_DIRS= kde4-config --path xdgdata-mime" still returns many paths here on my system. I guess for you it's empty?
Git commit 9a4eb075c8974d5a109b23a0c524e32c982d8cdb by David Faure. Committed on 30/04/2011 at 02:41. Pushed by dfaure into branch 'master'. Fix usage of KStandardDirs in case there's no xdgdata-mime dir. This might fix 267179, please test. CCBUG: 267179 M +1 -1 kdecore/services/kmimetyperepository.cpp http://commits.kde.org/kdelibs/9a4eb075c8974d5a109b23a0c524e32c982d8cdb
Thomas: ping? Can this be closed?
(In reply to comment #5) > Thomas: ping? Can this be closed? I could not reproduce the problem since I fixed my mime type problem back in February and I don't remember how to reproduce it. Furthermore, XDG_DATA_DIRS= kde4-config --path xdgdata-mime returns /home/abc/.local/share/mime/:/usr/share/mime/ which seems to be a valid value. Yes, this bug report can be closed.
Thanks, closing.
But the test fails: [ 4452s] Start 50: kdecore-kmimetype_nomimetypes [ 4452s] [ 4452s] 50: Test command: /home/abuild/rpmbuild/BUILD/kdelibs-4.10.5/build/kdecore/tests/kmimetype_nomimetypes.shell [ 4452s] 50: Test timeout computed to be: 120 [ 4452s] 50: /home/abuild/rpmbuild/BUILD/kdelibs-4.10.5/build/kdecore/tests/kmimetype_nomimetypes.shell: line 4: 11194 Aborted LD_LIBRARY_PATH=/home/abuild/rpmbuild/BUILD/kdelibs-4.10.5/build/lib/./:/usr/lib64:/home/abuild/rpmbuild/BUILD/kdelibs-4.10.5/build/lib/.:/usr/lib64${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} "/home/abuild/rpmbuild/BUILD/kdelibs-4.10.5/build/kdecore/tests/kmimetype_nomimetypes" "$@" [ 4452s] 50/155 Test #50: kdecore-kmimetype_nomimetypes ........***Failed 0.07 sec strace says: access("/usr/share/mime/application/x-zerosize.xml", R_OK) = 0 The test is bogus.