[reSIProcate] failures in testParseBuffer

[Byron Campen]

On 2/28/14 3:30 PM, Daniel Pocock wrote:
>
> 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 at resiprocate.org
>>>>>> 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 at 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)
    Wow. And what is the parsebuffer itself pointing at?

Best regards,
Byron Campen