This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]