icqlib-dev

[icqlib-dev] BSD Fix, and question about two callbacks

[Eric W. <war...@ya...>]

Hi,

In order to compile the icqlib that's currently in CVS on FreeBSD 4.2, I
had to add

#include <sys/types.h>

before the sys/socket.h include in icqpacket.c and socketmanager.h.

Also, I had a question about the InvalidUIN and WrongPassword callbacks.
In udphandle.c, the both have invoke_callback followed by

icq_UDPAck(icqlink, seq);

In kicq though, both callbacks lead to the icqlink being deleted
(both callbacks call RegWindow::stop, which calls RegWindow::disconnect,
which calls icq_ICQLINKDelete).

Once the icqlink is deleted, it returns to icq_ServerResponse in udphandle.c,
which immediately tries to use it.

Shouldn't the calls be reversed? The icq_UDPAck first and then
invoke_callback?

Eric

Re: [icqlib-dev] BSD Fix, and question about two callbacks

[Denis V. D. <de...@nu...>]

Eric Warmenhoven <war...@ya...> writes:

> Hi,
> 
> In order to compile the icqlib that's currently in CVS on FreeBSD 4.2, I
> had to add
> 
> #include <sys/types.h>
> 
> before the sys/socket.h include in icqpacket.c and socketmanager.h.

Thanks for this, fixed.

> Also, I had a question about the InvalidUIN and WrongPassword callbacks.
> In udphandle.c, the both have invoke_callback followed by
> 
> icq_UDPAck(icqlink, seq);
> 
> In kicq though, both callbacks lead to the icqlink being deleted
> (both callbacks call RegWindow::stop, which calls RegWindow::disconnect,
> which calls icq_ICQLINKDelete).
> 
> Once the icqlink is deleted, it returns to icq_ServerResponse in udphandle.c,
> which immediately tries to use it.
> 
> Shouldn't the calls be reversed? The icq_UDPAck first and then
> invoke_callback?

Hmm, it is more than just 2 callbacks. Most of the time we send
acknowledgement packet after calling callback. Which I think could cause
problems if client try to disconnect/delete icq_Link inside the
callback, and which is causing them in kicq's RegWindow right now. Probably
calling callbacks after acknowledging the packet would solve this kind of
problems in general and RegWindow crash in particular.

-- 
Denis V. Dmitrienko | E-mail: de...@de... | ICQ#: 5538614
Home page: http://denix.org | de...@kd...
History became legend... Legend became myth.
And some things that should not have been forgotten ...were lost.

Re: [icqlib-dev] BSD Fix, and question about two callbacks

[Michael M. <mic...@in...>]

On Thursday, 31. May 2001 02:15, Denis V. Dmitrienko wrote:
[...]
>
> > Also, I had a question about the InvalidUIN and WrongPassword
> > callbacks. In udphandle.c, the both have invoke_callback followed by
> >
> > icq_UDPAck(icqlink, seq);
> >
> > In kicq though, both callbacks lead to the icqlink being deleted
> > (both callbacks call RegWindow::stop, which calls
> > RegWindow::disconnect, which calls icq_ICQLINKDelete).
> >
> > Once the icqlink is deleted, it returns to icq_ServerResponse in
> > udphandle.c, which immediately tries to use it.
> >
> > Shouldn't the calls be reversed? The icq_UDPAck first and then
> > invoke_callback?
>
> Hmm, it is more than just 2 callbacks. Most of the time we send
> acknowledgement packet after calling callback. Which I think could cause
> problems if client try to disconnect/delete icq_Link inside the
> callback, and which is causing them in kicq's RegWindow right now.
> Probably calling callbacks after acknowledging the packet would solve
> this kind of problems in general and RegWindow crash in particular.

I agree with you, that acknowledging the packet before calling callbacks 
should be more save. But I encountered another problem with the same 
result (RegWindow crash): When registering a new UIN with correct password 
the icqlib tried to delete some tcp stuff, although it was not in use and 
therefore not allocated. In my situation testing for icq_UseTCP before 
calling icq_TCPDone helped. Perhaps this will fix Eric Warmenhoven's 
problem as well. I submitted a patch on 
http://sourceforge.net/projects/icqlib

-- 
Michael Moeller      Universitaet Oldenburg, Fachbereich Informatik, 
                     Postfach 25 03, 26111 Oldenburg 
                     Tel.:0441 798-3483              Raum: A3 2-218
        mailto:Mic...@in...