STINNER Victor added the comment:
I'm sorry, but even if it's a real bug, we don't have enough information nor
any scenario to reproduce the bug, so it's not possible to investigate the bug.
I close the issue.
--
resolution: - out of date
status: open - closed
STINNER Victor added the comment:
Did you see some errors or warnings when running your application with
asyncio in debug mode?
No, but I'll try. I doubt the problem is in asyncio itself because it's
mostly written in Python. This looks like a garbage collection issue.
Sorry, you're
STINNER Victor added the comment:
Bugfixes of asyncio 3.4.3, a lot of them are related to the proactor event loop
(and most of them leaded to crashes):
https://code.google.com/p/tulip/source/browse/ChangeLog#66
--
___
Python tracker
STINNER Victor added the comment:
(Since you chose to comment this closed issue instead of opening a new one, I
reopen this issue.)
--
resolution: not a bug -
status: closed - open
___
Python tracker rep...@bugs.python.org
Michael Goldish added the comment:
OK, I caught the crash with a debug build of Python 3.4.3.
I have a core dump and even the process itself still alive in memory. I can
provide any information you need. I can also explain how to debug a core dump
with Visual Studio, if necessary.
This time
Michael Goldish added the comment:
Sorry, you're wrong: the proactor event loop heavily uses the _overlapped
module which is implemented in C. A crash in the garbage collector is more
likely a bug in asyncio/your application, than a bug in Python itself.
I'm aware of that. I assumed the
STINNER Victor added the comment:
It looks like you are running your app on Windows. Are you using the
proactor event loop? I guess yes since you have more than 1000 clients and
select() is limited to 500 sockets.
In Python 3.4.3, I fixed a *lot* of crashes and race conditions in the
proactor
Michael Goldish added the comment:
That's nearly 4 GB. I somehow doubt your app is actually trying to allocate
that much memory
There's no reason for the app to allocate that much memory in a single call.
It's using almost 4 GB of memory in total today, but that makes sense given its
load
Michael Goldish added the comment:
It looks like you are running your app on Windows. Are you using the proactor
event loop?
Yes.
In Python 3.4.3, I fixed a *lot* of crashes and race conditions in the
proactor event loop. There are maybe more race conditions.
I've already tried Python
Michael Goldish added the comment:
I caught another crash just now, this time in update_refs(). A stack trace is
attached below. I still think this is the same issue.
static void
update_refs(PyGC_Head *containers)
{
PyGC_Head *gc = containers-gc.gc_next;
67382D60 mov
Guido van Rossum added the comment:
So what do you make of this?
PyObject_GC_Malloc(unsigned __int64 basicsize=4046951880)
That's nearly 4 GB. I somehow doubt your app is actually trying to allocate
that much memory -- maybe the type object a few lines below in the stack is
overwritten, or
Michael Goldish added the comment:
I don't see a reason to assume the machine was running out of memory. After
each crash the process was kept alive by one of those Windows crash dialogs -
the process terminated unexpectedly or similar. I could see exactly how much
memory was occupied by the
Michael Goldish added the comment:
Why do you consider that it's the same issue?
Because it's a very similar stack trace, the crash itself is in
subtype_dealloc(), it happens once every few days, asyncio is involved, and the
issue is relatively new - I couldn't find another bug report with a
Guido van Rossum added the comment:
Are we all in agreement that it's probably somehow running out of memory?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23187
___
STINNER Victor added the comment:
I'm not sure where to post this as the issue is closed:
Please open a new issue.
I've encountered the same problem.
Why do you consider that it's the same issue?
The crash seems to occur at random, with anything between 1 and 20 days
separating
Michael Goldish added the comment:
I'm not sure where to post this as the issue is closed:
I've encountered the same problem. I don't have a stack trace to share at the
moment but I know it's almost (or entirely) identical.
My context:
- Windows
- Happens with Python 3.4.2 and 3.4.3 (and
STINNER Victor added the comment:
Since the issue looks to be related to a third party module (ujson), I close
this issue.
Note: On UNIX, asyncio is fully implemented in Python, I don't see how it could
corrupt internal Python structures.
--
resolution: - not a bug
status: open -
STINNER Victor added the comment:
@Ivailo: Any progress on your investigation?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23187
___
___
Ivailo Karamanolev added the comment:
@Victor It has been running for 5 days now on 3.4.2 using json instead of
ujson. I want to give at least 10 days to crash and if it's still up, I plan to
switch to simplejson to see how that will go, since json is quite slow. I'll
keep playing with using
Changes by Rickard Englund gefle.rick...@gmail.com:
--
nosy: +r-englund
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23187
___
___
New submission from Ivailo Karamanolev:
I have a program that's running Tornado on top of asyncio and uses
mysql-connector-python to monitor a set of HTTP servers and save the status to
MySQL. Initially I ran it with the current version of Python in the Ubuntu
14.04 repos, that's 3.4.0 and
Guido van Rossum added the comment:
That's going to be really hard to debug. Is it always the same stack trace?
Could it be slowly running out of memory? (The consistent time until it happens
points to this.) A segfault in dealloc might point to a refcounting bug. The
rarity of the even might
Ivailo Karamanolev added the comment:
Running out of memory is unlikely. There are many other processes running on
the machine and none of them show signs of memory issues. In addition, the
munin memory usage reporting doesn't show signs of steady growing or drops when
the process crashes
Ivailo Karamanolev added the comment:
What I forgot to mention is that I'm using aiohttp for making lots of HTTP
requests. http://bugs.python.org/issue21435 mentions asyncio and aiohttp and is
somewhat memory management related so I thought I'm hitting a different
manifestation of it and
STINNER Victor added the comment:
that's 3.4.0
I suggest you to upgrade to Python 3.4.2. Your issue may already be fixed. For
example, there was the issue #21435 in the garbage collector. The issue was
found with an asyncio code.
Your crash occurs at _PyObject_GC_UNTRACK(self); which is
Ivailo Karamanolev added the comment:
@haypo
Maybe I didn't put it prominently enough, but I upgraded to 3.4.2 by
downloading the source and installing it. The same crash with the same stack
trace happens.
--
___
Python tracker
STINNER Victor added the comment:
upgrading to 3.4.2 would fix it, but it didn't
Oh sorry, I missed the part where you wrote that you already tested Python
3.4.2.
By the way, if you already compile your own Python: try to configure Python
with ./configure --with-pydebug. It adds much more
Ivailo Karamanolev added the comment:
try to configure Python with ./configure --with-pydebug
I'm installing 3.4.2 with this option right now and I'll reboot and run the
script with gdb attached. I might be a few days before I have a result.
Are you using other external modules which are
STINNER Victor added the comment:
The only module that I'm using that's implemented in C is ujson
https://pypi.python.org/pypi/ujson . If you think this is relevant, I can
easily try changing it to use the built-in json.
To investigate an issue, we have to reduce the scope. If your program
29 matches
Mail list logo
