mainAutoconf - Support: sr #110354, Parallel autotest produces mangled...


sr #110354: Parallel autotest produces mangled output on Solaris 10

Submitter:  Zack Weinberg <zackw>
Submitted:  Sat 31 Oct 2020 03:09:25 PM UTC
Priority:  * 2 - Eventually Severity:  3 - Normal
Status:  Confirmed Privacy:  Public
Assigned to:  None Open/Closed:  Open
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup

Fri 08 Dec 2023 02:04:49 PM UTC, comment #2: 

I still plan to work on this myself but I'm not committing to any particular timeframe.  If someone wants to beat me to it, please feel free.

Zack Weinberg <zackw>
Group administrator
Sun 15 Nov 2020 08:24:13 PM UTC, comment #1: 

I wanted to get this sorted for 2.70 so that automatic testing would be more reliable, but I don't think it's going to be feasible.

Zack Weinberg <zackw>
Group administrator
Sat 31 Oct 2020 03:09:25 PM UTC, original submission:  

On Solaris 10, with CONFIG_SHELL=/bin/bash (version 3.2.51(1)-release, I believe), parallel autotest may produce mangled output, with more than one test result reported on a single line:

./ $CONFIG_SHELL ./micro-suite -j4
## -------------------------------------------------------------- ##
## GNU Nonsense 1.0 test suite: suite to test parallel execution. ##
## -------------------------------------------------------------- ##

  3: test number 3                                   ok  2: test number 2                                   ok  1: test number 1                                   ok

  4: test number 4                                   ok
  5: test number 5                                   ok
  6: test number 6                                   ok
  7: test number 7                                   ok
  8: test number 8                                   ok
  9: test number 9                                   ok 10: test number 10                                  ok

 11: test number 11                                  ok
 12: test number 12                                  ok
 13: test number 13                                  ok
 14: test number 14                                  ok 15: test number 15                                  ok

 16: test number 16                                  ok

## ------------- ##
## Test results. ##
## ------------- ##

All 16 tests were successful.

This causes test #212 to fail, because it's looking for 16 copies of 'ok' each on their own line:

./ grep -c '^.\{53\}ok' stdout
< 16
> 12

I don't know if there's anything we can do about this.  It looks like a classic "two or more processes writing to the same pipe at once with the wrong amount of buffering" bug and we don't control the code doing the buffering.  I have been tinkering with replacing the parallel test driver with `make -j` but that's a long way from done and might not actually help.

(Originally reported by Dagobert as part of sr #110320, logs extracted from file #49873.)

Zack Weinberg <zackw>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by zackw (Submitted the item)
  • -email is unavailable- added by zackw

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-12-08 zackw StatusNone Confirmed
    2023-12-08 zackw Priority1 - Blocked 2 - Eventually
    2020-11-15 zackw Priority5 - Unprioritized 1 - Blocked
    2020-10-31 zackw Carbon-Copy- Added dagobert

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code