Created attachment 316926 [details] gdb log when kita crashes Description of problem: 2ch client kita (I maintain) crashes when writing messages on 2ch threads twice. Currently I cannot figure out what is the problem. gdb backtrace seems to be showing that the crash is happing on qt3, however I am not sure what is the original culprit so I need your help. Version-Release number of selected component (if applicable): kita-0.177.4-1.fc10.i386 (currently only available on koji) qt3-3.3.8b-14.fc10.i386 kdelibs3-3.5.10-1.fc10.i386 How reproducible: 100% Steps to Reproduce: long explanation... Note: Please test this in Japanese environment. Any 2ch clients won't work other than in Japanese environment because all messages in 2ch are in Japanese 1. launch kita 2. choose one board ("ita") on the left window 3. On the right up window choose one thread name shown in title list 4. On the right down window click "pencil" icon 5. On the popup window write some messages (in Japanese) and write in the thread by pushing "OK" button 6. Again click "pencil" icon. Actual results: kita crash Additional info: gdb backtrace attached
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Normally I would say report this upstream but qt3 is no longer supported. Closing this as WONTFIX.
Hmmm, unfortunately, for packages which have no upstream, it's our (the packagers') responsibility to fix such bugs. (This is one of the problems with compat packages.) However, I'm not convinced this is not an application bug. Do you know where these warnings come from? > QInputContext: cannot create input context for non-toplevel widgets > QInputContext: cannot create input context for non-toplevel widgets I suspect these may be the root cause of the problem. Another potential application error which can cause such crashes is deleting a QObject during signal/slot processing. (A safe way to handle this is to use deleteLater() instead of delete.)
As this is a memory-related error, a Valgrind log could also be useful.
Created attachment 329274 [details] valgrind log of kita Sorry for delay. (In reply to comment #3) > Do > you know where these warnings come from? > > QInputContext: cannot create input context for non-toplevel widgets > > QInputContext: cannot create input context for non-toplevel widgets > I suspect these may be the root cause of the problem. grep shows this is from qt3, more precisely from /usr/src/debug/qt-x11-free-3.3.8b/plugins/src/inputmethods/xim/qximinputcontext_x11.cpp . (In reply to comment #4) > As this is a memory-related error, a Valgrind log could also be useful. (Un)fortunately, when trying with valgrind, kita won't crash.... Anyway valgrind log attached.
Created attachment 329275 [details] refreshed gdb log when kita crashes gdb log retaken
By the way, I am using kita on GNOME desktop environment.
> grep shows this is from qt3, more precisely from > /usr/src/debug/qt-x11-free-3.3.8b/plugins/src/inputmethods/xim/qximinputcontext_x11.cpp But Qt emits this warning when its function is being used incorrectly. Input contexts may only be added on toplevel widgets (i.e. windows), not on controls. In any case, your Valgrind log contains plenty of buffer overflows and use-after-free bugs. (It also keeps using delete where delete[] is required, but I think g++ will let you get away with that one.) There's also one use of an uninitialized value. So I think this is an application bug.
Hmmm, one thing: what input method software are you using? If it's something which links in Qt 4 into the Qt 3 executable, then that would be a problem. scim-bridge should be safe (it's designed exactly to prevent that sort of issues).
Sorry for delay. I am using scim-bridge now. Unfortunately my C++ knowledge is limited and for now I cannot debug this issue easily.
Update: Well, actually kita seems to crash when - I enable scim on the first writing - and then try the second writing on the other hand, today I tried ibus and there does not seem to be any problem currently. So I guess something is wrong with kita <-> scim (as scim-bridge was running I thought this issue was not due to scim, but it seems related...) As F-11 will use ibus I will close this bug as WONTFIX.