Debugger crashes when loading debuginfo

[KapiX]

Repro package: ​http://haiku.kacperkasper.pl/instdir.zip (356 MB)

1. cd program
2. LIBRARY_PATH=.:$LIBRARY_PATH svdemo
3. svdemo crashes. Click Debug.
4. Debugger will crash while loading debuginfo after some time.

1. export LIBRARY_PATH=.:$LIBRARY_PATH
2. LD_PRELOAD=libroot_debug.so MALLOC_DEBUG=g Debugger svdemo
3. svdemo crashes. Click Debug.
4. Debugger crashes almost immediately.

hrev50794 gcc5h

Reports attached.

[mmlr]

Replying to KapiX:

1. export LIBRARY_PATH=.:$LIBRARY_PATH
2. LD_PRELOAD=libroot_debug.so MALLOC_DEBUG=g Debugger svdemo
3. svdemo crashes. Click Debug.
4. Debugger crashes almost immediately.

The report with libroot_debug shows a debugger call due to failure to allocate a new memory area (i.e. the system's out of memory or the application ran out of address space). Considering that using libroot_debug with the guarded heap consumes a lot of extra memory, this isn't too surprising.

It is possible that the original crash was also due to an out of memory/address space situation since both stack traces seem to be in the path of hoard resizing. The handling of such situations should then be reviewed.

To avoid running out of address space you could try reproducing on a 64 bit installation instead. If the used memory indication in the report is correct, available memory shouldn't be the problem.

[anevilyak]

I was going to ask the same, this looks nearly identical to what occurs when attempting to debug WebKit on 32-bit, where we exhaust the address space while parsing the info. It may or may not also help to specify -fdebug-types-section in your debug build flags for your app.

[KapiX]

The issue with trying 64-bit is that it requires some more work without getting actual results. LibreOffice needs a long list of libraries present to even start compiling, and then the compilation takes around 6 hours on my machine.

I'll try stripping and keeping two sets of libraries - with and without debuginfo - and use debuginfo from one at a time. Maybe that will get me somewhere.

This should be fixed nonetheless because I don't think one failed allocation should bring the whole process down.

Bonus question: why do I see memory exhaustion when not even 50% of total available memory is allocated? I know there are limits of allocated memory for one process, but isn't it around 2 GB mark?

[anevilyak]

It's more complicated than that: the userland of a single process has 2gb of address space to work with. Note that this is not entirely equivalent to having 2gb of memory to work with since, e.g. the area mappings for the various shared libraries the app uses take up address space despite not taking additional memory for the code segments that are common across apps. In addition, there are other area mappings that are needed for things like system calls, which again take up address space without taking up memory. All of this also potentially results in address space fragmentation such that an area allocation may fail simply due to there not being a large enough contiguous chunk to satisfy the request. The latter may be what's happening with hoard, but at the moment it's difficult to tell for sure.

-fdebug-types-section would be worth trying on 32-bit either way, since it allows gcc to eliminate a lot of redundant debug info, which may lower the memory requirements (this option is disabled by default since not all versions of various open source dev tools know how to grok .debug_types).

[anevilyak]

Moving to libroot since this appears to be an issue with either hoard itself, or our backend. The codepaths in question on the debugger side use std::nothrow and check the allocation result, so the expected behavior would be for the allocation to fail and return NULL.