Description
Raised at https://forum.micropython.org/viewtopic.php?f=18&t=7208
At the point that modussl_mbedtls.c calls mbedtls_ssl_setup, the ESP32 heap looks like this:
Heap summary for capabilities 0x00001800:
At 0x3ffaff10 len 240 free 0 allocated 168 min_free 0
largest_free_block 0 alloc_blocks 10 free_blocks 0 total_blocks 10
At 0x3ffb6388 len 7288 free 0 allocated 7168 min_free 0
largest_free_block 0 alloc_blocks 22 free_blocks 0 total_blocks 22
At 0x3ffb9a20 len 16648 free 0 allocated 16324 min_free 0
largest_free_block 0 alloc_blocks 73 free_blocks 0 total_blocks 73
At 0x3ffcc870 len 79760 free 26808 allocated 52520 min_free 19840
largest_free_block 26716 alloc_blocks 94 free_blocks 6 total_blocks 100
At 0x3ffe0440 len 15072 free 15036 allocated 0 min_free 15036
largest_free_block 15036 alloc_blocks 0 free_blocks 1 total_blocks 1
At 0x3ffe4350 len 113840 free 4092 allocated 109708 min_free 4092
largest_free_block 4092 alloc_blocks 1 free_blocks 1 total_blocks 2
Totals:
free 45936 allocated 185888 min_free 38968 largest_free_block 26716
mbedtls_ssl_setup tries to allocate two 16717 buffers -- the first (ssl->in_buf) succeeds (likely from the fourth block) then the second (ssl->out_buf ) fails.
Easy workaround would be to enable CONFIG_MBEDTLS_ASYMMETRIC_CONTENT_LEN (which would drop the output buffer to 4kiB).
I'll grab the heap info for a 3.3 build. I'm guessing that by chance the fragmentation across the blocks just ends up being slightly more favourable to two >16kiB allocations.