notmuch setup: segfault in prompt macro

notmuch setup: segfault in prompt macro

[Mike Kelly]

Hi,

While testing Michal Sojka's latest patches, I tried running notmuch
setup, only to find that it segfaults. It does this on a vanilla
branch, too, though:

  #0  0x286e3ba5 in memcpy () from /lib/libc.so.7
  No symbol table info available.
  #1  0x28620f6b in getline () from /lib/libc.so.7
  No symbol table info available.
  #2  0x2862113b in getdelim () from /lib/libc.so.7
  No symbol table info available.
  #3  0x28620f03 in getline () from /lib/libc.so.7
  No symbol table info available.
  #4  0x08053c1c in notmuch_setup_command (ctx=0x288090a0, argc=0, argv=0xbfbfe320) at notmuch-setup.c:121
          response = 0x0
          response_size = 671820800
          config = (notmuch_config_t *) 0x2881e490
          old_other_emails = (char **) 0xbfbfe324
          old_other_emails_len = 0
          other_emails = (GPtrArray *) 0xbfbfe2d8
          i = 671549033
          is_new = 0
          new_tags = (const char **) 0x280ae000
          new_tags_len = 3217023608
  #5  0x0804ec46 in main (argc=2, argv=0xbfbfe318) at notmuch.c:499
          local = (void *) 0x288090a0
          command = (command_t *) 0x806fd00
          i = 0

-- 
Mike Kelly

Re: notmuch setup: segfault in prompt macro

[David Bremner]

On Wed, 13 Oct 2010 09:43:40 -0400, Mike Kelly <pioto@pioto.org> wrote:
> Hi,
> 
> While testing Michal Sojka's latest patches, I tried running notmuch
> setup, only to find that it segfaults. It does this on a vanilla
> branch, too, though:
> 
>   #0  0x286e3ba5 in memcpy () from /lib/libc.so.7
>   No symbol table info available.

What environment is this where you have libc7 ?

d

Re: notmuch setup: segfault in prompt macro

[Mike Kelly]

(sorry, forgot to reply to list)

On Wed, 13 Oct 2010 14:26:56 -0300
David Bremner <bremner@unb.ca> wrote:

> On Wed, 13 Oct 2010 09:43:40 -0400, Mike Kelly <pioto@pioto.org>
> wrote:
> > Hi,
> > 
> > While testing Michal Sojka's latest patches, I tried running notmuch
> > setup, only to find that it segfaults. It does this on a vanilla
> > branch, too, though:
> > 
> >   #0  0x286e3ba5 in memcpy () from /lib/libc.so.7
> >   No symbol table info available.
> 
> What environment is this where you have libc7 ?

FreeBSD 8.0

-- 
Mike Kelly

[PATCH] notmuch-setup.c: Initialize getline(3) response_size to 0

[Mike Kelly]

This appears to be necessary on FreeBSD. If this isn't done, we get a
nasty segfault.

See: id:20101013094340.41580a2f@pioto.org
---
 notmuch-setup.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/notmuch-setup.c b/notmuch-setup.c
index 955deb7..0ed80ad 100644
--- a/notmuch-setup.c
+++ b/notmuch-setup.c
@@ -92,7 +92,7 @@ notmuch_setup_command (unused (void *ctx),
 		       unused (int argc), unused (char *argv[]))
 {
     char *response = NULL;
-    size_t response_size;
+    size_t response_size = 0;
     notmuch_config_t *config;
     char **old_other_emails;
     size_t old_other_emails_len;
-- 
1.7.2.3

Re: [PATCH] notmuch-setup.c: Initialize getline(3) response_size to 0

[Carl Worth]

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

On Thu, 14 Oct 2010 14:18:19 -0400, Mike Kelly <pioto@pioto.org> wrote:
> This appears to be necessary on FreeBSD. If this isn't done, we get a
> nasty segfault.

Thanks. I've pushed this out.

I didn't have that initialized originally, because the documentation I
have for getline on my Linux machine says explicitly:

       If *lineptr is NULL, then getline() will allocate a buffer for
       storing the line, which should be freed by the user program.  (In
       this case, the value in *n is ignored.)

But, oh well, it's easy enough to fix.

Thanks again for the patch.

-Carl

-- 
carl.d.worth@intel.com

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