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,
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
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
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
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
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
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 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
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"
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
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
11 matches
Mail list logo
