Version: (using KDE Devel) Installed from: Compiled sources This occurs when I click on the newsgroup in the left-side list after starting KNode. Interestingly, if I subscribe to the newsgroup, I can click on it all I want and it works fine. Crashing only occurs after KNode has been restarted and loads the preexisting subscription. This problem occurs only for one newsserver that I wrote today. Other news servers work fine. I I have, to my knowledge, designed my news server to implement the RFC properly in addition to the XOVER extension, with the exception of the NEWNEWS command (which is disabled on many other servers). Either way, nothing the server does should be able to crash KNode... If testing is needed, the server is currently running on tsurukikun.utopios.org port 2119. #0 0x00002aaaadf08f82 in QGArray::QGArray(QGArray const&) () from /usr/qt/3/lib/libqt-mt.so.3 #1 0x00002aaaaacd93a2 in KNRemoteArticle::setHeader(KMime::Headers::Base*) ( this=0x78c5e0, h=0x793490) at qmemarray.h:60 #2 0x00002aaaaacbb226 in KNGroup::loadHdrs() (this=0x832800) at kmime_headers.h:577 #3 0x00002aaaaacb0a71 in KNGroupManager::loadHeaders(KNGroup*) ( this=0x7fffffffd920, g=0x832800) at kngroupmanager.cpp:313 #4 0x00002aaaaacb0dbd in KNGroupManager::setCurrentGroup(KNGroup*) ( this=0x8776a0, g=0x832800) at kngroupmanager.cpp:565 #5 0x00002aaaaad2d388 in KNMainWidget::slotCollectionSelected(QListViewItem*) (this=0x8aa070, i=0x7802b0) at knmainwidget.cpp:1093 #6 0x00002aaaaad30a3e in KNMainWidget::qt_invoke(int, QUObject*) ( this=0x8aa070, _id=48, _o=0x7fffffffdef0) at qucom_p.h:312 #7 0x00002aaaadca0888 in QObject::activate_signal(QConnectionList*, QUObject*) () from /usr/qt/3/lib/libqt-mt.so.3 #8 0x00002aaaadf92e18 in QListView::selectionChanged(QListViewItem*) () from /usr/qt/3/lib/libqt-mt.so.3 #9 0x00002aaaadd748e9 in QListView::setCurrentItem(QListViewItem*) () from /usr/qt/3/lib/libqt-mt.so.3 #10 0x00002aaaadd7660a in QListView::contentsMousePressEventEx(QMouseEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #11 0x00002aaaacac19ae in KListView::contentsMousePressEvent(QMouseEvent*) ( this=0x8670d0, e=0x7fffffffe130) at klistview.cpp:790 #12 0x00002aaaadd9835b in QScrollView::viewportMousePressEvent(QMouseEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #13 0x00002aaaadd9a504 in QScrollView::eventFilter(QObject*, QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #14 0x00002aaaadd6f13e in QListView::eventFilter(QObject*, QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #15 0x00002aaaaad380f7 in KNCollectionView::eventFilter(QObject*, QEvent*) ( this=0x8670d0, o=0x76b600, e=0x7fffffffe6f0) at kncollectionview.cpp:442 #16 0x00002aaaadc9df77 in QObject::activate_filters(QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #17 0x00002aaaadc9e05e in QObject::event(QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #18 0x00002aaaadcd2523 in QWidget::event(QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #19 0x00002aaaadc47d3d in QApplication::internalNotify(QObject*, QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #20 0x00002aaaadc4826e in QApplication::notify(QObject*, QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #21 0x00002aaaad0b5621 in KApplication::notify(QObject*, QEvent*) ( this=0x7fffffffedc0, receiver=0x76b600, event=0x7fffffffe6f0) at kapplication.cpp:549 #22 0x00002aaaadbed117 in QETWidget::translateMouseEvent(_XEvent const*) () from /usr/qt/3/lib/libqt-mt.so.3 #23 0x00002aaaadbebdd8 in QApplication::x11ProcessEvent(_XEvent*) () from /usr/qt/3/lib/libqt-mt.so.3 #24 0x00002aaaadbfcbab in QEventLoop::processEvents(unsigned) () from /usr/qt/3/lib/libqt-mt.so.3 #25 0x00002aaaadc5be65 in QEventLoop::enterLoop() () from /usr/qt/3/lib/libqt-mt.so.3 #26 0x00002aaaadc5bdc2 in QEventLoop::exec() () from /usr/qt/3/lib/libqt-mt.so.3 #27 0x0000000000409d88 in main (argc=-4672, argv=0x7ffffffff0c8) at main.cpp:41
I'm able to reproduce this with your server. The problem is an additional space behind header names in its response to the 'LIST OVERVIEW.FMT' command. However this should of course not crash KNode, I'm working on a patch.
Interestingly, I recall adding that space because I was troubleshooting another problem I was having and noticed that my INN server had a space at the end... That was before I realised Ethereal shows non-printable chars (and tabs) in a confusing way. ;) Do you want me to leave the bug-space in my server for now for testing or is it okay if I fix it?
I've just finished the tests, so you can change the server.
CVS commit by vkrause: More robust handling of optional headers in XOVER responses. This should at least prevent crashes if the response of LIST OVERVIEW.FMT is not exactly what we expected. CCBUG: 101354 M +9 -2 kngroup.cpp 1.84 M +1 -0 knnntpclient.cpp 1.61 --- kdepim/knode/kngroup.cpp #1.83:1.84 @@ -258,7 +258,14 @@ bool KNGroup::loadHdrs() buff = f.readLine(); int pos = buff.find(':'); + QCString hdrName = buff.left( pos ); + // skip headers we already set above and which we actually never should + // find here, but however it still happens... (eg. #101355) + if ( hdrName == "Subject" || hdrName == "From" || hdrName == "Date" + || hdrName == "Message-ID" || hdrName == "References" + || hdrName == "Bytes" || hdrName == "Lines" ) + continue; hdrValue = buff.right( buff.length() - (pos + 2) ); if (hdrValue.length() > 0) - art->setHeader( new KMime::Headers::Generic( buff.left(pos), art, hdrValue ) ); + art->setHeader( new KMime::Headers::Generic( hdrName, art, hdrValue ) ); } } @@ -456,5 +463,5 @@ void KNGroup::insortNewHeaders(QStrList hdrName = hdr.left( pos ); // if the header format is 'full' we have to strip the header name - if (hdr.findRev("full") == (int)(hdr.length() - 5)) + if (hdr.findRev("full") == (int)(hdr.length() - 4)) data = data.right( data.length() - (hdrName.length() + 2) ); --- kdepim/knode/knnntpclient.cpp #1.60:1.61 @@ -403,4 +403,5 @@ void KNNntpClient::doFetchNewHeaders() if (getMsg(tmp)) { for(QCString s = tmp.first(); s; s = tmp.next()) { + s = s.stripWhiteSpace(); // remove the mandatory xover header if (s == "Subject:" || s == "From:" || s == "Date:" || s == "Message-ID:"
CVS commit by vkrause: Backport fix for #101354 (More robust handling of optional headers in XOVER responses, this should at least prevent crashes if the response of LIST OVERVIEW.FMT is not exactly what we expected). BUG: 101354 M +9 -2 kngroup.cpp 1.83.2.1 M +1 -0 knnntpclient.cpp 1.60.2.1 --- kdepim/knode/kngroup.cpp #1.83:1.83.2.1 @@ -258,7 +258,14 @@ bool KNGroup::loadHdrs() buff = f.readLine(); int pos = buff.find(':'); + QCString hdrName = buff.left( pos ); + // skip headers we already set above and which we actually never should + // find here, but however it still happens... (eg. #101355) + if ( hdrName == "Subject" || hdrName == "From" || hdrName == "Date" + || hdrName == "Message-ID" || hdrName == "References" + || hdrName == "Bytes" || hdrName == "Lines" ) + continue; hdrValue = buff.right( buff.length() - (pos + 2) ); if (hdrValue.length() > 0) - art->setHeader( new KMime::Headers::Generic( buff.left(pos), art, hdrValue ) ); + art->setHeader( new KMime::Headers::Generic( hdrName, art, hdrValue ) ); } } @@ -456,5 +463,5 @@ void KNGroup::insortNewHeaders(QStrList hdrName = hdr.left( pos ); // if the header format is 'full' we have to strip the header name - if (hdr.findRev("full") == (int)(hdr.length() - 5)) + if (hdr.findRev("full") == (int)(hdr.length() - 4)) data = data.right( data.length() - (hdrName.length() + 2) ); --- kdepim/knode/knnntpclient.cpp #1.60:1.60.2.1 @@ -403,4 +403,5 @@ void KNNntpClient::doFetchNewHeaders() if (getMsg(tmp)) { for(QCString s = tmp.first(); s; s = tmp.next()) { + s = s.stripWhiteSpace(); // remove the mandatory xover header if (s == "Subject:" || s == "From:" || s == "Date:" || s == "Message-ID:"
You need to log in before you can comment on or make changes to this bug.
KDE Bug Tracking System
KDE Bug Tracking System 