RT RT/krbdev.mit.edu: Ticket #7860 libdb2 tests hang Signed in as guest.
[Logout]

[Home] [Search] [Configuration]

[Display] [History] [Basics] [Dates] [People] [Links] [Jumbo]

 
 

 The Basics  
Id
7860
Status
resolved
Worked
0 min
Priority
0/0
Queue
krb5
 

 Keyword Selections  
Component
Tags
Version_reported
Version_Fixed
  • 1.12.2
Target_Version
  • 1.12.2
 

 Relationships  
Depends on:
Depended on by:
Parents:
Children:

Refers to:
Referred to by:
 
 Dates  
Created: Fri Feb 7 15:54:12 2014
Starts: Not set
Started: Tue Feb 11 23:17:11 2014
Last Contact: Tue Jul 22 14:35:57 2014
Due: Not set
Updated: Wed Dec 16 18:03:01 2015 by tlyu
 

 People  
Owner
 ghudson
Requestors
 pierre.labastie@neuf.fr
Cc
 
AdminCc
 
 

 More about Pierre Labastie  
Comments about this user:
No comment entered about this user
This user's 25 highest priority tickets:
 

History   Display mode: [Brief headers] [Full headers]
      Fri Feb  7 15:54:12 2014  pierre.labastie@neuf.fr - Ticket created    
     
Date: Fri, 07 Feb 2014 14:10:49 +0100
From: Pierre Labastie <pierre.labastie@neuf.fr>
To: krb5-bugs@mit.edu
Subject: libdb2 tests hang

 

     
Hi,

While updating the MIT Kerberos page for BLFS
(www.linuxfromscratch.org/blfs), I found that "make check" generated a
few errors.

The first (and most important) one is:
----------
make: Entering directory
`/sources/mitkrb/krb5-1.11.4/src/plugins/kdb/db2/libdb2/test'
gcc -L.. -L../../../../../lib -Wl,--enable-new-dtags -Wl,-rpath
-Wl,/usr/lib -g -O2  -o dbtest dbtest.o  -ldb
LD_LIBRARY_PATH=`echo -L.. -L../../../../../lib | sed -e "s/-L//g" -e
"s/ /:/g"`; export LD_LIBRARY_PATH;  srcdir=. TMPDIR=.  /bin/sh ./run.test
Test 1: btree, hash: small key, small data pairs
test1: type btree: failed
make: Leaving directory
`/sources/mitkrb/krb5-1.11.4/src/plugins/kdb/db2/libdb2/test'
----------

I found the reason for that: the dictionary used is the one installed
for cracklib, which contains shell meta character and spaces. Those are
interpreted by the "for i in `cat $TMP1`" in run.test, so that what is
sent to the database is not what was originally in the file. Changing
the line:
"sed -e '/^$/d' < $DICT | cat -v | sed -e ${1}q"
to:
"sed -e '/[[:space:]*?/d' -e '/^$/d' < $DICT | cat -v | sed -e ${1}q"
allows the first test to pass.

