Re: [reSIProcate] failures in testParseBuffer
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@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}
Could you pop onto your chat account so we can speed this up?
Best regards,
Byron Campen