| Issue 180: | transport crashes: can't start new thread | |
| 3 people starred this issue and may be notified of changes. | Back to list |
What steps will reproduce the problem? 1. After a while of using the transport. It's not clear why. 2. 3. What is the expected output? What do you see instead? Message send to my client from the transport: "Undefined condition. The error condition is not one of those defined by the other conditions in this list. ------ ICQ connection lost! Reason: [Failure instance: Traceback (failure with no frames): <class 'thread.error'>: can't start new thread ]" What version of the product are you using? On what operating system? pyicqt 0.8.1.3, Debian 5.0, Python 2.5.2, Twisted 8.1.0, ejabberd 2.0.3 Please provide any additional information below. After a while I had used the transport, it crashes with the error-message I've written above. After the error occurs, the transport is still running, but he will not accept any new connections. Only restarting the transport is not enough. To get the transport working, I had to reboot the whole OS.
Aug 7, 2009
Project Member
#1
r000ns...@gmail.com
Aug 16, 2009
This happens to me too since Gentoo upgrade to python-2.6, rolling back Python to 2.5 lowers memory&thread usage from 1300Mb+ to 900Mb (20 connected users, still too much - but it runs without warnings and errors).
Aug 16, 2009
Sorry for comment spam, just noticed after a while (minutes, not seconds) it gets down to about 100Mb with python 2.5, memory&thread-usage perhaps startup-related?
Aug 16, 2009
With 2 users it eats 340 Mb of virtual memory and 340 Mb in peak. :) You got maximum when restarted transport I think and all users were connecting to it simultaneously. Or 900 Mb in resident memory?
Aug 16, 2009
Now it's here early morning, much less users connected - tried pyicq-t with python-2.6 on gentoo again, result with 9 connected users: Memory usage during start 450Mb, 2 minutes later 116Mb, 9 threads. With python-2.5 it uses a bit less memory, about 100Mb. Yes, you're right, waiting some time reduces the memory usage to normal levels, and if there are not too much users connecting at the same time (during startup) starting the transport works without problems. Small workaround: I removed/commented out <enableAutoInvite/> from my config file, now it starts perfectly :) (but all users have to reconnect themselfes)
Aug 24, 2009
Try 0.8.1.5 version
Aug 24, 2009
the new version feels better :) Tested with 15 users connected and <enableAutoInvite/> activated, i get this results: 0.8.1.4 highest memory usage during startup: 880 Mb, reduces to 190 Mb 0.8.1.5 highest memory usage during startup: 781 Mb, reduces to 125 Mb |