Bug 133312

Created attachment 17577 [details]
The crash backtrace

Created attachment 17578 [details]
Updated backtrace with -g3 -ggdb3

Got no clue here. Can't reproduce it, that's for sure. And the BTs look innocent enough: It does what it should, until it goes boom up there in the string list. The DccChat after it is instanciated doesn't have any link to the Server object, so there shouldn't be any potential for races in there. Since Chris is starting the chat, after the tab has been opened, we append a CTCP PRIVMSG to the server's output buffer, which is that string list in the BT, via Server::queue(). 

konversation: Server::getIp(): using RPL_USERHOST
konversation: DccChat::DccChat() [BEGIN]
konversation: DccChat::listenForPartner() [BEGIN]
konversation: DccChat::listenForPartner(): using port 55578
konversation: DccChat::listenForPartner() [END]
konversation: DccChat::DccChat() [END]
konversation: PRIVMSG Sho_ :DCC CHAT chat 405154610 55578

Requested output.  This is what the buffer looks like before the offending function that crashes.

To provide some context, what he did was add "kdDebug() << buffer << endl;" to Server:queue and run in a terminal. Looks fine: DCC Chat object is instanciated, chat starts listening for the other side, queue gets the PRIVMSG to send to the chat partner. Boom in QStringList.

SVN commit 605705 by argonel:

prevent crash when initiating dcc chat when focus-new-tabs enabled.

BUG: 133312


 M  +3 -1      viewcontainer.cpp  


--- trunk/extragear/network/konversation/src/viewcontainer.cpp #605704:605705
@@ -2022,11 +2022,13 @@
     if (m_frontServer)
     {
         DccChat* dccChatPanel=new DccChat(m_tabWidget, myNick,nick,arguments,listen);
-        addView(dccChatPanel, dccChatPanel->getName());
         connect(dccChatPanel, SIGNAL(updateTabNotification(ChatWindow*,const Konversation::TabNotifyType&)), this, SLOT(setViewNotification(ChatWindow*,const Konversation::TabNotifyType&)));
         if(listen)
+	{
             m_frontServer->queue(QString("PRIVMSG %1 :\001DCC CHAT chat %2 %3\001")
               .arg(nick).arg(numericalIp).arg(dccChatPanel->getPort()));
+	}
+        addView(dccChatPanel, dccChatPanel->getName());
     }
 }
 

[x] KDE Version       1.0.1 (KDE 3.5.5, Debian Package 4:3.5.5a.dfsg.1-5 (4.0))
[x] Application       A user friendly IRC Client for the K Desktop Environment
[x] Operating System  Linux (i686) release 2.6.18-3-k7
[x] Compiler  Target: i486-linux-gnu

Problem's still alive in Konversation 1.0.1, cf. above.

We had a channel #c3s on OFTC.net. If one user uses c3s as a nick, he/she can kill any 1.0.* Konversation another user uses. We the one mentioned in comment #7 above and a  Konversation 1.0 Build 3170 (C) 2002-2006 by the Konversation team.

As user c3s, a simple "/ctcf nickname chat" didn't cause any crashes, but when using the nick name list side bar + second mouse button + "Open DCC chat" the wanted user's Konversation crashed, reproducable.

To confirm this, we tried another sample channel, #d3s, but there the case was not reproducable.

Additionally, on a Konversation 0.16 (Debian Sarge) didn't crash in neither case.

Just to confirm: The target user's client crashes, not the initiators? If so, this is not the same bug as the one which was fixed here. 

Got a backtrace?

(Notably, the fix for the first bug came in *after* Konversation 1.0.1 was released, so if the initiator crashes it's back to RESOLVED FIXED again.)

*** Bug has been marked as fixed ***.

still happening for me in 1.0.1

KDE Version	1.0.1 (KDE 3.5.8, Kubuntu (gutsy) 4:3.5.8-0ubuntu3.1)
Application	A user friendly IRC Client for the K Desktop Environment
Operating System	Linux (i686) release 2.6.22-14-386
Compiler	Target: i486-linux-gnu

apologies, looks like its fixed in the next release following 1.0.1! disregard