memory leak using body_string without a messageID

[LorenzoTa]

Hello and thanks for your module!

I used inadvertedly $imap->body_string() instead of $imap->body_string( $msg ) and the program leaked a lot of memory until I killed it. I'm using the currently latest version 3.43

I suspect it tried to read all messages in the currently selected, huge, imap folder.

I hope is not something affecting all methods acceppting one or more message IDs.

ATM I have no time to investigate it further.

Thanks for reading

L*

[plobbes]

Based on this initial description, it sounds like you have a very large folder and you told Mail::IMAPClient to do an inefficient thing which will cause it to use lots of memory. There's a reason that the API allows you to work on a per message basis instead of always loading an entire folder (into memory). Unless you can provide some evidence of an actual leak, what I believe you found is an inefficient way to work with large folders. This sounds to be working as designed. Phil

…

On Mon, Jan 23, 2023 at 7:18 AM LorenzoTa ***@***.***> wrote: Hello and thanks for your module! I used inadvertedly $imap->body_string() instead of $imap->body_string( $msg ) and the program leaked a lot of memory until I killed it. I'm using the currently latest version 3.43 I suspect it tried to read all messages in the currently selected, huge, imap folder. I hope is not something affecting all methods acceppting one or more message IDs. ATM I have no time to investigate it further. Thanks for reading L* — Reply to this email directly, view it on GitHub <#4>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ6PR5JSWB77RUVGR3AODLWTZZLBANCNFSM6AAAAAAUDYT64I> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[LorenzoTa]

Thanks for looking!

here a simple program: see around line 113 and 114 I think is simple enough, If you think this is not an issue, close it, but I suspect somthing wrong when nothing is passed instead of a message ID

imap-monitorV3-pruned.pl.txt

The supposed wrong behaviour happens if you uncomment line 114. Sorry I left usage sub in Italian :)

thanks

[LorenzoTa]

Hello again,

I see that body_string calls fetch which has my $what = shift || "ALL";

So what I experiencing is by design. Infact it is documented under fetch: If no arguments are supplied then fetch does a FETCH ALL.

All is ok, but I'd put this in the top of the documentation that all the following methods:

• bodypart_string
• message_uid
• body_string
• get_bodystructure
• get_envelope
• fetch_hash (and so also the migrate methods)
• flags
• parse_headers
• size

will try to operate on ALL messages if not messageID or list of them is passed.

thanks for reading

L*

[plobbes]

Thanks for the suggestion!

…

On Tue, Jan 24, 2023 at 5:24 AM LorenzoTa ***@***.***> wrote: Hello again, I see that body_string calls fetch <https://metacpan.org/dist/Mail-IMAPClient/source/lib/Mail/IMAPClient.pm#L2150> which has my $what = shift || "ALL"; So what I experiencing is by design. Infact it is documented under fetch: *If no arguments are supplied then fetch does a FETCH ALL.* All is ok, but I'd put this in the top of the documentation that all the following methods: - bodypart_string - message_uid - body_string - get_bodystructure - get_envelope - fetch_hash (and so also the migrate methods) - flags - parse_headers - size will try to operater on *ALL* messages if not messageID or list of them is passed. thanks for reading L* — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ6PR75LTG4J5JFMSAY2P3WT6UWBANCNFSM6AAAAAAUDYT64I> . You are receiving this because you commented.Message ID: ***@***.***>