Re: [reSIProcate] failures in testParseBuffer
On 01/03/14 00:42, Byron Campen wrote:
> 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@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)
> Wow. And what is the parsebuffer itself pointing at?
(gdb) print pb
$1 = {static Whitespace = 0x7ffff7bbd5cf " \t\r\n",
static ParamTerm = 0x7ffff7bbd5d4 ";?", mBuff = 0x7fffffffe4d0 "estt",
mPosition = 0x7fffffffe4d1 "stt", mEnd = 0x7fffffffe4d5 "",
mErrorContext = @0x7ffff7dd8a80}