Re: [reSIProcate] failures in testParseBuffer
On 01/03/14 00:14, Daniel Pocock wrote:
>
>
> On 27/02/14 17:47, Byron Campen wrote:
>> On 2/27/14 8:20 AM, Daniel Pocock wrote:
>>> On 27/02/14 17:03, Byron Campen wrote:
>>>> On 2/27/14 5:07 AM, Daniel Pocock wrote:
>>>>> Some people have noticed failures in testParseBuffer, e.g.
>>>>>
>>>>> https://launchpadlibrarian.net/167715579/buildlog_ubuntu-trusty-amd64.resiprocate_1.9.1-1_FAILEDTOBUILD.txt.gz
>>>>>
>>>>>
>>>>>
>>>>> That is with gcc 4.8 (most of my own testing is with gcc 4.7 and travis
>>>>> uses 4.6.3 and the problem hasn't appeared in either of those
>>>>> environments)
>>>>>
>>>>> Has anybody else seen issues relating to this recently or in the past?
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> resiprocate-devel mailing list
>>>>> resiprocate-devel@xxxxxxxxxxxxxxx
>>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>> I've never seen this kind of behavior. Seems very troubling to me.
>>>> Is it reproducible?
>>> I haven't tried to reproduce it myself yet, but the same failure has
>>> been observed on a Debian unstable 64 bit build:
>>>
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740232
>>>
>>>
>>> but the build farm doesn't show any sign of this problem in any other
>>> platform running Debian unstable/gcc 4.8
>>> https://buildd.debian.org/status/package.php?p=resiprocate
>>>
>>> (the Hurd failure in that report is the testLogger issue I mentioned in
>>> an earlier email)
>>>
>>>
>> It would be nice if we could determine what the result actually was.
>> My suspicion is that the moment we add any logging in the case of
>> failure, the bug will go away. We need to try to catch this in a
>> debugger and find out what's really going on (both what's in memory, and
>> the actual instructions the compiler generated).
>>
>
> Gotcha... well, in progress
>
> It happens in my VM now, I'll have a closer look and see where we get to
>
> I also had a random compiler failure in the same environment earlier
> today, not sure if it is a g++ or Ubuntu trusty issue as the compile
> continue successfully when I restarted it.
>
>
> PASS: testMD5Stream
> lt-testParseBuffer: testParseBuffer.cxx:41: int main(int, char**):
> Assertion `result == "test"' failed.
> /bin/bash: line 5: 6876 Aborted (core dumped) ${dir}$tst
> FAIL: testParseBuffer
> Generating 1000 random 8 byte strings and checking for uniqueness.
> 5224ab56
Reproducible in the debugger too (output below), notice:
result=estt
Note that I tried two Ubuntu systems:
Ubuntu (saucy) amd64, gcc 4.8, test cases all run fine
Ubuntu (trusty) amd64, gcc 4.8, testParseBuffer failure (as below) and
random failure elsewhere in compile
$ libtool --mode=execute gdb rutil/test/testParseBuffer
GNU gdb (Ubuntu 7.7-0ubuntu3) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
/home/daniel/ws/resiprocate/rutil/test/.libs/lt-testParseBuffer...done.
(gdb) run
Starting program:
/home/daniel/ws/resiprocate/rutil/test/.libs/lt-testParseBuffer
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
result=estt
lt-testParseBuffer: testParseBuffer.cxx:42: int main(int, char**):
Assertion `result == "test"' failed.
Program received signal SIGABRT, Aborted.
0x00007ffff72a3f79 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb)