[issue26278] BaseTransport.close() does not trigger connection_lost()

2019-11-19 Thread Sümer Cip

Sümer Cip  added the comment:

Closing the issue seems like a good idea: as it seems nobody seems to have 
spotted similar issue and I have only been able to reproduce it in Python 3.4. 

Just for future ref.: The uncommon thing is that the server I was using is a 
TCP game server holding long-running connections as opposed to short-lived HTTP 
connections, maybe there is a very random issue at the core but as it is 
happening very randomly.

--

___
Python tracker 
<https://bugs.python.org/issue26278>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38522] Py_USING_MEMORY_DEBUGGER is referenced in docs but not present in code

2019-10-18 Thread Sümer Cip

Change by Sümer Cip :


--
versions: +Python 2.7, Python 3.5

___
Python tracker 
<https://bugs.python.org/issue38522>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38522] Py_USING_MEMORY_DEBUGGER is referenced in docs but not present in code

2019-10-18 Thread Sümer Cip

New submission from Sümer Cip :

Hi all,

While trying to debug Python C extension via valgrind, I was reading the 
document Misc/README.valgrind and it seems there are some parts not being 
uptodate. There is comments comments like following:

Uncomment Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c, then rebuild Python. 
This define seems to be removed from the obmalloc.c file and also I am not sure 
if anything is using it at all. When I searched the code, only Python/dtoa.c 
have a reference to this define. Anyway, I have not specifically investigated 
the reason behind of the removal of the define but it seems it is removed 
somewhere between 3.3 and 3.4. I am assuming it might be related with 
tracemalloc maybe? 

Cheers,

--
components: Build
messages: 354922
nosy: Sümer.Cip
priority: normal
severity: normal
status: open
title: Py_USING_MEMORY_DEBUGGER is referenced in docs but not present in code
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue38522>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26278] BaseTransport.close() does not trigger connection_lost()

2019-05-07 Thread Sümer Cip

Sümer Cip  added the comment:

I do not know I still have the issue since I have circumvented the problem. I 
have been using Python3.4, I think it was one of the earliest asyncio 
implementations. The way it can be reproduced is as following: 
1) There are lots of active TCP connections connected to asyncio server 
(300-400 of them)
2) One of the clients close connection ungracefully(without sending a FIN)
3) We have a PING/PONG mechanism in the server (similar to http keep-alive), we 
call transport.close() on the socket if pong is not received within an interval.
connection_lost() event is never gets called for the socket. This is not 
happening all the time, this is a random issue, the key here is to disconnect 
client without sending a FIN and there is outgoing buffer for client.

Above is all I got.

Thanks!

--

___
Python tracker 
<https://bugs.python.org/issue26278>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26278] BaseTransport.close() does not trigger connection_lost()

2016-02-03 Thread Sümer Cip

New submission from Sümer Cip:

Hi all,

We have implemented a TCP server based on asyncio. And while doing some 
regression tests we randomly see following error:

1) Client connects to the server.
2) Client is closed ungracefully(without sending a FIN, deplug cable)
3) We have a custom PING handler that sends a PING and waits for PONG message.
4) After a while, we see that we timeout for the PING and we call close() on 
the Transport object. 

Now, most of the time, above just works fine, but at some point, somehow 
connection_lost() is NEVER gets called even though we call close() on the 
socket. As this issue is happening very randomly I don't have any asyncio logs 
for it. But can you think about any scenario that might lead to this somehow? 

Somehow, it seems we have an outgoing data in the TCP buffer when this happens 
and that is why the close() does not call the connection_lost immediately, but 
why it is never calling it is a mystery to me. Can that be following:

1) we call close() and is_closing is set to true we have outgoing data so we 
return.
2) Then a subsequent write occurs and connection ConnectionResetError() is 
raised and this calls _force_close(), but as we have previously set is_closing 
to True, connection_lost() does not get called.

Above is just a very trivial idea which is probably is not the case, I do not 
spend too much time on the code. 

Thanks,

--
components: asyncio
messages: 259487
nosy: Sümer.Cip, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: BaseTransport.close() does not trigger connection_lost()
type: behavior
versions: Python 3.4

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26278>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com