stress-stack stressor terminates with segfault

[Colin Ian King]

At the end of a particular run, stress-ng printed "unsuccessful run completed in 6109.56s", and returned exit code 2, but there was no "fail:" message anywhere prior to that. How can I determine which test actually failed?

The command line was: stress-ng --timestamp --verbose --verify --metrics brief --times --tz --sequential 0 --exclude efivar,resources --timeout 30 --copy-file-bytes 512M --fallocate-bytes 512M --fiemap-bytes 512M --hdd-bytes 512M --iomix-bytes 512M --msync-bytes 512M --readahead-bytes 512M --revio-bytes 512M --sync-file-bytes 512M

I've uploaded the command output here: https://gist.github.com/glaebhoerl/130b0a4111fba0d6b7222d358b905f1f

Using stress-ng-0.10

[Colin Ian King (colin-king)]

Looking at the log there is a failure message in the stressor:

stress-ng: 19:04:27.27 debug: [20634] process [833] (stress-ng-stack) terminated on signal: 11 (Segmentation fault)

The stressor itself should not be segfaulting. The stressor forks off child processes that can segfault (e.g. when the stack is too large) but the parent should never segfault, hence the error is caught by the main top-level stress-ng controlling process and reports this as a core test failure. I believe this may be occurring because of memory pressure on the stressor. I'll try figure out why this is occurring.

[Colin Ian King (colin-king)]

I've pushed a fix that I believe addresses the segfault:

https://kernel.ubuntu.com/git/cking/stress-ng.git/commit/?id=a6a41968fcf598ffacb86ee85cf5d632f0bd8d83

I was able to reproduce the error and it was clear that the alternative signal stack was not expanded because lack of free pages causing the segfault handler itself to segfault. Ugh.