This is the mail archive of the 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

On July 20, 2016 9:18:09 AM GMT+02:00, Senthil Kumar Selvaraj <> wrote:
>Richard Biener writes:
>> On July 20, 2016 2:01:18 AM GMT+02:00, Andrew Pinski
><> wrote:
>>>  I noticed that ubsan testsuite sometimes has failures due to
>>>buffer gets full and we no longer match on the output any more.
>>>As you can see from the .log file:
>>>runtime error: value iPASS:
>>>  -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
>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
>read syscall gets EIO, but if it so happens that there's buffered data
>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: 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
>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) =
>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

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


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

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