lazarus Sockets - sigabrt
lazarus / 38-Networking and Web Programming

----------------------------------------------------------------------
richard_rtech · 2015-03-24 10:10

Hi Guys

Laz 1.2.6/Pi B+ or Deb Wheezy /LazSockets

I'm still chasing this down. I have some code ported over from
Delphi/twsocket to Lazarus/tsocket client thats being a bit odd. Just
thought I'd post in the hope someone may have some more suggestions or
the author is about.

First non-issue. If a connection goes down and I reconnect just
ocasionally, it'll alow one char to be sent than drops the connection
again. I can solve this by totally tearing the component down and
recreating it. Its a pain but no biggie. I've had a quick look and its
getting an error somewhere and just closing but theres no feedback
about why this is happening. I may well do some pokig to add an
OnError event.

Now the real pain.

I'm receiving binary encrypted data, I sent an STX, two bytes packet
length, a encrypted stream of text and then a checksum. Its all looked
after by a state machine. Feeding this state machine with data from a
file including garbage and it works as expected so I'm sure itss
something daft.

The onreceive even grabs the data and serialises it if needed with a
for-to and spits it off to the state machine. The state machine has
timeouts so it cant get stuck.

*something* and I have no idea what, throws an access violation
seemingly at random. I get SIGSEGV then access violation then it
normally chunters off happy again. No try/except blocks I've thrown in
are tripping, no clues get given and sometimes it'll happen at the
protocol running over it handling it, sometimes 15 mins later after
unpteen rekey attempts. Whats annoying is I know Delphi would be a
little more helpful than just going BLAM and dying.

My thought is something is going boom along the processing and thats
not raising the exception and its getting deferred somehow.

Has anyone else used this component and had any issues?

----------------------------------------------------------------------
richard_rtech · 2015-03-24 10:17

Its definiately something in the receive chain, just going to kill the
encryption code off to rul that out but I've uced DCPCrypt for years
in similar systems so not expecting that to help.

Probobly little help but the Assembler line that seems to throw it is
ldr r0, [r0]

Think I've got it, god knows how but all the timeout logic is missing
It looks like somthing is dropping a char, this leaves it a char
behind, waiting for a checksum byte its already received and appended
to the data. As its not timing out its in an invalid state when the
next packet arrives. So I need to know where char dropping is going on
and fix that too.

Not sure where 30 odd lines of code have just vanished off to mind

Nope that wasnt it

If I make the first ling of the on readchar event an exit its fine.
Even a tmemo.lines.add() in there and it starts flaking out. If I grab
the data out into a string its fine but the moment I try to do
anything else it it gets flakey again.

so:

socketclient1.readline(work);
exit;

is ok.

socketclient1.readline(work);
memo1.lines.add('foo!');
exit;

starts flaking out randomly.

More I look the more I'm now convinced its the component. At a guess
its getting hung up while I do my processing and the next char
arriving causes the issue. I think I need to implement some sort of
FIFO, post the char and exit the even then find a way to process the
fifo.

That or write my own wrapper round fp_socket

----------------------------------------------------------------------
richard_rtech · 2015-03-24 16:42

Been pulling sockets_laz apart. Sorry this thread is turning into a
brain dump as I try and understand this.

When GetBuffer is caled a semaphore is set to true.
When the receive thread is fired it runs _addChar, the first lines in
_addchar are:

While semaphore do
  begin
  end;

As I've called getbuffer, assuming I'm still processing data the next
char will get stuck in that While-Do. Assumingly the next received
char has nowhere to go when the thread fires and it'll hang
up/deadlock and then cause issues with the thread loop hanging up.
While the thread is hung data is still coming into the socket and I
guess eventaully something will give.

Assuming I'm right implementing a fifo should stop this silliness.
Another thread to poll the fifo and trip events as and when needed or
am I overcomplicating this?

I think the issue is the way I'm using this. I could see using whole
blocks of data rather than single chars would stop this behaviour
however I need to pass binary data and doing this via text would be
more difficult in this application.

Any ideas?

----------------------------------------------------------------------
richard_rtech · 2015-03-26 12:26

Whole new component written in the end. Found the same issues with my
inital ver as in the component which was this

 Code: [Select]c being a char and ret being an int and S the socket
handle

ret := fprecv(s,@c,1,);

I used more or less the same. I did a lot of tidying up, the code in
laz_sockets isnt really thread safe and allowed for data corruption if
used in just the wrong way. Lots of extra error checking BUT it would
still randombly SIGABRT.

Looking deeper I managed to create the error on demand and it seems to
be a buffer overrun issue with fpread. Because the author, and myself,
were reading chars and then processing each char it all becomes very
time sensitive and it doesnt take much for something to plough into
the end of the buffer and blow it all up.

This isnt how I do things in Delphi or anywhere else, I always grab
the entire buffer not a bit at a time. Given I only have his reference
code to go by as fpsocket is poorly documented I had just assumed this
was the only way. After digging it turns out I can ask for chunks of
buffer up to size of 'n'. Some rework to grab the entire buffer and
then poke it into my fifo on one big hunk solved the issues. Quite why
the author went the byte at a time route I dont know.

In the last 48 hours I've learnt a lot about threads, thread
synchronisation and FPSockets though