[PATCH] lib/message-file: close stream in destructor

[PATCH] lib/message-file: close stream in destructor

[David Bremner]

Without this,

$ make time-test OPTIONS=--small

leads to fatal errors from too many open files.

Thanks to st-gourichon-fid for bringing this problem to my attention in IRC.
---
 lib/message-file.c | 3 +++
 1 file changed, 3 insertions(+)

The regression test could be improved, but I wanted to get a fix out
and hopefully into master, as this is a problem that seems
particularly likely to hit new users during their initial notmuch-new.

diff --git a/lib/message-file.c b/lib/message-file.c
index 50855067..24c5fda4 100644
--- a/lib/message-file.c
+++ b/lib/message-file.c
@@ -46,6 +46,9 @@ _notmuch_message_file_destructor (notmuch_message_file_t *message)
     if (message->message)
 	g_object_unref (message->message);
 
+    if (message->stream)
+	g_object_unref (message->stream);
+
     return 0;
 }
 
-- 
2.20.1

Re: [PATCH] lib/message-file: close stream in destructor

[Will Dietz]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

Great, thank you!

Much appreciated, I actually was running into this yesterday.

( which for whatever reason led to posting this on the subject:
https://github.com/afewmail/afew/issues/193#issuecomment-490766850 )

Would the valgrind support in the test suite catch this sort of thing
(fd leak on relatively common path)?

Regardless, glad to see it fixed!

~Will

On Thu,  9 May 2019 21:23:24 -0300, David Bremner <david@tethera.net> wrote:
> Without this,
> 
> $ make time-test OPTIONS=--small
> 
> leads to fatal errors from too many open files.
> 
> Thanks to st-gourichon-fid for bringing this problem to my attention in IRC.
> ---
>  lib/message-file.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> The regression test could be improved, but I wanted to get a fix out
> and hopefully into master, as this is a problem that seems
> particularly likely to hit new users during their initial notmuch-new.
> 
> diff --git a/lib/message-file.c b/lib/message-file.c
> index 50855067..24c5fda4 100644
> --- a/lib/message-file.c
> +++ b/lib/message-file.c
> @@ -46,6 +46,9 @@ _notmuch_message_file_destructor (notmuch_message_file_t *message)
>      if (message->message)
>  	g_object_unref (message->message);
>  
> +    if (message->stream)
> +	g_object_unref (message->stream);
> +
>      return 0;
>  }
>  
> -- 
> 2.20.1
> 
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] lib/message-file: close stream in destructor

[David Bremner]

Will Dietz <w@wdtz.org> writes:

> Great, thank you!
>
> Much appreciated, I actually was running into this yesterday.
>
> ( which for whatever reason led to posting this on the subject:
> https://github.com/afewmail/afew/issues/193#issuecomment-490766850 )
>
> Would the valgrind support in the test suite catch this sort of thing
> (fd leak on relatively common path)?
>

Good question. It didn't in a naive test I tried (just running notmuch
new under valgrind --track-fds). This is probably has to do with glib
cleaning up the relevant objects during shutdown.

Re: [PATCH] lib/message-file: close stream in destructor

[David Bremner]

David Bremner <david@tethera.net> writes:

> Without this,
>
> $ make time-test OPTIONS=--small
>
> leads to fatal errors from too many open files.
>
> Thanks to st-gourichon-fid for bringing this problem to my attention in IRC.
> ---
>  lib/message-file.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> The regression test could be improved, but I wanted to get a fix out
> and hopefully into master, as this is a problem that seems
> particularly likely to hit new users during their initial notmuch-new.
>
> diff --git a/lib/message-file.c b/lib/message-file.c
> index 50855067..24c5fda4 100644
> --- a/lib/message-file.c
> +++ b/lib/message-file.c
> @@ -46,6 +46,9 @@ _notmuch_message_file_destructor (notmuch_message_file_t *message)
>      if (message->message)
>  	g_object_unref (message->message);
>  
> +    if (message->stream)
> +	g_object_unref (message->stream);
> +
>      return 0;
>  }
>  
> -- 
> 2.20.1

I received several reports that this fixes the problem, so I've pushed
it to master.