But then, the second test hangs and has to be interrupted:
-------------
make: Entering directory
`/sources/mitkrb/krb5-1.11.4/src/plugins/kdb/db2/libdb2/test'
LD_LIBRARY_PATH=`echo -L.. -L../../../../../lib | sed -e "s/-L//g" -e
"s/ /:/g"`; export LD_LIBRARY_PATH;  srcdir=. TMPDIR=.  /bin/sh ./run.test
Test 1: btree, hash: small key, small data pairs
Test 1: recno: small key, small data pairs
Test 2: btree, hash: small key, medium data pairs
Test 2: recno: small key, medium data pairs^C
------------

I tried to debug this by putting some printf at various places in the
code, I found that:
- the call to dbp->close(dbp) does not return (in dbtest)
- in rec_close.c, the instructions:
                 while (status == RET_SUCCESS) {
                         iov[0].iov_base = data.data;
                         iov[0].iov_len = data.size;
                         if (writev(t->bt_rfd, iov, 2) != data.size + 1)
                                 return (RET_ERROR);
                         status = (dbp->seq)(dbp, &key, &data, R_NEXT);
                 }
enter an infinite loop, but the file __dbtest keeps the same size.

Going farther without assistance is too hard... I would need at least
some pointers to docs about the structure of the database.

System information. The box is a virtual machine under qemu:
> uname -a
Linux virtuallfs 3.10.10-lfs-1 #1 SMP Tue Feb 4 17:16:25 CET 2014 x86_64
GNU/Linux
> gcc --version
gcc (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The build is as follows:
cd src &&
sed -e "s@python2.5/Python.h@& python2.7/Python.h@g" \
     -e "s@-lpython2.5]@&,\n
AC_CHECK_LIB(python2.7,main,[PYTHON_LIB=-lpython2.7])@g" \
     -i configure.in &&
sed -e "s@interp->result@Tcl_GetStringResult(interp)@g" \
     -i kadmin/testing/util/tcl_kadm5.c &&
autoconf &&
./configure CPPFLAGS="-I/usr/include/et -I/usr/include/ss" \
             --prefix=/usr                                  \
             --sysconfdir=/etc                              \
             --localstatedir=/var/lib                       \
             --with-system-et                               \
             --with-system-ss                               \
             --enable-dns-for-realm &&
make

There are no krb5 libraries on the system (first install). The same
behavior is observed for both versions 1.11.4 et 1.12.1 (1.12.1 is built
without the CPPFLAGS).

Regards
Pierre
NB : the other error is a minor defect in the krb testsuite of
"tests/dejagnu". I can send another report on request.



Download (untitled) 3.7k
     
 
Download (untitled) 7.6k
      Mon Feb 10 12:46:02 2014  ghudson - Comments added    
     
I asked Pierre for the dictionary file he was using; it is at this link:

  http://downloads.sourceforge.net/cracklib/cracklib-words-20080507.gz

That part of the problem is pretty easy to resolve; either filter the
dictionary file for alphabetical characters only, or stop using the
system dictionary and always use the built-in word list
(plugins/kdb/db2/libdb2/test/dictionary).

In his response, Pierre also reported that he gets the test2 hang using
the built-in word list.  I cannot reproduce this.  Since the hang occurs
in the recno code, it is not particularly troubling from a Kerberos
perspective since the recno format isn't used for Kerberos databases.
But of course it is still problematic for our test suite to hang in some
environments, so we should figure out what is going on if we can.


Download (untitled) 813b
      Tue Feb 11 23:17:11 2014  ghudson - Given to ghudson    
      Tue Feb 11 23:17:11 2014  ghudson - Status changed from new to open    
      Tue Feb 11 23:17:11 2014  ghudson - Correspondence added    
     
From: ghudson@mit.edu
Subject: git commit


Don't use system dictionary files for DB2 tests

The system dictionary may contain entries with punctuation, which can
confuse the shell.  It's more predictable to always use the word list
from the source tree.

https://github.com/krb5/krb5/commit/d21a86e47a7cda29225013e08d060095b94b2ee7
Author: Greg Hudson <ghudson@mit.edu>
Commit: d21a86e47a7cda29225013e08d060095b94b2ee7
Branch: master
 src/plugins/kdb/db2/libdb2/test/run.test |    8 --------
 1 files changed, 0 insertions(+), 8 deletions(-)


Download (untitled) 500b
      Wed Feb 12 08:14:44 2014  pierre.labastie@neuf.fr - Comments added    
     
Date: Wed, 12 Feb 2014 14:11:21 +0100
From: Pierre Labastie <pierre.labastie@neuf.fr>
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #7860] libdb2 hanging on regular distribution
RT-Send-Cc: 

Not sure I am sending to the right place, sorry, I am not sure I
understand this bug system...

I have reproduced the hanging with a Debian distribution (jessie/sid) on
a real machine:

$ uname -a
Linux xxxx 3.12-1-amd64 #1 SMP Debian 3.12.9-1 (2014-02-01) x86_64 GNU/Linux

$ less /etc/os-release
PRETTY_NAME="Debian GNU/Linux jessie/sid"
NAME="Debian GNU/Linux"
ID=debian
ANSI_COLOR="1;31"
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support/"
BUG_REPORT_URL="http://bugs.debian.org/"

After applying the patch to avoid using system dictionaries, I run "make
check", from the source dictionary and the tests stopped at the same point:
making check in plugins/kdb/db2/libdb2/recno...
make[3]: Entering directory
`/sources/mitkrb/krb5-1.12.1/src/plugins/kdb/db2/libdb2/recno'
make[3]: Leaving directory
`/sources/mitkrb/krb5-1.12.1/src/plugins/kdb/db2/libdb2/recno'
making check in plugins/kdb/db2/libdb2/test...
make[3]: Entering directory
`/sources/mitkrb/krb5-1.12.1/src/plugins/kdb/db2/libdb2/test'
gcc -DHAVE_CONFIG_H  -I../../../../../include -I../../../../../include
-I. -I./../include -I../include -I./../mpool -I./../btree -I./../hash
-I./../db -DKRB5_DEPRECATED=1 -DKRB5_PRIVATE  -g -O2 -Wall -Wcast-align
-Wshadow -Wmissing-prototypes -Wno-format-zero-length -Woverflow
-Wstrict-overflow -Wmissing-format-attribute -Wmissing-prototypes
-Wreturn-type -Wmissing-braces -Wparentheses -Wswitch -Wunused-function
-Wunused-label -Wunused-variable -Wunused-value -Wunknown-pragmas
-Wsign-compare -Werror=uninitialized -Werror=pointer-arith
-Werror=declaration-after-statement
-Werror-implicit-function-declaration -pthread -c dbtest.c
gcc -L.. -L../../../../../lib -Wl,--enable-new-dtags -Wl,-rpath
-Wl,/usr/lib -g -O2  -o dbtest dbtest.o  -ldb -lkrb5support
LD_LIBRARY_PATH=`echo -L.. -L../../../../../lib | sed -e "s/-L//g" -e
"s/ /:/g"`; export LD_LIBRARY_PATH;  srcdir=. TMPDIR=.  /bin/sh ./run.test
Test 1: btree, hash: small key, small data pairs
Test 1: recno: small key, small data pairs
Test 2: btree, hash: small key, medium data pairs
Test 2: recno: small key, medium data pairs
(interrupted by hitting ^C)
after interruption, t1 contains lines of the form:
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
t2 contains records in the form:
p
k1
dabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
g
k1
and "cmp t1 t3" gives no errors.

