Date: Fri, 13 Oct 2023 10:51:12 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 266882] mandoc(1) crashes with a core dump if it cannot parse a manual page Message-ID: <bug-266882-227-2XTfbEyQQO@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-266882-227@https.bugs.freebsd.org/bugzilla/> References: <bug-266882-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D266882 Ingo Schwarze <schwarze@usta.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schwarze@usta.de --- Comment #2 from Ingo Schwarze <schwarze@usta.de> --- 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 invaria= nt is still being violated in the code: $ mandoc krb5_openlog.3 assertion "rval !=3D 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 rproducer is very valuable. Right now, we are in the middle of an OpenBSD release, so it will take up t= o a week before i will find the time of looking into this. Apparently, the bug is that some particular roff(7) escape sequence is like= ly 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 sequen= ce 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 ma= nual 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.=20 The pre-parser still sees the "\\" and consequently sees no user-defined st= ring replacement escape sequences. But when the "xx" string is later used, the "\\*" likely gets resolved to "\*", i.e. to a string replacement request, b= ut 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= .=20 Or something like that, i will have to investigate in detail. No wonder i was unable to construct a reproducer from scratch, given how cr= azy the reproducer actually looks... --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-266882-227-2XTfbEyQQO>