From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17857 invoked from network); 13 Oct 2023 10:57:41 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 13 Oct 2023 10:57:41 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id b22b3c49 for ; Fri, 13 Oct 2023 10:57:39 +0000 (UTC) Received: from scc-mailout-kit-01.scc.kit.edu (scc-mailout-kit-01.scc.kit.edu [129.13.231.81]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 921ea84c for ; Fri, 13 Oct 2023 10:57:39 +0000 (UTC) Received: from hekate.asta.kit.edu ([2a00:1398:5:f401::77]) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (envelope-from ) id 1qrFrO-00FOkE-0v; Fri, 13 Oct 2023 12:57:38 +0200 Received: from login-1.asta.kit.edu ([2a00:1398:5:f400::72]) by hekate.asta.kit.edu with esmtp (Exim 4.94.2) (envelope-from ) id 1qrFrN-002N0L-97; Fri, 13 Oct 2023 12:57:37 +0200 Received: from schwarze by login-1.asta.kit.edu with local (Exim 4.94.2) (envelope-from ) id 1qrFrN-00Eizj-1s; Fri, 13 Oct 2023 12:57:37 +0200 Date: Fri, 13 Oct 2023 12:57:37 +0200 From: Ingo Schwarze To: Baptiste Daroussin Cc: tech@mandoc.bsd.lv Subject: Re: Crash core dump when parsing krb5_openlog.3 Message-ID: References: X-Mailinglist: mandoc-tech Reply-To: tech@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi Bapt, Baptiste Daroussin wrote on Fri, Oct 13, 2023 at 09:06:56AM +0200: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266882 > I haven't had time yet to debug, do you actually need more information? No, the information in that report is perfect. That's a very useful report, i replied to it here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266882#c2 Pasting the reply here, too: Actually, with mandoc-current, i get a different assertion, but in the same function, and judging from what i know about the code, i hold a strong suspicion that the root cause is still the same, i.e. that the same invariant is still being violated in the code: $ mandoc krb5_openlog.3 assertion "rval != ESCAPE_EXPAND" failed: file "/usr/src/usr.bin/mandoc/roff_escape.c", line 46, function "mandoc_escape" Abort trap (core dumped) This is a very important bug report because this particular bug has already been reported a few weeks ago, but the reporter was unable to provide a reproducer. I tried to construct a reproducer from code inspection but unfortunately failed. So having the reproducer is very valuable. Right now, we are in the middle of an OpenBSD release, so it will take up to a week before i will find the time of looking into this. Apparently, the bug is that some particular roff(7) escape sequence is likely regarded as output-device-dependent by the roff(7) pre-parser and hence not substituted but instead left for the formatters to handle, similar to the \*(.T predefined string, but the formatters regards that particular escape sequence as one that should have been replaced by the pre-parser, hence dying because they cannot handle it. Having a quick look at your reproducing input file, i suspect that the following input confuses mandoc: .\" ouch! .ds xx \\*(fP\fR(\fP\\*(lI*\\*(fP Notably, you already marked that line with "ouch" in the manual page source code, presumably acknowledging that doing such low-level gymnastics in a manual page is asking for trouble. To not handle such madness gracefully is still a bug in mandoc though, i do not deny that. I suspect that using the extremely special escape sequence "\\" inside .ds is confusing mandoc - that sequence is mostly intended for being used inside .de. The pre-parser still sees the "\\" and consequently sees no user-defined string replacement escape sequences. But when the "xx" string is later used, the "\\*" likely gets resolved to "\*", i.e. to a string replacement request, but at the point, the pre-parser has already been run so the string does not get replaced and makes it through to the formatters, and those cannot handle it. Or something like that, i will have to investigate in detail. No wonder i was unable to construct a reproducer from scratch, given how crazy the reproducer actually looks... Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv