From nobody Fri Oct 13 10:51:12 2023 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S6NbP0DrWz4wqcS for ; Fri, 13 Oct 2023 10:51:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S6NbN6JJdz4Ysv for ; Fri, 13 Oct 2023 10:51:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1697194272; a=rsa-sha256; cv=none; b=LWyKyuCvcFaLMOml2OA0HcJqB+mkPeA2VxcKsXCeCVd5BkvNa+jKSXqQdEm5uzLaRlqg7X vWrmA5vZWt+HTTQ1AmICzYfGPoa0ZNkPIE3DEyxrhd0NN5RWozUp2RWooADEq2++LtwU6a 3y6blIxyS1zTLJlv1e2INWWaVNmNe9jhNGdbBVmn6tHiiwUTqTKzJCs0ukJx9Y3x3CLX3y 0l703S9cP7Gc6Pi18QhqhJKZ2vhI8J2jNTspTaHMQ1UkCOe5M4SyRPV/jdeS+ZbfOXJzsA zj8NIB5znjHYzCuEd7NZ8Nx0/sbsmzyXCSLYjXwcJNMJKBf9iZww9MbDC+4cLA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1697194272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=v4eLuw34j30STU1dFtwKp8GfUdELenKm0TGaVHUCLBU=; b=NqwLeMnzRMoh7JwTB4ypdfwTnaYvBOtWrwsL3slOoYYaRfN+/aKRN8IQeNzH8kVH36UnTq O05YEQdfqk1OSmKIBAR0xMODoDV7yB+9+gSuYavgUWaPHsY36qJDqNppkWa+c36tp8fgfH S0mHXrmos5YjqILf3jaQrZAKt+CYeGkrhLkis0EFqas2Sn5Hjm8ntmsljvnpw/NHzcoqis gmIyNkvzzEH+I1jSra3xDUQdBISlMh3Lj7gnauA43kJSt/+0PgHC2wQHEpjDPJ4RsYqZiU uF134utvj0PsInPAV0PhrMWs7auoOrsxunxDBN76z+fiAyupiwX5g0iLyWr++g== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4S6NbN5NLWzl29 for ; Fri, 13 Oct 2023 10:51:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 39DApCHT062806 for ; Fri, 13 Oct 2023 10:51:12 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 39DApCof062805 for bugs@FreeBSD.org; Fri, 13 Oct 2023 10:51:12 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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 Date: Fri, 13 Oct 2023 10:51:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 13.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: schwarze@usta.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D266882 Ingo Schwarze changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schwarze@usta.de --- Comment #2 from Ingo Schwarze --- 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.=