* read after free in notmuch new
@ 2017-02-19 14:15 David Bremner
2017-02-19 15:29 ` David Bremner
0 siblings, 1 reply; 10+ messages in thread
From: David Bremner @ 2017-02-19 14:15 UTC (permalink / raw)
To: notmuch
[-- Attachment #1: Type: text/plain, Size: 377 bytes --]
I haven't had a chance to really track this down, but it seems there is
a memory error in notmuch new (or a maybe false positive from valgrind).
Attached is the log from running "make memory-test OPTIONS=--medium" on
current git master (0e037c34).
It looks like we talloc the message_id string with the message object as
parent, but it somehow outlives the message object.
[-- Attachment #2: 1.log --]
[-- Type: application/octet-stream, Size: 32040 bytes --]
==4626== Memcheck, a memory error detector
==4626== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==4626== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==4626== Command: notmuch new
==4626== Parent PID: 11236
==4626==
==4626== Invalid read of size 1
==4626== at 0x4C2DDA2: strlen (vg_replace_strmem.c:454)
==4626== by 0x642FDA2: vfprintf (vfprintf.c:1637)
==4626== by 0x64DD9A5: __vsnprintf_chk (vsnprintf_chk.c:63)
==4626== by 0x561916D: ??? (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x5619708: talloc_vasprintf (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x56197B6: talloc_asprintf (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x12F436: _notmuch_message_add_term (message.cc:1204)
==4626== by 0x129B2F: _notmuch_database_link_message_to_parents (database.cc:2200)
==4626== by 0x129B2F: _notmuch_database_link_message (database.cc:2371)
==4626== by 0x129B2F: notmuch_database_add_message (database.cc:2521)
==4626== by 0x11AACE: add_file (notmuch-new.c:264)
==4626== by 0x11AACE: add_files (notmuch-new.c:599)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== Address 0x12226470 is 96 bytes inside a block of size 131 free'd
==4626== at 0x4C2BDDB: free (vg_replace_malloc.c:530)
==4626== by 0x561486A: _talloc_free (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x533466C: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x5334A69: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x125720: parse_references(void*, char const*, _GHashTable*, char const*) (database.cc:647)
==4626== by 0x129AEA: _notmuch_database_link_message_to_parents (database.cc:2188)
==4626== by 0x129AEA: _notmuch_database_link_message (database.cc:2371)
==4626== by 0x129AEA: notmuch_database_add_message (database.cc:2521)
==4626== by 0x11AACE: add_file (notmuch-new.c:264)
==4626== by 0x11AACE: add_files (notmuch-new.c:599)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11B48C: notmuch_new_command (notmuch-new.c:1100)
==4626== Block was alloc'd at
==4626== at 0x4C2ABAF: malloc (vg_replace_malloc.c:299)
==4626== by 0x5617591: talloc_strndup (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x125624: _parse_message_id(void*, char const*, char const**) (database.cc:606)
==4626== by 0x1256FC: parse_references(void*, char const*, _GHashTable*, char const*) (database.cc:644)
==4626== by 0x129AEA: _notmuch_database_link_message_to_parents (database.cc:2188)
==4626== by 0x129AEA: _notmuch_database_link_message (database.cc:2371)
==4626== by 0x129AEA: notmuch_database_add_message (database.cc:2521)
==4626== by 0x11AACE: add_file (notmuch-new.c:264)
==4626== by 0x11AACE: add_files (notmuch-new.c:599)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11B48C: notmuch_new_command (notmuch-new.c:1100)
==4626== by 0x114669: main (notmuch.c:456)
==4626==
==4626== Invalid read of size 1
==4626== at 0x4C2DDB4: strlen (vg_replace_strmem.c:454)
==4626== by 0x642FDA2: vfprintf (vfprintf.c:1637)
==4626== by 0x64DD9A5: __vsnprintf_chk (vsnprintf_chk.c:63)
==4626== by 0x561916D: ??? (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x5619708: talloc_vasprintf (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x56197B6: talloc_asprintf (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x12F436: _notmuch_message_add_term (message.cc:1204)
==4626== by 0x129B2F: _notmuch_database_link_message_to_parents (database.cc:2200)
==4626== by 0x129B2F: _notmuch_database_link_message (database.cc:2371)
==4626== by 0x129B2F: notmuch_database_add_message (database.cc:2521)
==4626== by 0x11AACE: add_file (notmuch-new.c:264)
==4626== by 0x11AACE: add_files (notmuch-new.c:599)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== Address 0x12226471 is 97 bytes inside a block of size 131 free'd
==4626== at 0x4C2BDDB: free (vg_replace_malloc.c:530)
==4626== by 0x561486A: _talloc_free (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x533466C: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x5334A69: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x125720: parse_references(void*, char const*, _GHashTable*, char const*) (database.cc:647)
==4626== by 0x129AEA: _notmuch_database_link_message_to_parents (database.cc:2188)
==4626== by 0x129AEA: _notmuch_database_link_message (database.cc:2371)
==4626== by 0x129AEA: notmuch_database_add_message (database.cc:2521)
==4626== by 0x11AACE: add_file (notmuch-new.c:264)
==4626== by 0x11AACE: add_files (notmuch-new.c:599)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11B48C: notmuch_new_command (notmuch-new.c:1100)
==4626== Block was alloc'd at
==4626== at 0x4C2ABAF: malloc (vg_replace_malloc.c:299)
==4626== by 0x5617591: talloc_strndup (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x125624: _parse_message_id(void*, char const*, char const**) (database.cc:606)
==4626== by 0x1256FC: parse_references(void*, char const*, _GHashTable*, char const*) (database.cc:644)
==4626== by 0x129AEA: _notmuch_database_link_message_to_parents (database.cc:2188)
==4626== by 0x129AEA: _notmuch_database_link_message (database.cc:2371)
==4626== by 0x129AEA: notmuch_database_add_message (database.cc:2521)
==4626== by 0x11AACE: add_file (notmuch-new.c:264)
==4626== by 0x11AACE: add_files (notmuch-new.c:599)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11B48C: notmuch_new_command (notmuch-new.c:1100)
==4626== by 0x114669: main (notmuch.c:456)
==4626==
==4626== Invalid read of size 1
==4626== at 0x4C320A8: __GI_mempcpy (vg_replace_strmem.c:1518)
==4626== by 0x645BC0D: _IO_default_xsputn (genops.c:438)
==4626== by 0x642FBDA: vfprintf (vfprintf.c:1637)
==4626== by 0x64DD9A5: __vsnprintf_chk (vsnprintf_chk.c:63)
==4626== by 0x561916D: ??? (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x5619708: talloc_vasprintf (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x56197B6: talloc_asprintf (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x12F436: _notmuch_message_add_term (message.cc:1204)
==4626== by 0x129B2F: _notmuch_database_link_message_to_parents (database.cc:2200)
==4626== by 0x129B2F: _notmuch_database_link_message (database.cc:2371)
==4626== by 0x129B2F: notmuch_database_add_message (database.cc:2521)
==4626== by 0x11AACE: add_file (notmuch-new.c:264)
==4626== by 0x11AACE: add_files (notmuch-new.c:599)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== Address 0x12226491 is 129 bytes inside a block of size 131 free'd
==4626== at 0x4C2BDDB: free (vg_replace_malloc.c:530)
==4626== by 0x561486A: _talloc_free (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x533466C: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x5334A69: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x125720: parse_references(void*, char const*, _GHashTable*, char const*) (database.cc:647)
==4626== by 0x129AEA: _notmuch_database_link_message_to_parents (database.cc:2188)
==4626== by 0x129AEA: _notmuch_database_link_message (database.cc:2371)
==4626== by 0x129AEA: notmuch_database_add_message (database.cc:2521)
==4626== by 0x11AACE: add_file (notmuch-new.c:264)
==4626== by 0x11AACE: add_files (notmuch-new.c:599)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11B48C: notmuch_new_command (notmuch-new.c:1100)
==4626== Block was alloc'd at
==4626== at 0x4C2ABAF: malloc (vg_replace_malloc.c:299)
==4626== by 0x5617591: talloc_strndup (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x125624: _parse_message_id(void*, char const*, char const**) (database.cc:606)
==4626== by 0x1256FC: parse_references(void*, char const*, _GHashTable*, char const*) (database.cc:644)
==4626== by 0x129AEA: _notmuch_database_link_message_to_parents (database.cc:2188)
==4626== by 0x129AEA: _notmuch_database_link_message (database.cc:2371)
==4626== by 0x129AEA: notmuch_database_add_message (database.cc:2521)
==4626== by 0x11AACE: add_file (notmuch-new.c:264)
==4626== by 0x11AACE: add_files (notmuch-new.c:599)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11B48C: notmuch_new_command (notmuch-new.c:1100)
==4626== by 0x114669: main (notmuch.c:456)
==4626==
==4626== Invalid read of size 1
==4626== at 0x4C320B8: __GI_mempcpy (vg_replace_strmem.c:1518)
==4626== by 0x645BC0D: _IO_default_xsputn (genops.c:438)
==4626== by 0x642FBDA: vfprintf (vfprintf.c:1637)
==4626== by 0x64DD9A5: __vsnprintf_chk (vsnprintf_chk.c:63)
==4626== by 0x561916D: ??? (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x5619708: talloc_vasprintf (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x56197B6: talloc_asprintf (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x12F436: _notmuch_message_add_term (message.cc:1204)
==4626== by 0x129B2F: _notmuch_database_link_message_to_parents (database.cc:2200)
==4626== by 0x129B2F: _notmuch_database_link_message (database.cc:2371)
==4626== by 0x129B2F: notmuch_database_add_message (database.cc:2521)
==4626== by 0x11AACE: add_file (notmuch-new.c:264)
==4626== by 0x11AACE: add_files (notmuch-new.c:599)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== Address 0x1222648f is 127 bytes inside a block of size 131 free'd
==4626== at 0x4C2BDDB: free (vg_replace_malloc.c:530)
==4626== by 0x561486A: _talloc_free (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x533466C: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x5334A69: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x125720: parse_references(void*, char const*, _GHashTable*, char const*) (database.cc:647)
==4626== by 0x129AEA: _notmuch_database_link_message_to_parents (database.cc:2188)
==4626== by 0x129AEA: _notmuch_database_link_message (database.cc:2371)
==4626== by 0x129AEA: notmuch_database_add_message (database.cc:2521)
==4626== by 0x11AACE: add_file (notmuch-new.c:264)
==4626== by 0x11AACE: add_files (notmuch-new.c:599)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11B48C: notmuch_new_command (notmuch-new.c:1100)
==4626== Block was alloc'd at
==4626== at 0x4C2ABAF: malloc (vg_replace_malloc.c:299)
==4626== by 0x5617591: talloc_strndup (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x125624: _parse_message_id(void*, char const*, char const**) (database.cc:606)
==4626== by 0x1256FC: parse_references(void*, char const*, _GHashTable*, char const*) (database.cc:644)
==4626== by 0x129AEA: _notmuch_database_link_message_to_parents (database.cc:2188)
==4626== by 0x129AEA: _notmuch_database_link_message (database.cc:2371)
==4626== by 0x129AEA: notmuch_database_add_message (database.cc:2521)
==4626== by 0x11AACE: add_file (notmuch-new.c:264)
==4626== by 0x11AACE: add_files (notmuch-new.c:599)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11A5E3: add_files (notmuch-new.c:483)
==4626== by 0x11B48C: notmuch_new_command (notmuch-new.c:1100)
==4626== by 0x114669: main (notmuch.c:456)
==4626==
==4626==
==4626== HEAP SUMMARY:
==4626== in use at exit: 661,584 bytes in 820 blocks
==4626== total heap usage: 132,610,938 allocs, 132,610,118 frees, 65,439,578,236 bytes allocated
==4626==
==4626== 16 bytes in 1 blocks are possibly lost in loss record 237 of 591
==4626== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==4626== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D6410: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DAF60: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50BA2AB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B4147: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626== by 0xFFF000552: ???
==4626==
==4626== 16 bytes in 1 blocks are possibly lost in loss record 238 of 591
==4626== at 0x4C2AADF: malloc (vg_replace_malloc.c:298)
==4626== by 0x4C2CE5F: realloc (vg_replace_malloc.c:785)
==4626== by 0x534BEC7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D62E0: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DAF60: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50BA2AB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B4147: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626==
==4626== 16 bytes in 1 blocks are possibly lost in loss record 239 of 591
==4626== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==4626== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D6410: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DAF60: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50BA311: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B4147: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626== by 0xFFF000552: ???
==4626==
==4626== 16 bytes in 1 blocks are possibly lost in loss record 240 of 591
==4626== at 0x4C2AADF: malloc (vg_replace_malloc.c:298)
==4626== by 0x4C2CE5F: realloc (vg_replace_malloc.c:785)
==4626== by 0x534BEC7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D62E0: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DAF60: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50BA311: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B4147: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626==
==4626== 16 bytes in 1 blocks are possibly lost in loss record 241 of 591
==4626== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==4626== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D6410: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DAF60: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50C39D4: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B4151: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626== by 0xFFF000552: ???
==4626==
==4626== 16 bytes in 1 blocks are possibly lost in loss record 242 of 591
==4626== at 0x4C2AADF: malloc (vg_replace_malloc.c:298)
==4626== by 0x4C2CE5F: realloc (vg_replace_malloc.c:785)
==4626== by 0x534BEC7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D62E0: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DAF60: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50C39D4: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B4151: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626==
==4626== 16 bytes in 1 blocks are possibly lost in loss record 243 of 591
==4626== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==4626== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D6410: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DAF60: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50BEB0B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B4156: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626== by 0xFFF000552: ???
==4626==
==4626== 16 bytes in 1 blocks are possibly lost in loss record 244 of 591
==4626== at 0x4C2AADF: malloc (vg_replace_malloc.c:298)
==4626== by 0x4C2CE5F: realloc (vg_replace_malloc.c:785)
==4626== by 0x534BEC7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D62E0: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DAF60: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50BEB0B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B4156: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626==
==4626== 96 bytes in 1 blocks are possibly lost in loss record 473 of 591
==4626== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==4626== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D5919: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50D5A03: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B407A: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626== by 0xFFF000552: ???
==4626==
==4626== 96 bytes in 1 blocks are possibly lost in loss record 474 of 591
==4626== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==4626== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D5919: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50D5A03: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DAF52: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50BA2AB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B4147: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626==
==4626== 96 bytes in 1 blocks are possibly lost in loss record 475 of 591
==4626== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==4626== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D5919: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50D5A03: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DAF52: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50BA311: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B4147: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626==
==4626== 96 bytes in 1 blocks are possibly lost in loss record 476 of 591
==4626== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==4626== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D5919: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50D5A03: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DAF52: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50C39D4: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B4151: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626==
==4626== 96 bytes in 1 blocks are possibly lost in loss record 477 of 591
==4626== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==4626== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D5919: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50D5A03: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DAF52: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50BEB0B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B4156: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626==
==4626== 96 bytes in 1 blocks are definitely lost in loss record 478 of 591
==4626== at 0x4C2ABAF: malloc (vg_replace_malloc.c:299)
==4626== by 0x561A6F2: talloc_enable_null_tracking (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==4626== by 0x1145CE: main (notmuch.c:417)
==4626==
==4626== 120 bytes in 1 blocks are possibly lost in loss record 518 of 591
==4626== at 0x4C2CDCF: realloc (vg_replace_malloc.c:785)
==4626== by 0x534BEC7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D5897: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DB29C: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x4E78B2D: internet_address_list_get_type (in /usr/lib/x86_64-linux-gnu/libgmime-2.6.so.0.621.0)
==4626== by 0x4E4B206: g_mime_init (in /usr/lib/x86_64-linux-gnu/libgmime-2.6.so.0.621.0)
==4626== by 0x1145EB: main (notmuch.c:421)
==4626==
==4626== 132 bytes in 1 blocks are possibly lost in loss record 522 of 591
==4626== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==4626== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D6D3F: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DAFB0: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50BA2AB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B4147: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626== by 0xFFF000552: ???
==4626==
==4626== 132 bytes in 1 blocks are possibly lost in loss record 523 of 591
==4626== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==4626== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D6D3F: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DAFB0: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50BA311: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B4147: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626== by 0xFFF000552: ???
==4626==
==4626== 148 bytes in 1 blocks are possibly lost in loss record 535 of 591
==4626== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==4626== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D6B02: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DAFB0: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50C39D4: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B4151: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626== by 0xFFF000552: ???
==4626==
==4626== 148 bytes in 1 blocks are possibly lost in loss record 536 of 591
==4626== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==4626== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D6B02: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DAFB0: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50BEB0B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B4156: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626== by 0xFFF000552: ???
==4626==
==4626== 184 bytes in 1 blocks are possibly lost in loss record 542 of 591
==4626== at 0x4C2CDCF: realloc (vg_replace_malloc.c:785)
==4626== by 0x534BEC7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==4626== by 0x50D5897: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50DB29C: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50C5659: g_param_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50C7983: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x50B415B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==4626== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==4626== by 0x400F6EA: call_init (dl-init.c:30)
==4626== by 0x400F6EA: _dl_init (dl-init.c:120)
==4626== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==4626== by 0x1: ???
==4626== by 0xFFF00054A: ???
==4626==
==4626== LEAK SUMMARY:
==4626== definitely lost: 96 bytes in 1 blocks
==4626== indirectly lost: 0 bytes in 0 blocks
==4626== possibly lost: 1,472 bytes in 19 blocks
==4626== still reachable: 659,936 bytes in 799 blocks
==4626== of which reachable via heuristic:
==4626== newarray : 1,536 bytes in 16 blocks
==4626== suppressed: 0 bytes in 0 blocks
==4626== Reachable blocks (those to which a pointer was found) are not shown.
==4626== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==4626==
==4626== For counts of detected and suppressed errors, rerun with: -v
==4626== ERROR SUMMARY: 240 errors from 24 contexts (suppressed: 0 from 0)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: read after free in notmuch new
2017-02-19 14:15 read after free in notmuch new David Bremner
@ 2017-02-19 15:29 ` David Bremner
2017-02-21 2:46 ` David Bremner
2017-03-01 1:49 ` read after free in notmuch new David Bremner
0 siblings, 2 replies; 10+ messages in thread
From: David Bremner @ 2017-02-19 15:29 UTC (permalink / raw)
To: notmuch
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
David Bremner <david@tethera.net> writes:
> I haven't had a chance to really track this down, but it seems there is
> a memory error in notmuch new (or a maybe false positive from valgrind).
>
> Attached is the log from running "make memory-test OPTIONS=--medium" on
> current git master (0e037c34).
>
> It looks like we talloc the message_id string with the message object as
> parent, but it somehow outlives the message object.
Sorry, that had a few commits beyond master.
master (08343d3d) gives essentially the same log.
[-- Attachment #2: 1.log --]
[-- Type: application/octet-stream, Size: 32040 bytes --]
==8681== Memcheck, a memory error detector
==8681== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==8681== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==8681== Command: notmuch new
==8681== Parent PID: 14825
==8681==
==8681== Invalid read of size 1
==8681== at 0x4C2DDA2: strlen (vg_replace_strmem.c:454)
==8681== by 0x642FDA2: vfprintf (vfprintf.c:1637)
==8681== by 0x64DD9A5: __vsnprintf_chk (vsnprintf_chk.c:63)
==8681== by 0x561916D: ??? (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x5619708: talloc_vasprintf (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x56197B6: talloc_asprintf (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x12F4F6: _notmuch_message_add_term (message.cc:1204)
==8681== by 0x129BEF: _notmuch_database_link_message_to_parents (database.cc:2210)
==8681== by 0x129BEF: _notmuch_database_link_message (database.cc:2381)
==8681== by 0x129BEF: notmuch_database_add_message (database.cc:2531)
==8681== by 0x11AA8E: add_file (notmuch-new.c:264)
==8681== by 0x11AA8E: add_files (notmuch-new.c:599)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== Address 0x159280c0 is 96 bytes inside a block of size 131 free'd
==8681== at 0x4C2BDDB: free (vg_replace_malloc.c:530)
==8681== by 0x561486A: _talloc_free (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x533466C: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x5334A69: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x1256E0: parse_references(void*, char const*, _GHashTable*, char const*) (database.cc:655)
==8681== by 0x129BAA: _notmuch_database_link_message_to_parents (database.cc:2198)
==8681== by 0x129BAA: _notmuch_database_link_message (database.cc:2381)
==8681== by 0x129BAA: notmuch_database_add_message (database.cc:2531)
==8681== by 0x11AA8E: add_file (notmuch-new.c:264)
==8681== by 0x11AA8E: add_files (notmuch-new.c:599)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11B44C: notmuch_new_command (notmuch-new.c:1100)
==8681== Block was alloc'd at
==8681== at 0x4C2ABAF: malloc (vg_replace_malloc.c:299)
==8681== by 0x5617591: talloc_strndup (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x1255E4: _parse_message_id(void*, char const*, char const**) (database.cc:614)
==8681== by 0x1256BC: parse_references(void*, char const*, _GHashTable*, char const*) (database.cc:652)
==8681== by 0x129BAA: _notmuch_database_link_message_to_parents (database.cc:2198)
==8681== by 0x129BAA: _notmuch_database_link_message (database.cc:2381)
==8681== by 0x129BAA: notmuch_database_add_message (database.cc:2531)
==8681== by 0x11AA8E: add_file (notmuch-new.c:264)
==8681== by 0x11AA8E: add_files (notmuch-new.c:599)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11B44C: notmuch_new_command (notmuch-new.c:1100)
==8681== by 0x114669: main (notmuch.c:456)
==8681==
==8681== Invalid read of size 1
==8681== at 0x4C2DDB4: strlen (vg_replace_strmem.c:454)
==8681== by 0x642FDA2: vfprintf (vfprintf.c:1637)
==8681== by 0x64DD9A5: __vsnprintf_chk (vsnprintf_chk.c:63)
==8681== by 0x561916D: ??? (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x5619708: talloc_vasprintf (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x56197B6: talloc_asprintf (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x12F4F6: _notmuch_message_add_term (message.cc:1204)
==8681== by 0x129BEF: _notmuch_database_link_message_to_parents (database.cc:2210)
==8681== by 0x129BEF: _notmuch_database_link_message (database.cc:2381)
==8681== by 0x129BEF: notmuch_database_add_message (database.cc:2531)
==8681== by 0x11AA8E: add_file (notmuch-new.c:264)
==8681== by 0x11AA8E: add_files (notmuch-new.c:599)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== Address 0x159280c1 is 97 bytes inside a block of size 131 free'd
==8681== at 0x4C2BDDB: free (vg_replace_malloc.c:530)
==8681== by 0x561486A: _talloc_free (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x533466C: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x5334A69: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x1256E0: parse_references(void*, char const*, _GHashTable*, char const*) (database.cc:655)
==8681== by 0x129BAA: _notmuch_database_link_message_to_parents (database.cc:2198)
==8681== by 0x129BAA: _notmuch_database_link_message (database.cc:2381)
==8681== by 0x129BAA: notmuch_database_add_message (database.cc:2531)
==8681== by 0x11AA8E: add_file (notmuch-new.c:264)
==8681== by 0x11AA8E: add_files (notmuch-new.c:599)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11B44C: notmuch_new_command (notmuch-new.c:1100)
==8681== Block was alloc'd at
==8681== at 0x4C2ABAF: malloc (vg_replace_malloc.c:299)
==8681== by 0x5617591: talloc_strndup (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x1255E4: _parse_message_id(void*, char const*, char const**) (database.cc:614)
==8681== by 0x1256BC: parse_references(void*, char const*, _GHashTable*, char const*) (database.cc:652)
==8681== by 0x129BAA: _notmuch_database_link_message_to_parents (database.cc:2198)
==8681== by 0x129BAA: _notmuch_database_link_message (database.cc:2381)
==8681== by 0x129BAA: notmuch_database_add_message (database.cc:2531)
==8681== by 0x11AA8E: add_file (notmuch-new.c:264)
==8681== by 0x11AA8E: add_files (notmuch-new.c:599)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11B44C: notmuch_new_command (notmuch-new.c:1100)
==8681== by 0x114669: main (notmuch.c:456)
==8681==
==8681== Invalid read of size 1
==8681== at 0x4C320A8: __GI_mempcpy (vg_replace_strmem.c:1518)
==8681== by 0x645BC0D: _IO_default_xsputn (genops.c:438)
==8681== by 0x642FBDA: vfprintf (vfprintf.c:1637)
==8681== by 0x64DD9A5: __vsnprintf_chk (vsnprintf_chk.c:63)
==8681== by 0x561916D: ??? (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x5619708: talloc_vasprintf (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x56197B6: talloc_asprintf (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x12F4F6: _notmuch_message_add_term (message.cc:1204)
==8681== by 0x129BEF: _notmuch_database_link_message_to_parents (database.cc:2210)
==8681== by 0x129BEF: _notmuch_database_link_message (database.cc:2381)
==8681== by 0x129BEF: notmuch_database_add_message (database.cc:2531)
==8681== by 0x11AA8E: add_file (notmuch-new.c:264)
==8681== by 0x11AA8E: add_files (notmuch-new.c:599)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== Address 0x159280e1 is 129 bytes inside a block of size 131 free'd
==8681== at 0x4C2BDDB: free (vg_replace_malloc.c:530)
==8681== by 0x561486A: _talloc_free (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x533466C: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x5334A69: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x1256E0: parse_references(void*, char const*, _GHashTable*, char const*) (database.cc:655)
==8681== by 0x129BAA: _notmuch_database_link_message_to_parents (database.cc:2198)
==8681== by 0x129BAA: _notmuch_database_link_message (database.cc:2381)
==8681== by 0x129BAA: notmuch_database_add_message (database.cc:2531)
==8681== by 0x11AA8E: add_file (notmuch-new.c:264)
==8681== by 0x11AA8E: add_files (notmuch-new.c:599)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11B44C: notmuch_new_command (notmuch-new.c:1100)
==8681== Block was alloc'd at
==8681== at 0x4C2ABAF: malloc (vg_replace_malloc.c:299)
==8681== by 0x5617591: talloc_strndup (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x1255E4: _parse_message_id(void*, char const*, char const**) (database.cc:614)
==8681== by 0x1256BC: parse_references(void*, char const*, _GHashTable*, char const*) (database.cc:652)
==8681== by 0x129BAA: _notmuch_database_link_message_to_parents (database.cc:2198)
==8681== by 0x129BAA: _notmuch_database_link_message (database.cc:2381)
==8681== by 0x129BAA: notmuch_database_add_message (database.cc:2531)
==8681== by 0x11AA8E: add_file (notmuch-new.c:264)
==8681== by 0x11AA8E: add_files (notmuch-new.c:599)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11B44C: notmuch_new_command (notmuch-new.c:1100)
==8681== by 0x114669: main (notmuch.c:456)
==8681==
==8681== Invalid read of size 1
==8681== at 0x4C320B8: __GI_mempcpy (vg_replace_strmem.c:1518)
==8681== by 0x645BC0D: _IO_default_xsputn (genops.c:438)
==8681== by 0x642FBDA: vfprintf (vfprintf.c:1637)
==8681== by 0x64DD9A5: __vsnprintf_chk (vsnprintf_chk.c:63)
==8681== by 0x561916D: ??? (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x5619708: talloc_vasprintf (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x56197B6: talloc_asprintf (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x12F4F6: _notmuch_message_add_term (message.cc:1204)
==8681== by 0x129BEF: _notmuch_database_link_message_to_parents (database.cc:2210)
==8681== by 0x129BEF: _notmuch_database_link_message (database.cc:2381)
==8681== by 0x129BEF: notmuch_database_add_message (database.cc:2531)
==8681== by 0x11AA8E: add_file (notmuch-new.c:264)
==8681== by 0x11AA8E: add_files (notmuch-new.c:599)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== Address 0x159280df is 127 bytes inside a block of size 131 free'd
==8681== at 0x4C2BDDB: free (vg_replace_malloc.c:530)
==8681== by 0x561486A: _talloc_free (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x533466C: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x5334A69: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x1256E0: parse_references(void*, char const*, _GHashTable*, char const*) (database.cc:655)
==8681== by 0x129BAA: _notmuch_database_link_message_to_parents (database.cc:2198)
==8681== by 0x129BAA: _notmuch_database_link_message (database.cc:2381)
==8681== by 0x129BAA: notmuch_database_add_message (database.cc:2531)
==8681== by 0x11AA8E: add_file (notmuch-new.c:264)
==8681== by 0x11AA8E: add_files (notmuch-new.c:599)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11B44C: notmuch_new_command (notmuch-new.c:1100)
==8681== Block was alloc'd at
==8681== at 0x4C2ABAF: malloc (vg_replace_malloc.c:299)
==8681== by 0x5617591: talloc_strndup (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x1255E4: _parse_message_id(void*, char const*, char const**) (database.cc:614)
==8681== by 0x1256BC: parse_references(void*, char const*, _GHashTable*, char const*) (database.cc:652)
==8681== by 0x129BAA: _notmuch_database_link_message_to_parents (database.cc:2198)
==8681== by 0x129BAA: _notmuch_database_link_message (database.cc:2381)
==8681== by 0x129BAA: notmuch_database_add_message (database.cc:2531)
==8681== by 0x11AA8E: add_file (notmuch-new.c:264)
==8681== by 0x11AA8E: add_files (notmuch-new.c:599)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11A5A3: add_files (notmuch-new.c:483)
==8681== by 0x11B44C: notmuch_new_command (notmuch-new.c:1100)
==8681== by 0x114669: main (notmuch.c:456)
==8681==
==8681==
==8681== HEAP SUMMARY:
==8681== in use at exit: 661,584 bytes in 820 blocks
==8681== total heap usage: 132,610,951 allocs, 132,610,131 frees, 65,439,596,062 bytes allocated
==8681==
==8681== 16 bytes in 1 blocks are possibly lost in loss record 237 of 591
==8681== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==8681== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D6410: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DAF60: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50BA2AB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B4147: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681== by 0xFFF000552: ???
==8681==
==8681== 16 bytes in 1 blocks are possibly lost in loss record 238 of 591
==8681== at 0x4C2AADF: malloc (vg_replace_malloc.c:298)
==8681== by 0x4C2CE5F: realloc (vg_replace_malloc.c:785)
==8681== by 0x534BEC7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D62E0: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DAF60: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50BA2AB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B4147: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681==
==8681== 16 bytes in 1 blocks are possibly lost in loss record 239 of 591
==8681== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==8681== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D6410: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DAF60: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50BA311: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B4147: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681== by 0xFFF000552: ???
==8681==
==8681== 16 bytes in 1 blocks are possibly lost in loss record 240 of 591
==8681== at 0x4C2AADF: malloc (vg_replace_malloc.c:298)
==8681== by 0x4C2CE5F: realloc (vg_replace_malloc.c:785)
==8681== by 0x534BEC7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D62E0: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DAF60: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50BA311: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B4147: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681==
==8681== 16 bytes in 1 blocks are possibly lost in loss record 241 of 591
==8681== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==8681== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D6410: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DAF60: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50C39D4: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B4151: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681== by 0xFFF000552: ???
==8681==
==8681== 16 bytes in 1 blocks are possibly lost in loss record 242 of 591
==8681== at 0x4C2AADF: malloc (vg_replace_malloc.c:298)
==8681== by 0x4C2CE5F: realloc (vg_replace_malloc.c:785)
==8681== by 0x534BEC7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D62E0: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DAF60: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50C39D4: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B4151: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681==
==8681== 16 bytes in 1 blocks are possibly lost in loss record 243 of 591
==8681== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==8681== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D6410: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DAF60: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50BEB0B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B4156: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681== by 0xFFF000552: ???
==8681==
==8681== 16 bytes in 1 blocks are possibly lost in loss record 244 of 591
==8681== at 0x4C2AADF: malloc (vg_replace_malloc.c:298)
==8681== by 0x4C2CE5F: realloc (vg_replace_malloc.c:785)
==8681== by 0x534BEC7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D62E0: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DAF60: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50BEB0B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B4156: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681==
==8681== 96 bytes in 1 blocks are possibly lost in loss record 473 of 591
==8681== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==8681== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D5919: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50D5A03: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B407A: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681== by 0xFFF000552: ???
==8681==
==8681== 96 bytes in 1 blocks are possibly lost in loss record 474 of 591
==8681== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==8681== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D5919: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50D5A03: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DAF52: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50BA2AB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B4147: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681==
==8681== 96 bytes in 1 blocks are possibly lost in loss record 475 of 591
==8681== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==8681== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D5919: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50D5A03: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DAF52: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50BA311: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B4147: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681==
==8681== 96 bytes in 1 blocks are possibly lost in loss record 476 of 591
==8681== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==8681== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D5919: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50D5A03: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DAF52: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50C39D4: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B4151: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681==
==8681== 96 bytes in 1 blocks are possibly lost in loss record 477 of 591
==8681== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==8681== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D5919: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50D5A03: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DAF52: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50BEB0B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B4156: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681==
==8681== 96 bytes in 1 blocks are definitely lost in loss record 478 of 591
==8681== at 0x4C2ABAF: malloc (vg_replace_malloc.c:299)
==8681== by 0x561A6F2: talloc_enable_null_tracking (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.8)
==8681== by 0x1145CE: main (notmuch.c:417)
==8681==
==8681== 120 bytes in 1 blocks are possibly lost in loss record 518 of 591
==8681== at 0x4C2CDCF: realloc (vg_replace_malloc.c:785)
==8681== by 0x534BEC7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D5897: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DB29C: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x4E78B2D: internet_address_list_get_type (in /usr/lib/x86_64-linux-gnu/libgmime-2.6.so.0.621.0)
==8681== by 0x4E4B206: g_mime_init (in /usr/lib/x86_64-linux-gnu/libgmime-2.6.so.0.621.0)
==8681== by 0x1145EB: main (notmuch.c:421)
==8681==
==8681== 132 bytes in 1 blocks are possibly lost in loss record 522 of 591
==8681== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==8681== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D6D3F: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DAFB0: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50BA2AB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B4147: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681== by 0xFFF000552: ???
==8681==
==8681== 132 bytes in 1 blocks are possibly lost in loss record 523 of 591
==8681== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==8681== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D6D3F: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DAFB0: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50BA311: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B4147: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681== by 0xFFF000552: ???
==8681==
==8681== 148 bytes in 1 blocks are possibly lost in loss record 535 of 591
==8681== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==8681== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D6B02: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DAFB0: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50C39D4: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B4151: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681== by 0xFFF000552: ???
==8681==
==8681== 148 bytes in 1 blocks are possibly lost in loss record 536 of 591
==8681== at 0x4C2CBC5: calloc (vg_replace_malloc.c:711)
==8681== by 0x534BE60: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D6B02: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DAFB0: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50BEB0B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B4156: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681== by 0xFFF000552: ???
==8681==
==8681== 184 bytes in 1 blocks are possibly lost in loss record 542 of 591
==8681== at 0x4C2CDCF: realloc (vg_replace_malloc.c:785)
==8681== by 0x534BEC7: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
==8681== by 0x50D5897: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50DB29C: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50C5659: g_param_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50C7983: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x50B415B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.2)
==8681== by 0x400F5D9: call_init.part.0 (dl-init.c:72)
==8681== by 0x400F6EA: call_init (dl-init.c:30)
==8681== by 0x400F6EA: _dl_init (dl-init.c:120)
==8681== by 0x4000CD9: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==8681== by 0x1: ???
==8681== by 0xFFF00054A: ???
==8681==
==8681== LEAK SUMMARY:
==8681== definitely lost: 96 bytes in 1 blocks
==8681== indirectly lost: 0 bytes in 0 blocks
==8681== possibly lost: 1,472 bytes in 19 blocks
==8681== still reachable: 659,936 bytes in 799 blocks
==8681== of which reachable via heuristic:
==8681== newarray : 1,536 bytes in 16 blocks
==8681== suppressed: 0 bytes in 0 blocks
==8681== Reachable blocks (those to which a pointer was found) are not shown.
==8681== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==8681==
==8681== For counts of detected and suppressed errors, rerun with: -v
==8681== ERROR SUMMARY: 240 errors from 24 contexts (suppressed: 0 from 0)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: read after free in notmuch new
2017-02-19 15:29 ` David Bremner
@ 2017-02-21 2:46 ` David Bremner
2017-02-21 20:25 ` Tomi Ollila
2017-03-01 1:49 ` read after free in notmuch new David Bremner
1 sibling, 1 reply; 10+ messages in thread
From: David Bremner @ 2017-02-21 2:46 UTC (permalink / raw)
To: notmuch
David Bremner <david@tethera.net> writes:
> David Bremner <david@tethera.net> writes:
>
>> I haven't had a chance to really track this down, but it seems there is
>> a memory error in notmuch new (or a maybe false positive from valgrind).
>>
>> Attached is the log from running "make memory-test OPTIONS=--medium" on
>> current git master (0e037c34).
>>
>> It looks like we talloc the message_id string with the message object as
>> parent, but it somehow outlives the message object.
>
> Sorry, that had a few commits beyond master.
>
> master (08343d3d) gives essentially the same log.
>
The log says the relevent piece of memory was freed at line 655 of database.cc, which
is the g_hash_table_insert in the code
ref = _parse_message_id (ctx, refs, &refs);
if (ref && strcmp (ref, message_id)) {
g_hash_table_insert (hash, ref, NULL);
last_ref = ref;
}
According to the docs for g_hash_table_insert
If the key already exists in the GHashTable its current value is
replaced with the new value. If you supplied a value_destroy_func
when creating the GHashTable, the old value is freed using that
function. If you supplied a key_destroy_func when creating the
GHashTable, the passed key is freed using that function.
Since we do pass a key_destroy_func, it seems we are being naughty by
returning last_ref just below.
I'm not sure about the best solution; one option would be to drop the
key_destroy_func and manually talloc_free ref, something like
char *ref=NULL;
while (*refs) {
if (ref) talloc_free (ref);
ref = _parse_message_id (ctx, refs, &refs);
if (ref && strcmp (ref, message_id)) {
g_hash_table_insert (hash, ref, NULL);
last_ref = ref;
}
}
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: read after free in notmuch new
2017-02-21 2:46 ` David Bremner
@ 2017-02-21 20:25 ` Tomi Ollila
2017-02-22 1:05 ` David Bremner
0 siblings, 1 reply; 10+ messages in thread
From: Tomi Ollila @ 2017-02-21 20:25 UTC (permalink / raw)
To: David Bremner, notmuch
On Tue, Feb 21 2017, David Bremner <david@tethera.net> wrote:
> David Bremner <david@tethera.net> writes:
>
>> David Bremner <david@tethera.net> writes:
>>
>>> I haven't had a chance to really track this down, but it seems there is
>>> a memory error in notmuch new (or a maybe false positive from valgrind).
>>>
>>> Attached is the log from running "make memory-test OPTIONS=--medium" on
>>> current git master (0e037c34).
>>>
>>> It looks like we talloc the message_id string with the message object as
>>> parent, but it somehow outlives the message object.
>>
>> Sorry, that had a few commits beyond master.
>>
>> master (08343d3d) gives essentially the same log.
>>
>
> The log says the relevent piece of memory was freed at line 655 of database.cc, which
> is the g_hash_table_insert in the code
>
> ref = _parse_message_id (ctx, refs, &refs);
>
> if (ref && strcmp (ref, message_id)) {
> g_hash_table_insert (hash, ref, NULL);
> last_ref = ref;
> }
>
>
> According to the docs for g_hash_table_insert
>
> If the key already exists in the GHashTable its current value is
> replaced with the new value. If you supplied a value_destroy_func
> when creating the GHashTable, the old value is freed using that
> function. If you supplied a key_destroy_func when creating the
> GHashTable, the passed key is freed using that function.
>
> Since we do pass a key_destroy_func, it seems we are being naughty by
> returning last_ref just below.
To me it looks like replacing g_hash_table_insert() with
g_hash_table_replace() would do the trick.
(or even g_hash_table_add()!)
One has to read the documentation a bit (and compare the docstrings of
these 2 functions to guess the missing pieces) to get some understanding to
this...
Tomi
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: read after free in notmuch new
2017-02-21 20:25 ` Tomi Ollila
@ 2017-02-22 1:05 ` David Bremner
2017-02-22 1:44 ` David Bremner
0 siblings, 1 reply; 10+ messages in thread
From: David Bremner @ 2017-02-22 1:05 UTC (permalink / raw)
To: Tomi Ollila, notmuch
Tomi Ollila <tomi.ollila@iki.fi> writes:
> To me it looks like replacing g_hash_table_insert() with
> g_hash_table_replace() would do the trick.
>
> (or even g_hash_table_add()!)
>
> One has to read the documentation a bit (and compare the docstrings of
> these 2 functions to guess the missing pieces) to get some understanding to
> this...
>
Hi Tomi;
Thanks for the suggestion. Unfortunately in my experiments it just
shifts the invalid memory access to a different piece of memory. I think
the problem is that a pointer to the previous copy of that key also
leaked a reference via last_ref, so when we kill that via
g_hash_table_replace it causes the same problem.
d
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: read after free in notmuch new
2017-02-22 1:05 ` David Bremner
@ 2017-02-22 1:44 ` David Bremner
2017-02-22 10:32 ` [PATCH] lib: fix g_hash_table related read-after-free bug David Bremner
0 siblings, 1 reply; 10+ messages in thread
From: David Bremner @ 2017-02-22 1:44 UTC (permalink / raw)
To: Tomi Ollila, notmuch
David Bremner <david@tethera.net> writes:
> Tomi Ollila <tomi.ollila@iki.fi> writes:
>
>> To me it looks like replacing g_hash_table_insert() with
>> g_hash_table_replace() would do the trick.
>>
>> (or even g_hash_table_add()!)
>>
>> One has to read the documentation a bit (and compare the docstrings of
>> these 2 functions to guess the missing pieces) to get some understanding to
>> this...
>>
>
> Hi Tomi;
>
> Thanks for the suggestion. Unfortunately in my experiments it just
> shifts the invalid memory access to a different piece of memory. I think
> the problem is that a pointer to the previous copy of that key also
> leaked a reference via last_ref, so when we kill that via
> g_hash_table_replace it causes the same problem.
>
Thinking a bit more about it, at least in this case the pointer that was
just inserted remains valid after insertion, and can be
talloc_strdup'ed, i.e.
diff --git a/lib/database.cc b/lib/database.cc
index f0bfe566..eddb780c 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -652,7 +652,7 @@ parse_references (void *ctx,
ref = _parse_message_id (ctx, refs, &refs);
if (ref && strcmp (ref, message_id)) {
- g_hash_table_insert (hash, ref, NULL);
+ g_hash_table_add (hash, ref);
last_ref = ref;
}
}
@@ -661,7 +661,7 @@ parse_references (void *ctx,
* reference to the database. We should avoid making a message
* its own parent, thus the above check.
*/
- return last_ref;
+ return talloc_strdup(ctx, last_ref);
}
notmuch_status_t
I'll let valgrind chew on that for a bit and see what it says.
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH] lib: fix g_hash_table related read-after-free bug
2017-02-22 1:44 ` David Bremner
@ 2017-02-22 10:32 ` David Bremner
2017-02-22 11:25 ` Tomi Ollila
2017-02-23 13:12 ` David Bremner
0 siblings, 2 replies; 10+ messages in thread
From: David Bremner @ 2017-02-22 10:32 UTC (permalink / raw)
To: David Bremner, Tomi Ollila, notmuch
The two g_hash_table functions (insert, add) have different behaviour
with respect to existing keys. g_hash_table_insert frees the new key,
while g_hash_table_add (which is really g_hash_table_replace in
disguise) frees the existing key. With this change 'ref' is live until
the end of the function (assuming single-threaded access to
'hash'). We can't guarantee it will continue to be live in the
future (i.e. there may be a future key duplication) so we copy it with
the allocation context passed to parse_references (in practice this is
the notmuch_message_t object whose parents we are finding).
Thanks to Tomi for the simpler approach to the problem based on
reading the fine glib manual.
---
this at least passes the --medium memory test. I'll run the full one
but it probably needs a day or so to complete.
lib/database.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index f0bfe566..eddb780c 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -652,7 +652,7 @@ parse_references (void *ctx,
ref = _parse_message_id (ctx, refs, &refs);
if (ref && strcmp (ref, message_id)) {
- g_hash_table_insert (hash, ref, NULL);
+ g_hash_table_add (hash, ref);
last_ref = ref;
}
}
@@ -661,7 +661,7 @@ parse_references (void *ctx,
* reference to the database. We should avoid making a message
* its own parent, thus the above check.
*/
- return last_ref;
+ return talloc_strdup(ctx, last_ref);
}
notmuch_status_t
--
2.11.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH] lib: fix g_hash_table related read-after-free bug
2017-02-22 10:32 ` [PATCH] lib: fix g_hash_table related read-after-free bug David Bremner
@ 2017-02-22 11:25 ` Tomi Ollila
2017-02-23 13:12 ` David Bremner
1 sibling, 0 replies; 10+ messages in thread
From: Tomi Ollila @ 2017-02-22 11:25 UTC (permalink / raw)
To: David Bremner, notmuch
On Wed, Feb 22 2017, David Bremner <david@tethera.net> wrote:
> The two g_hash_table functions (insert, add) have different behaviour
> with respect to existing keys. g_hash_table_insert frees the new key,
> while g_hash_table_add (which is really g_hash_table_replace in
> disguise) frees the existing key. With this change 'ref' is live until
> the end of the function (assuming single-threaded access to
> 'hash'). We can't guarantee it will continue to be live in the
> future (i.e. there may be a future key duplication) so we copy it with
> the allocation context passed to parse_references (in practice this is
> the notmuch_message_t object whose parents we are finding).
>
> Thanks to Tomi for the simpler approach to the problem based on
> reading the fine glib manual.
> ---
Great work! LGTM.
Tomi
PS: tried to look whethet there were talloc_ref() (the glib way)...
there is "refcounting" but a bit different (unsuitable) way...
>
> this at least passes the --medium memory test. I'll run the full one
> but it probably needs a day or so to complete.
>
> lib/database.cc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/database.cc b/lib/database.cc
> index f0bfe566..eddb780c 100644
> --- a/lib/database.cc
> +++ b/lib/database.cc
> @@ -652,7 +652,7 @@ parse_references (void *ctx,
> ref = _parse_message_id (ctx, refs, &refs);
>
> if (ref && strcmp (ref, message_id)) {
> - g_hash_table_insert (hash, ref, NULL);
> + g_hash_table_add (hash, ref);
> last_ref = ref;
> }
> }
> @@ -661,7 +661,7 @@ parse_references (void *ctx,
> * reference to the database. We should avoid making a message
> * its own parent, thus the above check.
> */
> - return last_ref;
> + return talloc_strdup(ctx, last_ref);
> }
>
> notmuch_status_t
> --
> 2.11.0
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] lib: fix g_hash_table related read-after-free bug
2017-02-22 10:32 ` [PATCH] lib: fix g_hash_table related read-after-free bug David Bremner
2017-02-22 11:25 ` Tomi Ollila
@ 2017-02-23 13:12 ` David Bremner
1 sibling, 0 replies; 10+ messages in thread
From: David Bremner @ 2017-02-23 13:12 UTC (permalink / raw)
To: Tomi Ollila, notmuch
David Bremner <david@tethera.net> writes:
> The two g_hash_table functions (insert, add) have different behaviour
> with respect to existing keys. g_hash_table_insert frees the new key,
> while g_hash_table_add (which is really g_hash_table_replace in
> disguise) frees the existing key. With this change 'ref' is live until
> the end of the function (assuming single-threaded access to
> 'hash'). We can't guarantee it will continue to be live in the
> future (i.e. there may be a future key duplication) so we copy it with
> the allocation context passed to parse_references (in practice this is
> the notmuch_message_t object whose parents we are finding).
>
> Thanks to Tomi for the simpler approach to the problem based on
> reading the fine glib manual.
pushed to master and release
d
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: read after free in notmuch new
2017-02-19 15:29 ` David Bremner
2017-02-21 2:46 ` David Bremner
@ 2017-03-01 1:49 ` David Bremner
1 sibling, 0 replies; 10+ messages in thread
From: David Bremner @ 2017-03-01 1:49 UTC (permalink / raw)
To: notmuch
David Bremner <david@tethera.net> writes:
> David Bremner <david@tethera.net> writes:
>
>> I haven't had a chance to really track this down, but it seems there is
>> a memory error in notmuch new (or a maybe false positive from valgrind).
>>
>> Attached is the log from running "make memory-test OPTIONS=--medium" on
>> current git master (0e037c34).
>>
>> It looks like we talloc the message_id string with the message object as
>> parent, but it somehow outlives the message object.
>
> Sorry, that had a few commits beyond master.
>
> master (08343d3d) gives essentially the same log.
>
This should be fixed as of commit
4e649d000b9d3764aea98cb0e1120947d7f76f3d
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-03-01 1:49 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-19 14:15 read after free in notmuch new David Bremner
2017-02-19 15:29 ` David Bremner
2017-02-21 2:46 ` David Bremner
2017-02-21 20:25 ` Tomi Ollila
2017-02-22 1:05 ` David Bremner
2017-02-22 1:44 ` David Bremner
2017-02-22 10:32 ` [PATCH] lib: fix g_hash_table related read-after-free bug David Bremner
2017-02-22 11:25 ` Tomi Ollila
2017-02-23 13:12 ` David Bremner
2017-03-01 1:49 ` read after free in notmuch new David Bremner
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).