In the last time I had two disconnects from LFS and got the error message: Avoiding buffer crash (OK)

I never had this kind of disconnect before and the only thing that had changed was, that I have extended the LFS-Dedi with an InSim application that displays the recent laps to the current driver.
I use buttons to display the information and I have the suspicion that this extension is the cause for the disconnection. So is it possible that I have a bug in my program, so that some wrong data is send to the client, that causes the crash?

Here is a screenshot of an early version of the extension:


If someone wants to see this live, just join one of my servers ( \\\liveforspeed.at or \\\f1challenge ) and enter the chat message '/i board'. (Currently a restart of the race is needed to see the times)

ive acutally seen a problem like this, if you send to many buttons to LFS in the wrong way, like spam them it doesnt like it. Saying that you could have easly made a typo in the code, try removing all the code for the buttons, then leave it running and if it still gets a error, its most probley something else

Too many? 239 buttons ids can be used, so I assume I can use 239 buttons. I display not more then 30 buttons at one time.

What du you mean with the wrong way?

What I do is that if a button is shown and I want to change the text, then I send IS_BTN with the same values but the new text. I do not send a prior clear.

If the buttons are not shown I never had this kind of disconnect. This disconnect only happend to me twice, and I have done lots for laps with the buttons activated.

Basucally what i mean is if you send the same button to LFS loads of times it wont like it. Your right yes LFS can take 239+ buttons but if you send the same 1 in a spamming way LFS will just say "no sorry dont like spam" then more then likey show the error your getting. All im saying is basically try not to send the same button so many times and see if it helps, but ill give you an example. if you make a program with a while loop and say for example where the condition will always go into the loop known as a infinity loop, then put code inside the loop to send a button to LFS, LFS wont stand for it and it will just kick the insim out because your doing something wrong. So im not saying that your sending to many buttons as in number of buttons you see on screen but you could be sending the same but too many times or updating it too many times(hence the error)

You don't clear/delete the old buttons? That is the first thing I would check. I know you specify the same button/click ID but it may be possible that, if the width/height are not zero, the new button is either dropped or appended to LFS's button buffer, causing that buffer crash. InSim.txt says if you want to update an existing button, to make sure width or height is zero.

I have now changed the width and height so that 0 is send, but a colleague yesterday had this kind of disconnect.

I will try to write a program that displays and hides lots of buttons, so that I can reproduce this, because it only happens very rarely.

Today I wrote a test program that displays 100 buttons and every second the text of 10 buttons was updated. I did only take one second until I lost the connection to the server.
I found in the log the following error messages:
TCP ERROR : WOULDBLOCK
TCP : Cleared emergency store
FATAL TCP ERROR : CONNRESET

I search the forum and found this thread:
http://www.lfsforum.net/showthread.php?p=465707

This gave me the hint that this could be a linux/wine issue, because my host also runs unter linux.
So I tried my test program on another dedi server that runs on windows and it worked. No disconnect after several minutes.

I will try to google a bit, maybe it is possible to tweak wine, or try a newer wine version, but I think this is unfixable as long there is no native lfs linux dedi

I did some additional testing.
One thing that I had wrong in my program was that I always send the maximum packet size of the IS_BTN request with 252 bytes. But this is not really a bug, its only a waste of bandwidth.
Now I have changed this to a dynamic size depending on the text length.
With this now, It looks like that it works now, because my 100 buttons test program works fine on my linux/wine LFS dedi.

My opinion now is that if the LFS dedi has to send lots of InSim requests to the client, that this can cause a disconnect.

I'd agree with your opinion, I had the same thing when the CTRA re-launched, before they got the ability to hide results.