systat memory leak

[Anindya Mukherjee]

Hi, there seems to be a memory leak in systat where the help text buffer
is not freed under some circumstances. As a result, repeatedly pressing,
for example, 'h' and 'space' keys will cause it to leak memory. Also
entering command mode with an active help text will leak the text. The
following diff fixes it.

Index: engine.c
===================================================================
RCS file: /cvs/src/usr.bin/systat/engine.c,v
retrieving revision 1.26
diff -u -p -r1.26 engine.c
--- engine.c    9 Jan 2021 12:49:09 -0000       1.26
+++ engine.c    6 Feb 2021 03:07:37 -0000
@@ -1139,7 +1139,7 @@ command_set(struct command *cmd, const c
                        cmdbuf[0] = 0;
                }
        }
-       curr_message = NULL;
+       message_set(NULL);
        curr_cmd = cmd;
        need_update = 1;
        return prev;
@@ -1235,7 +1235,7 @@ keyboard(void)

        if (curr_message != NULL) {
                if (ch > 0) {
-                       curr_message = NULL;
+                       message_set(NULL);
                        need_update = 1;
                }
        }

ok?

Regards,
Anindya

[Theo Buehler-3]

On Sat, Feb 06, 2021 at 03:20:20AM +0000, Anindya Mukherjee wrote:
> Hi, there seems to be a memory leak in systat where the help text buffer
> is not freed under some circumstances. As a result, repeatedly pressing,
> for example, 'h' and 'space' keys will cause it to leak memory. Also
> entering command mode with an active help text will leak the text. The
> following diff fixes it.

Thanks for the diff, I committed it. I had to re-do it since your mailer
used some MIME encoding, the result is visible here:
https://marc.info/?l=openbsd-bugs&m=161258168001057&q=mbox

While using bugs@ is perfectly fine, I would probably rather send such
a fix to tech@.

>
> Index: engine.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/systat/engine.c,v
> retrieving revision 1.26
> diff -u -p -r1.26 engine.c
> --- engine.c    9 Jan 2021 12:49:09 -0000       1.26
> +++ engine.c    6 Feb 2021 03:07:37 -0000
> @@ -1139,7 +1139,7 @@ command_set(struct command *cmd, const c
>                         cmdbuf[0] = 0;
>                 }
>         }
> -       curr_message = NULL;
> +       message_set(NULL);
>         curr_cmd = cmd;
>         need_update = 1;
>         return prev;
> @@ -1235,7 +1235,7 @@ keyboard(void)
>
>         if (curr_message != NULL) {
>                 if (ch > 0) {
> -                       curr_message = NULL;
> +                       message_set(NULL);
>                         need_update = 1;
>                 }
>         }
>
> ok?
>
> Regards,
> Anindya
>

[Anindya Mukherjee]

 >From: Theo Buehler <[hidden email]>

>Sent: February 5, 2021 10:33 PM
>To: Anindya Mukherjee <[hidden email]>
>Cc: [hidden email] <[hidden email]>
>Subject: Re: systat memory leak
>
>On Sat, Feb 06, 2021 at 03:20:20AM +0000, Anindya Mukherjee wrote:
>> Hi, there seems to be a memory leak in systat where the help text buffer
>> is not freed under some circumstances. As a result, repeatedly pressing,
>> for example, 'h' and 'space' keys will cause it to leak memory. Also
>> entering command mode with an active help text will leak the text. The
>> following diff fixes it.
>
>Thanks for the diff, I committed it. I had to re-do it since your mailer
>used some MIME encoding, the result is visible here:
>https://marc.info/?l=openbsd-bugs&m=161258168001057&q=mbox

Sorry about that! It looks horrible! Thanks for letting me know. Is this
message also garbled? I'm using the outlook.com website set to plain
text, but it still managed to mess it up somehow.

>
>While using bugs@ is perfectly fine, I would probably rather send such
>a fix to tech@.
>

Thanks! I'll keep that in mind for future submissions.

Regards,
Anindya

[Stuart Henderson]

On 2021/02/06 07:24, Anindya Mukherjee wrote:
>  >From: Theo Buehler <[hidden email]>
> >
> >Thanks for the diff, I committed it. I had to re-do it since your mailer
> >used some MIME encoding, the result is visible here:
> >https://marc.info/?l=openbsd-bugs&m=161258168001057&q=mbox

quoted-printable.

> Sorry about that! It looks horrible! Thanks for letting me know. Is this
> message also garbled? I'm using the outlook.com website set to plain
> text, but it still managed to mess it up somehow.

It's "plain" text (as in "not html") but it's encoded. At least it's
mostly readable and not as bad as one of the popular privacy-focussed
email servers that base64-encodes text...

It's best if it can be avoided sender-side (some people will just ignore
mails sent like this) but can be handled receiver side if necessary.
In mutt if you pipe it from the view-attachment menu (usually on 'v')
it will be decoded automatically (whereas if you pipe from the mailbox
listing it will be sent raw). Or there's "qprint" in ports. It's easier
than bad word wrapping which can often not be fixed automatically.

[Anindya Mukherjee]

On Sat, Feb 06, 2021 at 11:47:56AM +0000, Stuart Henderson wrote:

> On 2021/02/06 07:24, Anindya Mukherjee wrote:
> >  >From: Theo Buehler <[hidden email]>
> > >
> > >Thanks for the diff, I committed it. I had to re-do it since your mailer
> > >used some MIME encoding, the result is visible here:
> > >https://marc.info/?l=openbsd-bugs&m=161258168001057&q=mbox
>
> quoted-printable.
>
> > Sorry about that! It looks horrible! Thanks for letting me know. Is this
> > message also garbled? I'm using the outlook.com website set to plain
> > text, but it still managed to mess it up somehow.
>
> It's "plain" text (as in "not html") but it's encoded. At least it's
> mostly readable and not as bad as one of the popular privacy-focussed
> email servers that base64-encodes text...

It seems it was being encoded as ISO-8859-1.

>
> It's best if it can be avoided sender-side (some people will just ignore
> mails sent like this) but can be handled receiver side if necessary.
> In mutt if you pipe it from the view-attachment menu (usually on 'v')
> it will be decoded automatically (whereas if you pipe from the mailbox
> listing it will be sent raw). Or there's "qprint" in ports. It's easier
> than bad word wrapping which can often not be fixed automatically.
>

I have set up mutt :)
Hopefully this renders correctly now.

Anindya