Program size incorrectly checked when building for ESP32

[vladkorotnev]

I have a partitions.csv with two 0x180000 partitions, and platformio.ini configured like this, running on Windows 10.

When building, the build pipeline finds the partition size correctly (1,572,864 bytes) and claims that the program fits:

Checking size .pio\build\AKI_K875\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [==        ]  19.7% (used 64588 bytes from 327680 bytes)
Flash: [==========]  99.7% (used 1568765 bytes from 1572864 bytes)
CURRENT: upload_protocol = esptool
Looking for upload port...
Auto-detected: COM4

However the actual file created is 1,575,056 bytes (file size, not size on disk) — that is, 0x180890 bytes, which is much bigger than the 0x180000 byte partition. And so esptool tries to flash exactly that, which leads to the firmware crashing on startup:

...
Flash will be erased from 0x00010000 to 0x00190fff...
...
Compressed 1575056 bytes to 952743...
Writing at 0x00010000... (1 %)
...
Writing at 0x0018fa51... (100 %)
Wrote 1575056 bytes (952743 compressed) at 0x00010000 in 16.4 seconds (effective 768.8 kbit/s)...
Hash of data verified.
...
--- Terminal on COM4 | 115200 8-N-1
ets Jul 29 2019 12:21:46

rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13232
load:0x40080400,len:3028
entry 0x400805e4
ets Jul 29 2019 12:21:46

rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13232
load:0x40080400,len:3028
entry 0x400805e4
ets Jul 29 2019 12:21:46

... many more of the same thing ...

Which is kind of expected, since the flash was written correctly, but is being mapped into the memory according to the partition table — so part of the program ends up being not available, the code jumps somewhere into the uninitialized RAM, and things explodify.

Why does it think the program is smaller than it actually is? Could this be a Windows-specific issue? (I don't have a Linux or Mac machine to test)

I'm not 100% sure if this belongs in here or in some other part of the toolchain, please redirect me if needed.