adrian_007

btw it's not the reason of deadlock durnig checking, have you been running client detection on any hub?

in user.cpp also change FastCriticalSection Identity::cs to CriticalSection::Identity::cs

in user.h -> replace FastCriticalSection with CriticalSection. in user.cpp and user.h replace all FastLock with Lock recompile and try to reproduce... ;)

which revision of stlp have you used?

if someone also have this problem, can play with WinDbg (if this will work with debug mode)

you can get stlport svn snapshot, it works with recent version of visual studio. it would be nice, if you run it in debug mode. when app will freeze, pause process in debugger and copy assembly here...

rolex, can you reproduce it, but in one hub, just sending pm's?

tip: when you will be able to reproduce it, place breakpoints on each line to the place where nothing special happens when you're sending pm (in pm frame and in corresponding classes in dcpp lib as well) then watch on which breakpoint app will stop... this might give you a clue (i used to look for deadlocks in this way)

yep, but it isnt stored in frame, so imo it doesn't matter... btw if pointer would be bad, you would get access violation rather than freeze

i thought it might be too much critical section.... but now, client pointer is stored in chat ctrl :>

hmm this bug make us two crise, because i was looking for it for a long time ^^

probably because you've mixed allocators ;)

no, interfaces are good and clear imo. mainly i was talking about stlport because it's the biggest problem. and i've made a nice and clean solution for it a long time ago. since we can't use clear data types, like char, we need a 'stringholder' so we're creating a wrapper around it, to make char 'scoped' (like scoped_ptr for ex.). as you know, my api use lib with exported functions, i've exported whole class to it. now it takes around 9kB... comparing to heavy stlport it's way better solution. you might say that no. of allocations will increase, but bear in mind that string send to plugins sometimes are reallocated... also string class is muuuch more bigger class than my (rString). + one thing - we can use release plugin in debug core and debug plugin in release core versions. overall, in this solution we're only using 2 operators and 2 functions new, delete strlen, strcpy worked fine so far :huh:

probably one of the reason of it might be complicated create process (and additionally depending on stlport - exact svn revision used to build apex released exe)

atm rsx++ is in deadlock state and it's going to be for 30 min. - 1200 filelists in queue, but tomorrow i can even show you a snapshot with a configuration. i use one settings for all dc clients. bind addr. 192.168.2.101 ip: pub ip updated on startup (can say it's static because it havne't changed for almost 6 months) tcp: 2555 udp: 2555 tls: 2554 opened ports for dc 2550-2555 strongdc++ works fine rsx++ works fine dc++ works fine apexdc++ fails i dont even have installed hjt so no there is no log atm, but no need for it, my os is running for 3y w/o format, no viruses etc.

first report comes from vista my report comes from xp i have no problem with core - strongdc++ as well with my client - rsx++ - do you think it's a user error? ....

imo useless, you have a ... player to control a player... now it depends on scroll position.

i also have this problem, even with previous releases. i have manually forwarded ports. this issue is only with apex afaik. (i'm running xp sp2)

well, yes, tr1 in microsoft edition really sux. comparing to latest svn revision: exe size: +/- 400KB bigger mem use: +/- 2MB at startup. checked with strongdc 2.13 but still, now stlport is an option, recommended but option =)

some clever ppl will instal feature pack for vs 2008 and then stlport isnt obligatory :mellow:

yes, basically, and i don't see equivalent for it in spec so far (checked some time ago so i might be wrong). and imo it can be done in access.lua update.

i think it may happen on certain configuration in special cases. (just like combination with nod32 make some problems) with apex i was able to reproduce it once, with sdc (checking many revision) 3 to 5 times. but i didn't know where it exacly occur and when.

my client also suffered because of freezes... now testing latest revision and all is running ok... so he should check it after next release...

adc have missed refresh userlist function.

imo next release, based on new sdc should solve the problem.