Bug 267179 - PATCH: KFileItem does not check KMimeType::Ptr on null
Summary: PATCH: KFileItem does not check KMimeType::Ptr on null
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: kdecore (show other bugs)
Version: 4.6
Platform: Gentoo Packages Linux
: NOR crash (vote)
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-25 23:49 UTC by Thomas Fischer
Modified: 2013-08-27 21:55 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Checking KMimeType::Ptr on null to avoid crash (973 bytes, patch)
2011-02-25 23:49 UTC, Thomas Fischer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Fischer 2011-02-25 23:49:37 UTC
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
Comment 1 David Faure 2011-04-28 13:30:48 UTC
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).
Comment 2 David Faure 2011-04-30 02:22:44 UTC
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
Comment 3 David Faure 2011-04-30 02:29:06 UTC
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?
Comment 4 David Faure 2011-04-30 02:31:43 UTC
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
Comment 5 David Faure 2011-08-26 16:11:36 UTC
Thomas: ping? Can this be closed?
Comment 6 Thomas Fischer 2011-08-26 16:39:22 UTC
(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.
Comment 7 David Faure 2011-08-29 14:30:42 UTC
Thanks, closing.
Comment 8 Christopher Yeleighton 2013-08-27 21:55:48 UTC
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.