Bug#807756: gnubg: fails to start. hangs using 100% of one cpu core

[Russ Allbery]

Control: reassign -1 libtasn1-6
Control: affects -1 gnubg

Julian Hughes <julianhughes at gmail.com> writes:

> Package: gnubg
> Version: 1.05.000-2
> Severity: grave
> Justification: renders package unusable

> when starting gnubg it uses 100% of one cpu core and then apparently
> hangs with no output and without starting the gui.

So, I'm not sure what's going on here, but it seems to be some sort of
weird bug in libgnutls/libtasn1.  gnubg is going into an infinite loop
before any gnubg code actually runs at all, during shared library
initialization.  This is the backtrace of the infinite loop:

#0  memcpy (__dest=0x83e070, __src=0x7fffea09a46e, __len=6)
    at /usr/include/x86_64-linux-gnu/bits/string3.h:53
#1  0x00007fffe838eee2 in strcpy (__src=0x7fffea09a46e "PKIX1", 
    __dest=0x83e070 "") at /usr/include/x86_64-linux-gnu/bits/string3.h:104
#2  _asn1_str_cpy (dest=dest at entry=0x83e070 "", 
    dest_tot_size=dest_tot_size at entry=65, src=0x7fffea09a46e "PKIX1")
    at gstr.c:59
#3  0x00007fffe838f43b in _asn1_set_name (node=node at entry=0x83e070, 
    name=<optimized out>) at parser_aux.c:379
#4  0x00007fffe8390489 in asn1_array2tree (array=<optimized out>, 
    definitions=definitions at entry=0x7fffea2d0f20 <_gnutls_pkix1_asn>, 
    errorDescription=errorDescription at entry=0x0) at structure.c:199
#5  0x00007fffe9ff4edd in gnutls_global_init () at gnutls_global.c:257
#6  0x00007fffe9fd6ed9 in lib_init () at gnutls_global.c:434
#7  0x00007ffff7dea26a in call_init (l=<optimized out>, argc=argc at entry=1, 
    argv=argv at entry=0x7fffffffe098, env=env at entry=0x7fffffffe0a8)
    at dl-init.c:72
#8  0x00007ffff7dea37b in call_init (env=0x7fffffffe0a8, argv=0x7fffffffe098, 
    argc=1, l=<optimized out>) at dl-init.c:30
#9  _dl_init (main_map=0x7ffff7ffe188, argc=1, argv=0x7fffffffe098, 
    env=0x7fffffffe0a8) at dl-init.c:120
#10 0x00007ffff7ddbcca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#11 0x0000000000000001 in ?? ()
#12 0x00007fffffffe42a in ?? ()
#13 0x0000000000000000 in ?? ()

So for some reason it's going into an infinite loop inside a memcpy of
only six bytes?  I'm really boggled by this behavior, but I'm not seeing
the mechanism where gnubg could cause this.

Reassigning to the libtasn1-6 package for help.  Maybe they have some idea
what's going on here.

libtasn1-6 maintainers, this is 100% reproducible by just installing gnubg
from unstable and running gnubg.  To get the above backtrace, I just
grabbed the source package, did apt-get build-dep gnubg, debian/rules
build, and installed the debugging packages for libgnutls and libtasn1.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>