38935 2010-05-11 14:38:21 -0700 [Qt][Symbian] data URIs cause crash at QFile layer 2010-05-14 08:24:48 -0700 1 1 1 Unclassified WebKit WebKit Qt 528+ (Nightly build) S60 Hardware S60 3rd edition RESOLVED INVALID Qt P2 Major --- 1 s.mathur webkit-unassigned hausmann kenneth laszlo.gombos markus oldest_to_newest 224165 0 55759 s.mathur 2010-05-11 14:38:21 -0700 Created attachment 55759 repro case [reporting on behalf of Jyri-Petteri Huttunen and Tom Hechang as reported on s60qt mailing list. The fix might be cross-platform, if QtWebkit can be changed to avoid involving QFile at all in case of data URIs] Use case: --------- We currently have an issue related to showing image in base64 format in Qwebkit. We create a simple qt application which has a qwebview and load a pic.html. The application run normally on windows, and will show a red cross on screen. While we build the application on symbian^3/4, it will crash when start the app. We are wondering if this is a bug for qt webkit. The pic.html is attached. Prelim analysis by Shane Kearns: ------------------------------- The findBackend() function calls each backend factory in an iterator. The first one to successfully process the request is used. The file backend calls QFileInfo("data:.......").exists() which crashes inside open C. open C needs to check the length of filenames passed to stat(), fopen() etc to prevent a buffer overrun panic when it is asked for a filename that is longer than the OS can support. Once open C is fixed, then the exists() function would return false; and the data backend would be tried (and presumably succeed). 224235 1 laszlo.gombos 2010-05-11 16:16:46 -0700 If this can not be addressed in OpenC - or lower in the stack - (which seems to be the best place), we should consider trying to address it in QtCore/QFileInfo before looking into changing QtWebKit. 225725 2 hausmann 2010-05-14 02:21:29 -0700 (In reply to comment #1) > If this can not be addressed in OpenC - or lower in the stack - (which seems to be the best place), we should consider trying to address it in QtCore/QFileInfo before looking into changing QtWebKit. I agree, this is not a QtWebKit issue at all. I think we should close this bug report. Markus, what do you think about avoiding the stat on Qt? Even though I agree that OpenC shouldn't crash (d'oh!), we shouldn't call QFileInfo::exists on data urls either. 225736 3 markus 2010-05-14 03:08:18 -0700 I can try work around it in Qt, but OpenC needs to fix this too. 225740 4 markus 2010-05-14 03:45:40 -0700 Actually this uncovered a "bug" in Qt. Fix is pending in Qt 4.6 staging repo as c1423c03d69f51d76b3629f2fedce555696759fa This bug can be closed as soon it has been re-tested with a Qt with this commit. The patch is at http://qt.pastebin.com/XkRBg7dL .. Still OpenC must not crash for too long filenames. 225826 5 s.mathur 2010-05-14 08:10:46 -0700 (In reply to comment #4) > Actually this uncovered a "bug" in Qt. Fix is pending in Qt 4.6 staging repo as c1423c03d69f51d76b3629f2fedce555696759fa > > This bug can be closed as soon it has been re-tested with a Qt with this commit. The patch is at http://qt.pastebin.com/XkRBg7dL .. > > Still OpenC must not crash for too long filenames. Does the above change fix the problem that file-system shouldn't be pinged at all when the raw image data is already supplied? If the file-system is still being touched, it is a performance problem. For 100 such icons, 0.001 seconds will be for decoding images and blitting them, 2 seconds for stat()ing files. :) 225828 6 markus 2010-05-14 08:16:40 -0700 Don't worry :) The order is now the "correct" one: static void ensureInitialized() { #ifndef QT_NO_HTTP (void) httpBackend(); #endif // QT_NO_HTTP (void) dataBackend(); #ifndef QT_NO_FTP (void) ftpBackend(); #endif #ifdef QT_BUILD_INTERNAL (void) debugpipeBackend(); #endif // leave this one last since it will query the special QAbstractFileEngines (void) fileBackend(); } 225831 7 kenneth 2010-05-14 08:23:56 -0700 (In reply to comment #6) > Don't worry :) > The order is now the "correct" one: > > static void ensureInitialized() > { > #ifndef QT_NO_HTTP > (void) httpBackend(); > #endif // QT_NO_HTTP > (void) dataBackend(); > #ifndef QT_NO_FTP > (void) ftpBackend(); > #endif > > #ifdef QT_BUILD_INTERNAL > (void) debugpipeBackend(); > #endif > > // leave this one last since it will query the special QAbstractFileEngines > (void) fileBackend(); > } So it is fixed now? Can we close this bug? 225832 8 s.mathur 2010-05-14 08:24:48 -0700 OpenC to fix their crash in TRLM-84XDAF QtNetwork fix in c1423c03d69f51d76b3629f2fedce555696759fa (thanks Markus! :) ) 55759 2010-05-11 14:38:21 -0700 2010-05-11 14:38:21 -0700 repro case pic.html text/html 1243 s.mathur PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiINCiJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFuc2l0aW9u YWwuZHRkIj4NCjxodG1sIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIj4NCiAg ICA8aGVhZD4NCiAgICAgICAgPHRpdGxlPjwvdGl0bGU+DQogICAgICAgICAgICAgICAgPG1ldGEg aHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRG LTgiIC8+ICAgICAgICAgICANCiAgICA8L2hlYWQ+DQogICAgPGJvZHk+DQogICAgICAgICAgPGlt ZyBzcmM9ImRhdGE6aW1hZ2UvcG5nO2Jhc2U2NCxpVkJPUncwS0dnb0FBQUFOU1VoRVVnQUFBQmtB QUFBV0NBWUFBQUExdnplMkFBQUFCM1JKVFVVSDJBVVNFZ29scmdCdlZRQUFBQWx3U0ZsekFBQUxF d0FBQ3hNQkFKcWNHQUFBQUFSblFVMUJBQUN4and2OFlRVUFBQUhsU1VSQlZIamE1VmJOU2h4QkVL NlphWHRuSFRlYlFQQTFnbmdObWZhZXErUU5QSWxJWGtDOWlRZEp4Sk52RUhMTjNWa3hoeHhFOGdU bUVoQVZkZFhaNlozZjlOZHJpejg5L3NIbWtCUVVWVlQxZkI5ZDljM3VPRVJVS1R1bklkbjNIenN0 eEdwWUJEUzR3Wms3VEFKai93bEo5MEoram51eWdxczhzdlNqKy9yR0hCb3MzckUxOFhCdmZVM25v N056bEpmVWFZLzV3aEF3bDhMci9XRFV2NE9EeFRNYitQNXhMRXhlNUxtTzU1OVdxVFgvTVFSNFda WUVBdFNlUFM0cEUwcVNudWhuUlVjQlU1R20yazlYbGpVNFoyNkkzTlJ4QnJkODByajJmaCtLTkUw Rlk0eGV2UmdUalJFdlBGcGFzQUs4WGxpNk1VYmJ1S3czYWZBR2dTQlhvem81dTRoa21uY0Fsa2w1 d3g4aU1HYmR5UWpuQ0ZFaUV3R2lvc2oxVVFBL3gyclZkZGlWb2krbDRJeEUwUFREbngrbXJRQnZ2 bng5Y0Z6M2tyaFZ2dWh6Rm41NzkvYXEvbjVyVzhmYnRUcWlXaElRWkVvMTdZQnZia3hPWE5WbmRu WXBUdm9kN0F0aXVOMnJlMCtzaXdjQjlvSDhWeHhyTndRUUFoenlSczMwbjd3VEkySElOMmcyUXRR d2pqaEpJUWF0T3E3RThiSVZDTHd6cGw4M0x2dHZsK05vaFdXbEU4VVpUV0VNQUdDY1I3N2ZIS2hQ blpGNXRZaWU2ZGZkeENwaEFDbUxQTStqOGJZZm1UcnlnNjRrVjlWaDNtVjhqUDBiLzR3Ty9ZVVBp VC84aTBNTGY1NWxTUUFBQUFCSlJVNUVya0pnZ2c9PSIvPiANCiAgICAgICAgICA8IS0tPGltZyBz cmM9Im11cHBldHMuanBnIiAvPi0tPg0KICAgIDwvYm9keT4NCjwvaHRtbD4NCg==