For the 2nd one it seems like referencing already deleted socket for me.
I don't see any direct problem in the code, but after some analysis two
things come to my mind:
1) for NAT sockets, they are attached to associated endpoints.
What happens, if there is an error during reading the socket (TCP
connection reset or similar).
From the code I see OnError and Close is called, but none of these
functions detach the socket from its endpoint.
2) in the CallSignalSocket::OnInformation function, if there happens
that an endpoint has already another NAT socket attached:
if (natsocket != NULL && natsocket != this)
we call natsocket->SetDeletable() and natsocket->Close() for a socket
that can be owned by another proxy handler. This may cause a rare race
condition,
although this is probably not the case with the reported core dump.
I guess a similar issue is with EndpointRec::SetSocket.
----- Original Message -----
From: "Jan Willamowius" <jan@xxxxxxxxxxxxxx>
Sent: Wednesday, May 14, 2008 11:03 PM
> Hi Grzegorz,
>
> great bug reports, again. Thanks!
>
> As you say, the first one is easy and I've fixed it for 2.2.8 and
> 2.2.7_STABLE. I'm not sure abut the 2nd one.
>
> Regards,
> Jan
>
> Grzegorz Stanislawski wrote:
>> Hi
>> Here comes another two:
>> This one is easy, check if m_call=NUL and return than (maybe with some
>> warning about alerting msg for deleted call), in ProxyChannel.cxx line
>> 2307
>> #0 CallRec::SetAlertingTime (this=0x0, tm=1210724824)
>> at /usr/local/src/h323plus/../pwlib/include/ptlib/psync.h:133
>> #1 0x0811b27a in CallSignalSocket::OnAlerting (this=0x85f7788,
>> msg=0x41a809c8)
>> at ProxyChannel.cxx:2307
>> #2 0x081288bf in CallSignalSocket::ReceiveData (this=0x85f7788)
>> at ProxyChannel.cxx:965
>> #3 0x0810b9ee in ProxyHandler::ReadSocket (this=0x81c2978,
>> socket=0x85f7788)
>> at ProxyChannel.cxx:5031
>> [..]
>> Second one:
>> #0 0x080a8801 in EndpointRec::SetSocket (this=0x41cb14e0,
>> socket=0x434a1a68)
>> at /usr/local/src/h323plus/../pwlib/include/ptlib/pstring.h:1945
>> 1945 string.PrintOn(stream);
>> (gdb) bt
>> #0 0x080a8801 in EndpointRec::SetSocket (this=0x41cb14e0,
>> socket=0x434a1a68)
>> at /usr/local/src/h323plus/../pwlib/include/ptlib/pstring.h:1945
>> #1 0x08110e77 in CallSignalSocket::OnInformation (this=0x434a1a68,
>> msg=0x429b3300) at ProxyChannel.cxx:2391
>> #2 0x08128713 in CallSignalSocket::ReceiveData (this=0x434a1a68)
>> at ProxyChannel.cxx:977
>> #3 0x0810b9ee in ProxyHandler::ReadSocket (this=0x81cf340,
>> socket=0x434a1a68)
>> at ProxyChannel.cxx:5031
>> [..]
>> that inline PrintOn introduces a little mess in gdb, but i took a look
>> into EndpointRec::SetSocket
>> trace was set to 2 so problem is in line 504 of RasTtbl.cxx
>> (gdb) p m_natsocket->m_name
>> $7 = {<PCharArray> = {<PBaseArray<char>> = {<PAbstractArray> =
>> {<PContainer> = {<PObject> = {_vptr.PObject = 0x42900248}, reference =
>> 0x65766965},
>> elementSize = 2065709668,
>> theArray = 0x7120200a <Address 0x7120200a out of bounds>,
>> allocatedDynamically = 1882272569}, <No data fields>}, <No data
>> fields>}, <No data fields>}
>>
>> Grzegorz Stanislawski
>
> --
> Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________________
Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/
