Richard Biener writes:
> On July 20, 2016 2:01:18 AM GMT+02:00, Andrew Pinski <pins...@gmail.com>
> wrote:
>>Hi,
>> I noticed that ubsan testsuite sometimes has failures due to dejagnu
>>buffer gets full and we no longer match on the output any more.
>>As you can see from the .log file:
>>/data1/jenkins/workspace/BuildThunderX_native_gcc_6/gcc/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c:88:3:
>>runtime error: value iPASS: c-c++-common/ubsan/float-cast-overflow-1.c
>> -O0 execution test
>>
>>This looks like I am using a much bigger path name than what most
>>people use which is why I am seeing it fail. Is there a way to
>>increase the buffer for dejagnu/expect so dg-output matches? Looks
>>like it is limited to 500k (if I read dejagnu code correctly).
>>
>>Or can/should we split up float-cast-overflow-1.c instead?
>
> I see this for some of the larger C frontend tests with lots of expected
> errors/warnings as well.
Are you guys getting this everytime or is it sporadic?
I recently ran into something similar, except that there were more parts
involved (Windows subsystem for Linux, wrapper process for gcc etc..)
and that it was random. After messing around with stdout/stderr buffer
sizes and finding they didn't really help, I eventually ran strace to
figure out what the heck was happening. The runtest process stops when a
read syscall gets EIO, but if it so happens that there's buffered data that's
already been read and not written yet, they get dropped.
9631 read(8, "\r\n/gcc/gcc/testsuite/gcc.dg/c99-vla-jump-1.c:
I..e/gcc.dg/c99-vl", 4096) = 4096
9631 read(8, "a-jump-1.c:300:124: note...ote: 'f' declared here\r\r\n", 4096)
= 1380
9631 write(7, "1.c:283:124: note: la..er with var", 4096) = 4096
9631 write(7, "iably modified typ..99-vla-jump-1.c:300:163: error: j", 1905) =
1905
...
9631 write(4, "\0", 1) = 1
...
9631 read(8, 0x13a49b8, 4096) = -1 EIO (Input/output error)
9631 fcntl(8, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
9631 fcntl(8, F_SETFL, O_RDWR) = 0
9631 fcntl(8, F_GETFL) = 0x2 (flags O_RDWR)
9631 close(8) = 0
9631 open("/dev/null", O_RDONLY) = 8
9631 fcntl(8, F_SETFD, FD_CLOEXEC) = 0
9631 fcntl(8, F_SETFD, FD_CLOEXEC) = 0
9631 wait4(9691, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 9691
9631 close(8) = 0
...
9631 write(7, "compiler exited with status 1\n", 30) = 30
The 1380 bytes read in the last read call end up getting dropped on the
floor.
Andrew, is the 500K limit you see in remote.exp:standard_wait?
Regards
Senthil
