Signed integer overflow when analysing libraries with combined size >2GB

[jchl]

It appears that bloaty is using signed 32-bit integers to store sizes, for when analysing a large number of libraries with a combined size of greater than about 2GB the size is printed as negative.

For example, this set of libraries has a combined size of about 2.6GB, and yet the total size is given as -1.59GB:

$ bloaty -d sections `cat /tmp/libs`
     VM SIZE                         FILE SIZE
 --------------                   --------------
  37.8%  1.43Gi .bss                    0   0.0%
  29.2%  1.11Gi .text              1.11Gi  46.0%
   9.7%   377Mi .data               377Mi  15.3%
   6.0%   233Mi .dynstr             233Mi   9.5%
   5.6%   216Mi .rodata             216Mi   8.8%
   3.0%   116Mi .rel.dyn            116Mi   4.7%
   2.6%   101Mi .eh_frame           101Mi   4.1%
   1.7%  67.2Mi .dynsym            67.2Mi   2.7%
   1.2%  46.6Mi .data.rel.ro       46.6Mi   1.9%
   0.6%  23.8Mi .plt               23.8Mi   1.0%
   0.6%  23.8Mi .gnu.hash          23.8Mi   1.0%
   0.6%  23.2Mi .gcc_except_table  23.2Mi   0.9%
   0.0%       0 .gnu_debugdata     21.9Mi   0.9%
   0.4%  16.9Mi .eh_frame_hdr      16.9Mi   0.7%
   0.2%  7.02Mi [33 Others]        13.0Mi   0.5%
   0.3%  11.9Mi .rel.plt           11.9Mi   0.5%
   0.0%       0 [Unmapped]         9.46Mi   0.4%
   0.2%  8.40Mi .gnu.version       8.40Mi   0.3%
   0.0%  1.24Mi [ELF Headers]      6.62Mi   0.3%
   0.2%  5.99Mi .got.plt           5.99Mi   0.2%
   0.0%       0 .debug_info        4.68Mi   0.2%
 100.0%  -209Mi TOTAL             -1.59Gi 100.0%

This is with a 32-bit build of bloaty, on Linux.

[haberman]

The code attempts to use int64_t throughout, but clearly there is a bug somewhere.

Glancing at the code, I think it might be this function that is causing the problem. It uses ssize_t instead of int64_t.

Do you want to try changing the parameter to int64_t and see if that solves your problem?

bloaty/src/bloaty.cc

Line 677 in d9c90b1

std::string SiPrint(ssize_t size, bool force_sign) {

[haberman]

This was fixed in #193 (thanks!).