read.c fails to handle views of more than 2,147,479,552 bytes

[Aaron1011]

On Linux, the read syscall will transfer at most 2,147,479,552 bytes (~2.147 GB). This means that read will return 2,147,479,552 even if the file being read from has more data available.

read.c interprets this condition as the file being too short, resulting in an error:

libbacktrace/read.c

Lines 81 to 86 in 559ab7c

	if ((size_t) got < size)
	{
	error_callback (data, "file too short", 0);
	free (view->base);
	return 0;
	}

If a file's debuginfo sections add up to more than 2,147,479,552 bytes, this will cause a spurious failure:

libbacktrace/elf.c

Lines 3162 to 3165 in 559ab7c

	if (!backtrace_get_view (state, descriptor, min_offset,
	max_offset - min_offset,
	error_callback, data, &debug_view))
	goto fail;

I recognize that it's unusual for a file to have such a large amount of debug info. However, it would be very useful if libbacktrace could handle this case by using multiple read calls, as this issue makes it impossible to generate backtraces for such files.

[ianlancetaylor]

While I'm fine with fixing this, I need to check: is this a problem that actually occurs, or is this purely theoretical? The file read.c should never be used on a GNU/Linux system.

[Aaron1011]

@ianlancetaylor: This actually occured - see rust-lang/rust#69151.

[ianlancetaylor]

Again, though, read.c should never be used on a GNU/Linux system. Are you sure you've diagnosed the problem correctly?

[Aaron1011]

@ianlancetaylor: Yes - I stepped through with gdb, and verified that read.c was being used.

It looks like read.c is being explicitly selected by backtrace-rs, which is used by the Rust compiler.

Is read.rs unsupported on GNU/linux systems, or is it just that mmapio.c is more efficient?

[ianlancetaylor]

I see. Thanks for the info. Yes, mmapio.c is more efficient. I see they are also using alloc.c rather than mmap.c, which means that that version won't work correctly if invoked from a signal handler. Odd.

[MeFisto94]

Well, this triggers #29.
I am just about to check the patch, but that's why my debugger stepped into read.c as well!

[ianlancetaylor]

@Aaron1011 Could you show the readelf -S --wide output of the failing binary? I'm wondering whether there is really 2G of debug data in this file or whether, as @MeFisto94 suggests, this is due to data that we don't really need to read. Thanks.