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=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16533 invoked from network); 4 Oct 2021 10:12:59 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 4 Oct 2021 10:12:59 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 109e58f7 for ; Mon, 4 Oct 2021 05:12:57 -0500 (EST) Received: from localhost (mandoc.bsd.lv [local]) by mandoc.bsd.lv (OpenSMTPD) with ESMTPA id 43da3517 for ; Mon, 4 Oct 2021 05:12:57 -0500 (EST) Date: Mon, 4 Oct 2021 05:12:57 -0500 (EST) X-Mailinglist: mandoc-source Reply-To: source@mandoc.bsd.lv MIME-Version: 1.0 From: schwarze@mandoc.bsd.lv To: source@mandoc.bsd.lv Subject: mandoc: Do not leak 64 bytes of heap memory every time a manual page X-Mailer: activitymail 1.26, http://search.cpan.org/dist/activitymail/ Content-Type: text/plain; charset=utf-8 Message-ID: Log Message: ----------- Do not leak 64 bytes of heap memory every time a manual page calls a user-defined macro. Calls of standard mdoc(7) and man(7) macros were unaffected, so the effect on OpenBSD manual pages was small, about 80 Kilobytes grand total for a full run of "makewhatis /usr/share/man". Argument expansion contexts for user-defined macros are stored on a stack that grows as needed if calls of user-defined macros are nested or recursive. Individual stack entries contain dynamically allocated arrays of pointers to arguments; these argument arrays also grow as needed if user-defined macros take more than eight arguments. The mistake was that argument arrays of already initialized expansion contexts were leaked rather than reused on subsequent macro calls. I found this issue in a systematic hunt for memory leaks after Michael reported memory exhaustion problems on the production server manpages.debian.org. This sub-Megabyte leak is not the cause of Michael's trouble, though, where Gigabytes of memory are being wasted. We are still investigating whether the original problem may be related to his supervisor process, which is written in Go, rather than to mandoc. Modified Files: -------------- mandoc: roff.c Revision Data ------------- Index: roff.c =================================================================== RCS file: /home/cvs/mandoc/mandoc/roff.c,v retrieving revision 1.378 retrieving revision 1.379 diff -Lroff.c -Lroff.c -u -p -r1.378 -r1.379 --- roff.c +++ roff.c @@ -3949,9 +3949,7 @@ roff_userdef(ROFF_ARGS) r->mstacksz += 8; } ctx = r->mstack + r->mstackpos; - ctx->argsz = 0; ctx->argc = 0; - ctx->argv = NULL; /* * Collect pointers to macro argument strings, -- To unsubscribe send an email to source+unsubscribe@mandoc.bsd.lv