Date: Fri, 27 Oct 2017 10:44:41 +0200 From: Norbert Koch <nkoch@demig.de> To: <freebsd-hackers@freebsd.org> Subject: crerating coredump of multithreaded process Message-ID: <e455d19c-72ac-3501-8764-415c4d154c74@demig.de>
next in thread | raw e-mail | index | archive | help
Hello. When trying to create the coredump of a running process (without killing it) under FreeBSD 10.3 I am seeing a somewhat strange behaviour. As I want to see the state of all threads, the q&d way of fork() + SIGABRT does not work for me. So, what I do is having a supervisor program waiting for SIGUSR1. When my application signals the wish to be coredumped it sends SIGSTOP to itself immediately after sending SIGUSR1. The supervisor then forks gcore. From what I can see using top, my application immediately starts again as if SIGCONT has been received while gcore hangs in wait. Gcore calls ptrace(PT_ATTACH) followed by waitpid(). So I assume that the ptrace call restarts my application and waitpid hangs (why?). If I manually send SIGCONT to my stopped application immediately before exec-ing gcore, the coredump is being created, but for obvious reasons not as consistent as I want it to be. I should add that in my application most other signals are blocked. Blocking (or not) SIGCONT seems to have no effect. Am I doing something wrong here? If yes, ist there a different/better/more elegant way of creating a consistent coredump? Thank you. --=20 Dipl.-Ing. Norbert Koch Entwicklung Prozessregler ***************************************** * demig Prozessautomatisierung GmbH * * * * Anschrift: Haardtstrasse 40 * * D-57076 Siegen * * Registergericht: Siegen HRB 2819 * * Geschaeftsfuehrer: Joachim Herbst, * * Winfried Held * * Telefon: +49 271 772020 * * Telefax: +49 271 74704 * * E-Mail: info@demig.de * * http://www.demig.de * *****************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e455d19c-72ac-3501-8764-415c4d154c74>