[Vm-dev] Difficult to debug VM crash with full blocks and Sista V1

[Ben Coman]

On Wed, 25 Sep 2019 at 15:32, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
> I noticed that many crash happen in testSendTimeout.
> This test is organizing a race:
> - Smalltalk fill the socket send buffer
> - the OS tries to drain
>
> The other thing I noticed is that [SocketTest suite run] takes 7 to 8s on
> macos while only 2 to 3s on ubuntu and windows
> So it might be that some test times out on macos, while it doesn't on
> other OS.
>
> This would explain that many crash also happen in JITted Timer loop, and
> that we cannot observe it in other OSes.
>
> The access to OS ressources and the race may also explain some
> randomization of the crash...
>
> So one idea would be to make the test timeout in linux too, see if we can
> make it crash then try using rr.
> Maybe it's possible with a huge Socket buffer, a smaller image side buffer
> (we could reduce the size from 1000 to 1 so as to increase overhead).
>

How that might be done spiked my interest, so I had a poke around...
*
https://serverfault.com/questions/799605/set-large-buffer-queue-on-a-network-interface-to-emulate-bufferbloat
*
https://coderwall.com/p/wuwoja/simulate-network-latency-to-debug-connection-timeouts
*
https://stackoverflow.com/questions/614795/simulate-delayed-and-dropped-packets-on-linux

But those might not directly affect the send buffer, so maybe an
alternative...
* https://utcc.utoronto.ca/~cks/space/blog/linux/TCPSendbufferDefaultSize
*
https://stackoverflow.com/questions/47350028/how-to-tune-linux-network-buffer-size
* https://www.cyberciti.biz/faq/linux-tcp-tuning/

cheers -ben

P.S. Probably not specifically useful, but Oh Wow! just-too-impressive and
more-than-you-could-possible-want-to-know about Linux networking...
https://blog.packagecloud.io/eng/2017/02/06/monitoring-tuning-linux-networking-stack-sending-data
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190925/0c110442/attachment.html>