Hi Sven,
Yes I can try that this weekend sometime and will respond with results,.
Thanks for taking a look at that 😁
On Oct 14, 2016 3:41 PM, "Sven Barth" wrote:
> Am 14.10.2016 20:31 schrieb "Snorkl e" :
> >
> > Yep, I used heaptr, my code is clean.
> > Sometimes it would happen after 3 connect
Am 14.10.2016 20:31 schrieb "Snorkl e" :
>
> Yep, I used heaptr, my code is clean.
> Sometimes it would happen after 3 connects/disconnects and sometimes
after 500.
> With the GUID as the event name it has never happened again and I really
stress tested it.
>
> It sounds like windows bug to me, but
Yep, I used heaptr, my code is clean.
Sometimes it would happen after 3 connects/disconnects and sometimes after
500.
With the GUID as the event name it has never happened again and I really
stress tested it.
It sounds like windows bug to me, but who knows.
On Oct 14, 2016 1:23 PM, "José Mejuto"
Hi Sven,
Yes the events get destroyed in the threads destructor. I verified they
were being freed up.
It would usually happen when lots of connect disconnects happened in a
short time.
Once that error 161 popped it could not be recovered from, all new
connections would fail on the teventobject
El 14/10/2016 a las 20:11, Snorkl e escribió:
Since I solved it by giving the name param a giud, the next thing to ask
is why does teventobject fail kind of silently when the name parm is
blank over time?
Hello,
To me it looks like a memory corruption, in your program or in the
library. Have
Hi Tomas,
TEventobject.create is the only thing called in the thread constructor, and
teventobject.create is indeed calling a API function in order to create the
event. There is no other way to find out if teventobject.create failed as
teventobject.handle always has a value even if it fails.
So w
On Fri, October 14, 2016 17:44, Snorkl e wrote:
Hi,
> Hi, actually getlasterror only applies to the calling thread,
> getlastOSerror is the one not to use.
> Anyway I think I found the solution.
.
.
I'm glad that you found potential reason of the problem, but your
assumption regarding GetLast
Am 14.10.2016 17:45 schrieb "Snorkl e" :
>
> Hi, actually getlasterror only applies to the calling thread,
getlastOSerror is the one not to use.
GetLastOSError merely calls GetLastError on Windows...
> Anyway I think I found the solution.
> Just for kicks I put in a name with a / I.e /test_name a
Hi,
are there any known problems with gprof?
Mantis says no but when enabling gprof support in my Lazarus project I get a
segfault in gmon.c when running it.
Any compiler switches I should check for that may interfere or other hints?
R.
___
fpc-pascal
Hi, actually getlasterror only applies to the calling thread,
getlastOSerror is the one not to use.
Anyway I think I found the solution.
Just for kicks I put in a name with a / I.e /test_name and getlasterror
came back with the same error. So the API is being called somewhere with
teventobject.cre
On 14/10/16 02:43, Snorkl e wrote:
Anyway, I am using a third party SFTP server lib and it creates a thread
inherited from tthread and in the create event of the tthread descendant
it does this:
(It uses this thread to read and write data on the socket)
FDataAvailable := TEvent.Create(nil, True,
11 matches
Mail list logo
