Re: ubsan and Dejagnu not having a big enough buffer in some cases

[Richard Biener <richard dot guenther at gmail dot com>]

On July 20, 2016 9:18:09 AM GMT+02:00, Senthil Kumar Selvaraj <senthil_kumar.selvaraj@atmel.com> wrote:
>
>Richard Biener writes:
>
>> On July 20, 2016 2:01:18 AM GMT+02:00, Andrew Pinski
><pinskia@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 see it pretty reliably but only when building inside a chroot inside a VM (probably the large path issue as well).

>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. 

That might also match what I see more closely, at least the output is nowhere near to 500K but the tail is missing.

Richard.

>Andrew, is the 500K limit you see in remote.exp:standard_wait?
>
>Regards
>Senthil