* Volker Simonis: >> The other issue is that formally, there are significant restrictions on >> what kind of functionality is available after a fork call from a >> multi-threaded process. Only async-signal-safe functions are supported, >> and POSIX does not include malloc among them. glibc supports malloc as >> an extension, but many other things are broken to varying degrees.
> Well, as you said, on Linux malloc() is working and I haven't seen Correction: On glibc. Historically, musl did not have a working malloc after multi-threaded fork because POSIX does not require it. There have been some discussions about supporting it like an extension, similar to glibc, but I don't know the current state. > anything else broken until now. As far as I can see, dumping is only > calling some basic I/O functions which are all async-signal-safe. Do > you have anything concrete in mind for the "many other things are > broken to varying degrees". NSS functions such as getpwuid_r do not work reliably with glibc. Even the FILE * functions have issues. The workaround is to collect this information before the fork, and not use <stdio.h>. Thinking about it, the crash dumper would be more problematic in this regard, given the amount of information it collects. The heap dumper probably doesn't need all that. >> It would be safest to fork again and execve a helper process that >> processes the original forked process via mappings from /proc. >> > > The nice thing about this approach is that we're getting the > functionality basically "for free" because it uses Hotspot's own dump > routine without modifications. Processing memory mappings from /proc > would require rewriting the whole dump logic. Yes, that's true. > But there's another approach which I've also thought about. As I > mentioned in my first mail, the SA tools can already create a heap > dump from a core file. So we could immediately raise a SIGSEGV in the > child (which is async-hread-safe :) and create a core file. But you don't know where that coredump lands, and the coredump will also contain non-heap data or non-live heap objects, potentially making it much larger. Thanks, Florian
