[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnupg-devel
Subject:    Re: Unpredictable GPGME bug
From:       Marcus Brinkmann <Marcus.Brinkmann () ruhr-uni-bochum ! de>
Date:       2002-05-27 11:54:49
[Download RAW message or body]

On Mon, May 27, 2002 at 05:12:24AM -0500, Robert J. Hansen wrote:
> Looks like there might be a bug in GPGME (I know, pre-1.0 software with 
> bugs--what's the world coming to?).  My C++ bindings for GPGME attempt to 
> grab all sorts of string data for a given key, and sometimes it will be 
> able to grab a string representation of the algorithm type and other times 
> it'll segfault.  The offending snippet of code looks like:
> 
> GpgmeKey _key;
> std::string _algo;
> 
> _algo = gpgme_key_get_string_attr(_key, GPGME_ATTR_ALGO, NULL, 0);
> 
> ... Maybe one time in ten, that line of code will segfault.  

What do you mean?  one out of ten times you run this on the same key, or for
one out of ten keys?

Let's look at the code:
    case GPGME_ATTR_ALGO:
      for (k = &key->keys; k && idx; k=k->next, idx--)
        ;
      if (k)
        val = pkalgo_to_string (k->key_algo);
      break;

So, if _key is really a key (and not NULL itself), which contains at least
one subkey (key->keys)), then this can not return NULL, because
pkalgo_to_string doesn't return NULL.

You could let it crash in gdb and check what the key and key->keys look
like in the case it is failing.

> gpgme_key_get_string_attr apparently returns a NULL pointer, and trying to 
> make a C++ std::string out of a NULL pointer is an instant segfault.
> 
> This has happened for other string quantities, such as usernames, etc.  
> For now, my solution is to assign the result of g_k_g_s_a() to a const 
> char*, test the const char* against NULL, and then assign either the const 
> char* to _algo or else assign "Unassigned" to _algo.  However, this is 
> fairly inelegant given that we could just fix the GPGME code.  :)

Most properties are optional and can return NULL, so you must catch the NULL
case anyway.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
[prev in list] [next in list] [prev in thread] [next in thread]