[[1.1.0] Random freeze when pressing Enter for private frame]

btw it's not the reason of deadlock

durnig checking, have you been running client detection on any hub?

[[1.1.0] Random freeze when pressing Enter for private frame]

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

[[1.1.0] Random freeze when pressing Enter for private frame]

in user.h -> replace FastCriticalSection with CriticalSection.

in user.cpp and user.h replace all FastLock with Lock

recompile and try to reproduce... ;)

[[1.1.0] Random freeze when pressing Enter for private frame]

which revision of stlp have you used?

[[1.1.0] Random freeze when pressing Enter for private frame]

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

[[1.1.0] Random freeze when pressing Enter for private frame]

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...

[[1.1.0] Random freeze when pressing Enter for private frame]

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

[[1.1.0] Random freeze when pressing Enter for private frame]

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)

[[1.1.0] Random freeze when pressing Enter for private frame]

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

[[1.1.0] Random freeze when pressing Enter for private frame]

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

[[1.1.0] Random freeze when pressing Enter for private frame]

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

[Released: ApexDC++ 1.1.0]

probably because you've mixed allocators ;)

[Released: ApexDC++ 1.1.0]

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:

[Released: ApexDC++ 1.1.0]

no one seems to bother with plugins

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)

[TCP/TLS Port]

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.

[TCP/TLS Port]

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? ....

[Released: ApexDC++ 1.1.0]

Media Toolbar

imo useless, you have a ... player to control a player...

Autoscroll chat

now it depends on scroll position.

[TCP/TLS Port]

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)

[Compiling ApexDC++]

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 =)

[Compiling ApexDC++]

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

[[1.0.1] Userlist]

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.

[Apex freezing very often]

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.

[Apex freezing very often]

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

[[1.0.1] Userlist]

adc have missed refresh userlist function.

[Apex freezing very often]

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