[#6279] Output pattern test of failX-frag.c in libmudflap may fail sometimes

Document created by Aaronwu Employee on Oct 17, 2013
Version 1Show Document
  • View in full screen mode

[#6279] Output pattern test of failX-frag.c in libmudflap may fail sometimes

Submitted By: Vivi Li

Open Date

2010-09-29 03:25:25     Close Date

2012-06-07 04:32:11

Priority:

Medium     Assignee:

Stuart Henderson

Board:

N/A     Silicon Revision:

Resolution:

Fixed     Fixed In Release:

N/A

Processor:

ALL     

Host Operating System:

toolchain rev.:

4.1 4.3 trunk head     kernel rev.:

State:

Closed     Found In Release:

N/A

Is this bug repeatable?:

N/A     

Summary: Output pattern test of failX-frag.c in libmudflap may fail sometimes

Details:

 

Output pattern test of failX-frag.c in libmudflap may fail from time to time.

X may vary for each regression cycle.

 

Bellow is a failing list in one regression cycle:

--

bfin-uclinux: libmudflap.c/fail11-frag.c output pattern test

bfin-uclinux: libmudflap.c/fail1-frag.c (-O3) output pattern test

bfin-uclinux: libmudflap.c/fail22-frag.c (-O3) output pattern test

 

bfin-linux-uclibc: libmudflap.c/fail12-frag.c (-O3) output pattern test

bfin-linux-uclibc: libmudflap.c/fail14-frag.c output pattern test

bfin-linux-uclibc: libmudflap.c/fail22-frag.c output pattern test

bfin-linux-uclibc: libmudflap.c/fail3-frag.c output pattern test

--

 

Bellow is a list in another regression cycle:

--

bfin-linux-uclibc: libmudflap.c/fail12-frag.c output pattern test

bfin-linux-uclibc: libmudflap.c/fail38-frag.c output pattern test

 

bfin-uclinux: libmudflap.c/fail16-frag.c (-O2) output pattern test

bfin-uclinux: libmudflap.c/fail3-frag.c output pattern test

bfin-uclinux: libmudflap.c/fail40-frag.c (-static) output pattern test

bfin-uclinux: libmudflap.c/fail7-frag.c output pattern test

--

 

Follow-ups

 

--- Steve Kilbane                                            2010-10-05 04:37:47

These tests are failing because the test suite is badly designed.

 

We configure libmudflap to raise violations to SEGV through MUDFLAP_OPTIONS

(otherwise we weren't detecting any failures at all). Once the problem occurs,

the tests verify their output by matching several "blah." patterns.

But because SEGV's been raised, "SEGV" is appearing in the output as

well, and where it appears is purely chance; if it turns up in the middle of the

fixed text a pattern is trying to match (e.g. "blSEGVah"), the test

will fail.

 

--- Steve Kilbane                                            2010-10-06 07:34:26

The "SEGV" text is emitted by the shell, iff the application was

terminated by a signal and it wasn't SIGINT. I see different options as to how

to address this.

 

The first option is to convince DejaGnu to use a different approach to

executing these tests, e.g. in a wrapper shell that traps SEGV (or ABRT) and

gives a non-zero exit status as a result.

 

A second is to use -viol-abort instead of -viol-segv. The shell will still emit

ABRT, but abort() can at least flush any output first (if

__UCLIBC_HAS_STDIO_SHUTDOWN_ON_ABORT__, which at present it does not).

 

The other approach is to enhance libmudflap. By adding a -viol-exit1 switch, I

can make libmudflap just call _exit(1) (or maybe exit(1)) instead of either

kill(getpid(), SIGSEGV) or abort() - that appears to take care of most of these

problems, and would be IMO a useful enhancement in its own right.

 

What baffles me about all this is: isn't this a common problem on all

platforms? Possibly it isn't, because it shouldn't actually be a problem here,

either: libmudflap emits its tracing to stderr, and stderr isn't supposed to be

buffered. So how come the SEGV or ABRT text is turning up in the stream earlier

than text written to stderr before invoking either of those two actions? Is it

something that's going on elsewhere, such as within the I/O redirection

happening between shell and invoked process?

 

--- Stuart Henderson                                         2010-10-14 09:34:28

i suppose we could just:

{ dg-prune-output SEGV }

for each of the fail tests.

 

or alternatively, there's a prune_X_output function for some modules (gcc/g++)

but i can't see one for libmudflap.  we could add one and have it prune SEGV's.

 

--- Stuart Henderson                                         2012-02-13 10:52:08

Finally fixed this in the board files.  we now prune any SEGVs and place them at

the end of the runtime output.

 

--- Mingquan Pan                                             2012-06-07 05:30:32

Yes. the failxxx-frag.c output pattern test in libmudflap testing are all can

pass now. Close.

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

libmudflap.tar.gz    application/x-gzip    38301    Vivi Li

Attachments

Outcomes