test 2500 too big allocation

[bagder]

I did this

I run test 2500 locally and it fails:

** TOO MUCH TOTAL ALLOCATION
1000000 maximum allocation allowed, did 1742888

The reason for this huge bump in allocation seems to be this:

MALLOC: malloc(1536000) at multi.c:3991 makes totally 1635420 bytes

Should it be this big? If so, we need to allow it in the test.

I expected the following

No response

curl/libcurl version

git master

operating system

Linux

[icing]

I run this test all the time locally, just did it again, and it works. What's the difference?

Ah, it's the use of recvmmsg() that is only used on linux.

[bagder]

MMSG_NUM * MSG_BUF_SIZE

So I presume we should consider allowing this size for h3 at least on Linux.

[icing]

We can try reducing the size, if we measure how that effects QUIC download performance. However, it's a single buffer per multi, not per connection.

[icing]

My follow up question would be: if this did not run with valgrind on CI, what made it unnoticed?

Update: we have no valgrind run in http3-linux.yml and linux.yml installs no nghttpx which means the h3 tests are skipped.

@vsz care to add some valgrind touch in http3-linux.yml?

[bagder]

My follow up question would be: if this did not run with valgrind on CI, what made it unnoticed?

This isn't valgrind, this is the memdebug-wrapper that logs all memory use so memanalyze can check it afterwards. And we can't use it with the threaded resolver because of how the logging is not thread-safe... Subject to fix soon I suppose!

[icing]

You are correct, the memcheck does not run bc of the threaded resolved. I meant that we should add valgrind because of the two other issues reported today.

Mixed that up here a bit, sorry.