Now, if do:
$ cd plugins/kdb/db2/libdb2/test
$ LD_LIBRARY_PATH=../../../../../lib:.. srcdir=. tmpdir=. bash run.test
test3
Test 3: hash: small key, big data pairs
(interrupted by hitting ^C after 2 hours)

The output of the line "Test ..." is immediate, then nothing happens. So
it looks like the problem is not only with recno.
After interruption, t1 contains binary data, t2 contains records in the
form:
p
k/bin/./netstat
D/bin/./netstat
g
k/bin/./netstat

and t3 is empty.

Regards,
Pierre



Download (untitled) 2.8k
      Fri Feb 14 15:33:36 2014  tlyu - Correspondence added    
     
To: rt@krbdev.MIT.EDU
Subject: Re: [krbdev.mit.edu #7860] libdb2 hanging on regular distribution
From: Tom Yu <tlyu@MIT.EDU>
Date: Fri, 14 Feb 2014 15:33:34 -0500
RT-Send-Cc: 

"Pierre Labastie via RT" <rt-comment@krbdev.mit.edu> writes:

> Not sure I am sending to the right place, sorry, I am not sure I
> understand this bug system...
>
> I have reproduced the hanging with a Debian distribution (jessie/sid) on
> a real machine:
>
> $ uname -a
> Linux xxxx 3.12-1-amd64 #1 SMP Debian 3.12.9-1 (2014-02-01) x86_64 GNU/Linux
>
> $ less /etc/os-release
> PRETTY_NAME="Debian GNU/Linux jessie/sid"
> NAME="Debian GNU/Linux"
> ID=debian
> ANSI_COLOR="1;31"
> HOME_URL="http://www.debian.org/"
> SUPPORT_URL="http://www.debian.org/support/"
> BUG_REPORT_URL="http://bugs.debian.org/"

Would this happen to be running on the same physical hardware as the
qemu VM you mentioned in your first message?  I think we have not seen
any other report of a problem similar to what you've described, and we
can't seem to reproduce it.  We don't have exactly the configuration
you describe, but we regularly run the tests on buildbot slaves on
x86 and x86_64 Ubuntu systems with no issues.

Getting strace output from the process when it is looping endlessly
around writev() might be helpful, if you have time to do that.
Otherwise, there is single stepping through the debugger, which can
get rather involved.


Download (untitled) 1.1k
      Sun Feb 16 14:47:15 2014  pierre.labastie@neuf.fr - Correspondence added    
     
Date: Sun, 16 Feb 2014 19:24:58 +0100
From: Pierre Labastie <pierre.labastie@neuf.fr>
To: krb5-bugs@mit.edu
Subject: Re: [krbdev.mit.edu #7860] libdb2 hanging on regular distribution
RT-Send-Cc: 

Le 14/02/2014 21:33, Tom Yu via RT a écrit :
> "Pierre Labastie via RT" <rt-comment@krbdev.mit.edu> writes:
>
>> Not sure I am sending to the right place, sorry, I am not sure I
>> understand this bug system...
>>
>> I have reproduced the hanging with a Debian distribution (jessie/sid) on
>> a real machine:
>>
>> $ uname -a
>> Linux xxxx 3.12-1-amd64 #1 SMP Debian 3.12.9-1 (2014-02-01) x86_64 GNU/Linux
>>
>> $ less /etc/os-release
>> PRETTY_NAME="Debian GNU/Linux jessie/sid"
>> NAME="Debian GNU/Linux"
>> ID=debian
>> ANSI_COLOR="1;31"
>> HOME_URL="http://www.debian.org/"
>> SUPPORT_URL="http://www.debian.org/support/"
>> BUG_REPORT_URL="http://bugs.debian.org/"
>
> Would this happen to be running on the same physical hardware as the
> qemu VM you mentioned in your first message?  I think we have not seen
> any other report of a problem similar to what you've described, and we
> can't seem to reproduce it.  We don't have exactly the configuration
> you describe, but we regularly run the tests on buildbot slaves on
> x86 and x86_64 Ubuntu systems with no issues.
>
> Getting strace output from the process when it is looping endlessly
> around writev() might be helpful, if you have time to do that.
> Otherwise, there is single stepping through the debugger, which can
> get rather involved.
>
Hi,

Same behavior on 2 different hardwares (one desktop with intel core i5, and
one workstation with dual intel Seon E5620, but same version of gcc on both.
I mention gcc, because it might be the cause of the trouble.

Putting more and more printf's, I narrowed the problem to mpool_get and
mpool_look (in mpool.c).
but then, I saw that adding one printf at some place just changed the behavior
(allowing test2 to pass). So I recompiled everything in:
plugins/kdb/db2/libdb2 with CFLAGS="-g -O1". Exactly, after make:
----------------------------------------
/sources/mitkrb/krb5-1.12.1/src$ cd plugins/kdb/db2/libdb2/
# next instruction needed for getting a big enough dictionary:
# the bundled one is too small for some tests
/sources/mitkrb/krb5-1.12.1/src/plugins/kdb/db2/libdb2$ sed \
'/\^\$/s@sed@LANG=C sed -e '\''/[^[:alpha:]]/d'\''@' -i test/run.test
/sources/mitkrb/krb5-1.12.1/src/plugins/kdb/db2/libdb2$ find . \
-name \*.c | xargs touch
/sources/mitkrb/krb5-1.12.1/src/plugins/kdb/db2/libdb2$ make CFLAGS="-g -O1"
making all in hash...
[...]
rm -f libdb.so
ln -s libdb.so.1.1 libdb.so
/sources/mitkrb/krb5-1.12.1/src/plugins/kdb/db2/libdb2$ make check
making check in hash...
[...]
Test 1: btree, hash: small key, small data pairs
Test 1: recno: small key, small data pairs
Test 2: btree, hash: small key, medium data pairs
Test 2: recno: small key, medium data pairs
Test 3: hash: small key, big data pairs
Test 3: btree: small key, big data pairs
    page size 512
    page size 16384
    page size 65536
Test 3: recno: big data pairs
    page size 512
    page size 16384
    page size 65536
Test 4: recno: random entries
Test 5: recno: reverse order entries
[...&c]
--------------------------------------
My gcc version is:
gcc (Debian 4.8.2-15) 4.8.2

Now, downgrading to gcc-4.7:
gcc (Debian 4.7.3-10) 4.7.3
All tests pass when running "make check" from the src directory, with default
CFLAGS...

I do not know whether you want to discuss with gcc developpers, or you prefer
that I send a bug report.

Regards
Pierre


Download (untitled) 3.2k
      Sun Feb 16 14:53:49 2014  ghudson - Correspondence added    
     
Thanks for the additional investigation.  I reproduce the test2 recno
hang using gcc 4.8.1 and -O2.  I will try to narrow it down.  It isn't
necessarily the compiler's fault; the code could be using an undefined
behavior.

(My regular dev machine uses gcc 4.6.3 and doesn't exhibit the problem at
any optimization level.  This is consistent with Pierre's findings.)


Download (untitled) 369b
      Sun Feb 16 19:52:22 2014  ghudson - Correspondence added    
     
Through a combination of debugging and googling, I believe the picture
is this:

* The optimizer in gcc 4.8 breaks the BSD CIRCLEQ macros by optimizing
out some of the conditionals.  This is either due to a strict aliasing
violation in the CIRCLEQ macros or a compiler bug; at this time I'm not
sure which.

* As a result, one of the mpool buckets becomes an infinite linked list,
causing mpool_look() to iterate forever.

* The response to gcc 4.8 in OpenBSD (and I think also FreeBSD) has been
to stop using the CIRCLEQ macros in favor of TAILQ.  It's not clear to
me yet whether the TAILQ macros are better or worse in terms of strict
aliasing violations, but gcc isn't known to have broken them yet.

* mpool structures are managed out of process memory, not mmapped
memory, so we are free to make any changes we want to them.  Converting
them from CIRCLEQ to TAILQ should be pretty easy if that turns out to be
the best answer.

The thread starting at
http://mail-index.netbsd.org/tech-kern/2013/11/20/msg016059.html
has the most in-depth discussion I was able to find.


Download (untitled) 1k
      Mon Feb 17 11:24:35 2014  ghudson - Correspondence added    
     
Please test this candidate fix:

https://github.com/greghudson/krb5/commits/circleq

It works for me with gcc 4.8.1 and -O2.  I still want to do more analysis
(probably with Tom's help) on whether CIRCLEQ and TAILQ violate strict
aliasing.  But we use TAILQ in several other parts of the code and don't
use CIRCLEQ anywhere else, so switching from CIRCLEQ to TAILQ is probably
a reasonable step regardless.


Download (untitled) 410b
      Mon Feb 17 15:41:14 2014  pierre.labastie@neuf.fr - Comments added    
     
Date: Mon, 17 Feb 2014 21:41:13 +0100
From: Pierre Labastie <pierre.labastie@neuf.fr>
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #7860] libdb2 tests hang
RT-Send-Cc: 

Le 17/02/2014 17:24, Greg Hudson via RT a écrit :
> Please test this candidate fix:
>
> https://github.com/greghudson/krb5/commits/circleq
>
> It works for me with gcc 4.8.1 and -O2.  I still want to do more analysis
> (probably with Tom's help) on whether CIRCLEQ and TAILQ violate strict
> aliasing.  But we use TAILQ in several other parts of the code and don't
> use CIRCLEQ anywhere else, so switching from CIRCLEQ to TAILQ is probably
> a reasonable step regardless.
> _______________________________________________
> krb5-bugs mailing list
> krb5-bugs@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krb5-bugs
>
Seems to work here too, with gcc-4.8.2.

BTW, some tests are not run, because the bundled dictionary is too small.

Pierre


Download (untitled) 753b
      Mon Feb 17 18:21:27 2014  ghudson - Correspondence added    
     
Please test this candidate fix:

https://github.com/greghudson/krb5/commits/circleq

It works for me with gcc 4.8.1 and -O2.  I still want to do more analysis
(probably with Tom's help) on whether CIRCLEQ and TAILQ violate strict
aliasing.  But we use TAILQ in several other parts of the code and don't
use CIRCLEQ anywhere else, so switching from CIRCLEQ to TAILQ is probably
a reasonable step regardless.


Download (untitled) 410b
      Mon Feb 17 20:39:29 2014  tlyu - Correspondence added    
     
To: rt@krbdev.MIT.EDU
Subject: Re: [krbdev.mit.edu #7860] libdb2 tests hang
From: Tom Yu <tlyu@MIT.EDU>
Date: Mon, 17 Feb 2014 20:39:27 -0500
RT-Send-Cc: 

"Greg Hudson via RT" <rt-comment@krbdev.mit.edu> writes:

> Through a combination of debugging and googling, I believe the picture
> is this:
>
> * The optimizer in gcc 4.8 breaks the BSD CIRCLEQ macros by optimizing
> out some of the conditionals.  This is either due to a strict aliasing
> violation in the CIRCLEQ macros or a compiler bug; at this time I'm not
> sure which.
>
> * As a result, one of the mpool buckets becomes an infinite linked list,
> causing mpool_look() to iterate forever.
>
> * The response to gcc 4.8 in OpenBSD (and I think also FreeBSD) has been
> to stop using the CIRCLEQ macros in favor of TAILQ.  It's not clear to
> me yet whether the TAILQ macros are better or worse in terms of strict
> aliasing violations, but gcc isn't known to have broken them yet.
>
> * mpool structures are managed out of process memory, not mmapped
> memory, so we are free to make any changes we want to them.  Converting
> them from CIRCLEQ to TAILQ should be pretty easy if that turns out to be
> the best answer.
>
> The thread starting at
> http://mail-index.netbsd.org/tech-kern/2013/11/20/msg016059.html
> has the most in-depth discussion I was able to find.

Thanks for tracking this down.  The CIRCLEQ macros have always made me
nervous with their weird (and probably undefined) casting.


Download (untitled) 1.2k
      Tue Feb 18 00:58:55 2014  ghudson - Comments added    
     
 

     
At this point I am pretty sure that this is actually a compiler bug,
because:

* I can't reproduce the problem with the head revision of gcc.

* With gcc 4.8.1, I was able to construct simplified test cases (like
the attached file) which clearly don't have strict aliasing violations,
and only take advantage of C99 6.3.2.3 paragraph 7.

I would speculate that in the attached test case, the gcc 4.8.1
optimizer sees list dereferenced before the conditional, and ent->prev
in the else clause, and erroneously concludes that if the two pointers
are the same, a strict aliasing violation must have occurred and the
behavior is undefined.  But since the dereference only happens when the
pointers are not equal, that deduction is invalid.

As for TAILQ, the macros in db-queue.h appear to be free of any aliasing
or type-punning issues.  More recent versions of queue.h (including the
one we copied into include/k5-queue.h) define additional TAILQ functions
including:

#define TAILQ_PREV(elm, headname, field) \
        (*(((struct headname *)((elm)->field.tqe_prev))->tqh_last))

which is pretty clearly a strict aliasing violation since tqe_prev could
point to the first member of an element structure rather than a list
head.  Therefore, we should avoid using TAILQ_PREV,
TAILQ_FOREACH_REVERSE, and TAILQ_FOREACH_REVERSE_SAFE if we want to
avoid unpleasant surprises.  TAILQs aren't really designed for reverse
iteration anyway.

I will adjust the commit message on my CIRCLEQ->TAILQ patch to reflect
my belief that it's working around a compiler bug, and push it.

I will revert d21a86e47a7cda29225013e08d060095b94b2ee7 and make an
alternate change to deal with special shell characters in the system
dictionary, since the built-in word list is not long enough for all of
the tests.

Download (untitled) 1.7k
     
 
Download circ.c 740b
      Wed Feb 19 16:53:40 2014  ghudson - Status changed from open to review    
      Wed Feb 19 16:53:40 2014  ghudson - Correspondence added    
     
From: ghudson@mit.edu
Subject: git commit


Use TAILQ macros instead of CIRCLEQ in libdb2

The optimizer in gcc 4.8.1 (but not the current gcc head revision)
breaks the queue.h CIRCLEQ macros, apparently due to an overzealous
strict aliasing deduction.  Use TAILQ macros in the libdb2 mpool code
instead.

https://github.com/krb5/krb5/commit/26d874412983c4c9979a9f5e7bec51834ad4cda5
Author: Greg Hudson <ghudson@mit.edu>
Commit: 26d874412983c4c9979a9f5e7bec51834ad4cda5
Branch: master
 src/plugins/kdb/db2/libdb2/mpool/mpool.c |   43 ++++++++++++++----------------
 src/plugins/kdb/db2/libdb2/mpool/mpool.h |    8 +++---
 2 files changed, 24 insertions(+), 27 deletions(-)


Download (untitled) 630b
      Wed Feb 19 16:53:41 2014  ghudson - Correspondence added    
     
From: ghudson@mit.edu
Subject: git commit


Use system dictionary for db2 tests again

The built-in word list is not long enough for all of the libdb2 tests
to run properly.  Revert d21a86e47a7cda29225013e08d060095b94b2ee7 and
go back to using the system dictionary if we find one.  However, omit
any lines from the chosen word list which contain non-alphabetical
characters.

https://github.com/krb5/krb5/commit/dba768e873d3ae34cfb2ff9d9c2d3644981f23a5
Author: Greg Hudson <ghudson@mit.edu>
Commit: dba768e873d3ae34cfb2ff9d9c2d3644981f23a5
Branch: master
 src/plugins/kdb/db2/libdb2/test/run.test |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)


Download (untitled) 631b
      Tue Jul 22 13:56:18 2014  ghudson - Target_Version 1.12.2 added    
      Tue Jul 22 13:56:18 2014  ghudson - Tags pullup added    
      Tue Jul 22 14:35:55 2014  tlyu - Status changed from review to resolved    
      Tue Jul 22 14:35:55 2014  tlyu - Version_Fixed 1.12.2 added    
      Tue Jul 22 14:35:55 2014  tlyu - Correspondence added    
     
From: tlyu@mit.edu
Subject: git commit


Use TAILQ macros instead of CIRCLEQ in libdb2

The optimizer in gcc 4.8.1 (but not the current gcc head revision)
breaks the queue.h CIRCLEQ macros, apparently due to an overzealous
strict aliasing deduction.  Use TAILQ macros in the libdb2 mpool code
instead.

(cherry picked from commit 26d874412983c4c9979a9f5e7bec51834ad4cda5)

https://github.com/krb5/krb5/commit/c7bb9278ad12c9278f316479af56f9e952f4d650
Author: Greg Hudson <ghudson@mit.edu>
Committer: Tom Yu <tlyu@mit.edu>
Commit: c7bb9278ad12c9278f316479af56f9e952f4d650
Branch: krb5-1.12
 src/plugins/kdb/db2/libdb2/mpool/mpool.c |   43 ++++++++++++++----------------
 src/plugins/kdb/db2/libdb2/mpool/mpool.h |    8 +++---
 2 files changed, 24 insertions(+), 27 deletions(-)


Download (untitled) 736b
      Tue Jul 22 14:35:56 2014  tlyu - Correspondence added    
     
From: tlyu@mit.edu
Subject: git commit


Use system dictionary for db2 tests again

The built-in word list is not long enough for all of the libdb2 tests
to run properly.  Revert d21a86e47a7cda29225013e08d060095b94b2ee7 and
go back to using the system dictionary if we find one.  However, omit
any lines from the chosen word list which contain non-alphabetical
characters.

(cherry picked from commit dba768e873d3ae34cfb2ff9d9c2d3644981f23a5)

https://github.com/krb5/krb5/commit/dc6e116f341300fb79a5e1aba76f884d01ef378d
Author: Greg Hudson <ghudson@mit.edu>
Committer: Tom Yu <tlyu@mit.edu>
Commit: dc6e116f341300fb79a5e1aba76f884d01ef378d
Branch: krb5-1.12
 src/plugins/kdb/db2/libdb2/test/run.test |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)


Download (untitled) 728b
      Tue Jul 29 13:12:47 2014  ghudson - Comments added    
     
Ubuntu 14.04 uses gcc 4.8.2 and manifests this bug in the libdb2 tests
and in practice.  (The compiler bug doesn't seem to manifest using
circ.c, which is a little confusing).  Here is a launchpad bug where we
will try to get Ubuntu to SRU the workaround:

https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1347147

Here is someone running into this bug on an Ubuntu 14.04 system:

http://mailman.mit.edu/pipermail/kerberos/2014-July/020007.html


Download (untitled) 450b
      Wed Jul 30 11:41:36 2014  ghudson - Comments added    
     
Anders Kaseorg did some excellent research on this and filed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 against gcc.  That bug
report also contains a better test case (circ.c doesn't manifest the bug
in gcc 4.8.2, but does manifest the bug in mpool.c; the test case in the
gcc bug report does manifest the bug in gcc 4.8.2.)


Download (untitled) 336b
      Wed Dec 16 18:03:01 2015  tlyu - Keyword pullup deleted