Linux amd-x64 user minidump stream support

[Bittner Ede]

Hello everyone,

Currenlty I'm working on a feature which involves storing a memory area in the dump file as a custom stream. My code works well on windows x64 environment, but it does not on Linux.

When I call AddUserDataMinidumpStream it seems OK, however when the process crash happens, the result dump file does not have the private stream.

I've found the bug where the implementation started: https://bugs.chromium.org/p/crashpad/issues/detail?id=95 but it's still open.

Is this feature supported on Linux? The documentation was clear on on set_extra_memory_ranges, but AddUserDataMinidumpStream mentions only MAC as not supported.
Can some help me with this issue?

Regads,

Ede Bittner

[Bittner Ede]

After some investigation I've found the following: in the ModuleSnapshotElf::Initialize() function creates a note reader

elf_reader_->NotesWithNameAndType(CRASHPAD_ELF_NOTE_NAME,
                                      CRASHPAD_ELF_NOTE_TYPE_CRASHPAD_INFO,
                                     kMaxNoteSize);

This note reader never finds the CrashpadInfo structure in the main application file, however the special symbols are presented in the binary, when I listed with elfreader:

Displaying notes found in: .note.crashpad.info
  Owner                Data size        Description
  Crashpad             0x00000008       Unknown note type: (0x4f464e49)
   description data: 0c 6b cc 01 00 00 00 00

That's far where I got with this right now. Hope this will ring a bell, and can some help me out with this!

Thanks,

Ede Bittner

[Bittner Ede]

I think I found the main root cause of the issue. Crashpad_handler expects that the .note.crashpad.info should be placed in a segment marked with PT_NOTE. However in our case it is placed in the LOAD segment. So with elfreader I've got this result:

I think there are a several possible option to resolve this:

• crashpad handler shall iterate through the section descriptions instead of the filtering the segments and their types
• crashpad handler can have an additional parameter, where the crashpadInfo is located and use that for locating the info file
  
• using a custom link script in our application to make sure that linker place the .note.crashpad.info into the NOTE segment

[Mark Mentovai]

I don’t know what toolchain you’re using, but I tried gcc and clang with all of lld, gold, and binutils ld, and found the .note.crashpad.info section was properly typed as SHT_NOTE, and upon linking was associated with both a PT_LOAD and PT_NOTE segment.

--
You received this message because you are subscribed to the Google Groups "Crashpad-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crashpad-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/crashpad-dev/d40bd914-e912-4819-add2-0b8bbf2fc53cn%40chromium.org.

[Bittner Ede]

Hello Mark,

Thank you for your answer.

Currently the builds done on Ubuntu 20.04.5 LTS, with the following toolchain:

g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0

GNU ld (GNU Binutils for Ubuntu) 2.34

I've created a small sample application, but it works okay with crashpad in the same build environment. The readelf shows that .note.crashpad.info is in their correct place, so I can't reproduce the bug with a simple code.

Linker was called through g++, like this (I don't think any of these flags should affect the final result): g++ -Wl,-z,origin -Wl,-rpath,\$ORIGIN/lib -Wl,-rpath,/Qt/6.3.0/gcc_64/lib -Wl,-rpath-link,/Qt/6.3.0/gcc_64/lib

Also we have a tons of thrid party library maybe they are affecting linking result, but I don't know how can I debug that (or the linking process at all)

What do you think, how should we proceed to debug and resolve this issue?

Regards, 

Ede Bittner

[Bittner Ede]

Hello,

It seems we have found the root cause of the issue. We have a special part of our code, which access the .note.gnu.build-id through the following semantics:

char build_id __attribute__((section(".note.gnu.build-id"))) = '!';

This will place the build_id at the end of .note.gnu.build-id section.

However this also has the side effect that the .note.crashpad.info won't be placed in a note segment anymore. (I don't have any reason for this behavior right now)

So I'm trying to find a way to access the build-id note, without compromising the crashpad info placement during link time.