On Sat, Sep 23, 2023 at 08:16:42PM +0200, Christian Weisgerber via curl-library
wrote:
> So in the end this regress test is built on assumptions and is
> therefor non-portable and prone to fail.
That basically verifies my guess as to what was happening. Thanks for following
up on this.
Dan
-
Dan Fandrich:
> After much pain I was finally able to install OpenBSD under KVM and reproduce
> this problem. I verified that curl was correctly sending the first 65536 bytes
> of data to the socket in a call to send(2), but the OS reports that only 32716
> bytes were actually sent. The test assum
On Tue, Sep 19, 2023 at 01:47:45PM +0200, Daniel Stenberg wrote:
> Maybe we should consider adding a way to
> disable/enable tests based on the OS name where it runs?
There's already the "win32" feature for that platform since it's needed often
because of its "special" behaviour. For finer-graine
On Tue, 19 Sep 2023, Dan Fandrich via curl-library wrote:
I don't see any reasonable alternative to just disabling this test on NetBSD
and OpenBSD.
I also can't think of any ways for us to detect this "feature" very easily to
disable this test automatically. Maybe we should consider adding a
On Mon, Sep 18, 2023 at 01:13:34PM +0200, Christian Weisgerber via curl-library
wrote:
> Dan Fandrich:
> > I wanted to try this patch on NetBSD to see if it's related
> > to Nagle's algorithm, but couldn't get to the point where I could try it:
>
> > -http://%HOSTIP:%HTTPPORT/we/want/%TESTNUMBER
Dan Fandrich:
> I wanted to try this patch on NetBSD to see if it's related
> to Nagle's algorithm, but couldn't get to the point where I could try it:
> -http://%HOSTIP:%HTTPPORT/we/want/%TESTNUMBER -T %LOGDIR/test%TESTNUMBER.txt
> --limit-rate 64K --expect100-timeout 0.001
> +http://%HOSTIP:%H
On Sun, Sep 17, 2023 at 10:43:17PM +0200, Christian Weisgerber via curl-library
wrote:
> The comment for test1474 says "This test is quite timing dependent and
> tricky to set up." On OpenBSD, it fails every time for me. And this
> is not an overloaded machine.
I've noticed failures on the NetB
The comment for test1474 says "This test is quite timing dependent and
tricky to set up." On OpenBSD, it fails every time for me. And this
is not an overloaded machine.
The initial part of the trace suggests that none of the timing
happens as intended:
15:38:42.282589 == Info: Trying 127.0.0.
