linuxdcpp-team team mailing list archive

[Pirre <644109@xxxxxxxxxxxxxxxxxx>]

It acts a bit different but error is still there ....

Rev400 in ADCS mode runing on OS XP and W2k


Running PURE core in ADCS mode (bloom and all lua's including access.lua disabled)

Handles use act more or less normal hub starts with 114 handles without
users after 4 users it go's to 192

But on every socket deleted there are handles traped either if its an error like these below or a simple reconnect with a 
client and those are never freed anymore.

ManagedSocket deleted
4IDR failed: 336130315 asio.ssl error
Removing 4IDR
ManagedSocket deleted
2EJT failed: 10054 An existing connection was forcibly closed by the remote host
Removing 2EJT
ManagedSocket deleted
OCNA connected
OCNA entering IDENTIFY
OCNA verifying ip
OCNA disconnecting because 6
OCNA failed: 9938 Unknown error

So after running 1 hour with 4 normal users and me reconnecting it reached 1000+ handles, to compare ,my real hub with all 
scripts enabled running a version based on Rev 379 with Poy's timerfix 389 merged uses after 1 week with 20 to 50 users uses 
260 handles and those go up and down in a logical way with the number of users.


Running in ADCS mode (bloom enabled)

All logic seems gone it's handles use rockets to 40.000+


Running in ADCS mode (only access.lua enabled bloom disabled)

Acts like running pure core except it uses more handles for a realy
connect user ... who are also not freed on a disconnect.


Enabling more lua scripts just increases the number of trapped handles,
so thats my 2 cent lol


I can't run this exact same test for Non Secure mode as i have no outside clients for that but as far i can duplicate it 
seems that the exesive handle use is now acting the same in adc and adcs mode ...

BRGDS and thx for making this work :)

-- 
Rev 387 threads consuming (mingw non official)
https://bugs.launchpad.net/bugs/644109
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to ADCH++.

Status in ADCH++: Confirmed

Bug description:
Somehow this version seems to consume threads in such a way that other applications are unable to create new ones.

This was done on a Win2k server but seems the same on a XP system (both fully updated).

When this happens the cpu use go's to 100% and the dcpph application starts erroring when it needs to preform a new action like a IO to disk etc probebly because it can't create a new thread itself.

Applications running on the same machine like Strgdc are reporting that they are unable to create a new one :)