[reSIProcate] failures in testParseBuffer

[Byron Campen]

On 2/28/14 3:49 PM, Daniel Pocock wrote:
>
> 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 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?
>
> (gdb) print pb
> $1 = {static Whitespace = 0x7ffff7bbd5cf " \t\r\n",
>    static ParamTerm = 0x7ffff7bbd5d4 ";?", mBuff = 0x7fffffffe4d0 "estt",
>    mPosition = 0x7fffffffe4d1 "stt", mEnd = 0x7fffffffe4d5 "",
>    mErrorContext = @0x7ffff7dd8a80}
     Could you pop onto your chat account so we can speed this up?

Best regards,
Byron Campen