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 |
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 > |
>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 |
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. |
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 |
Free forum by Nabble | Edit this page |