The Junit/XML reporter captures stdout/stderr by redirecting into a pipe, then reading it back in the same process. If an individual test prints enough output to fill up the pipe, the test process deadlocks waiting for a reader that is never going to drain the pipe.
Reproduce on Ubuntu 10 by:
#include "fct.h"
FCT_BGN()
{
FCT_QTEST_BGN(too_much_output)
{
int x;
for (x =0; x<100000; x++ )
printf("xxx\n");
}
FCT_QTEST_END();
}
FCT_END();
and then:
./a.out --logger junit
This affects the junit logger and custom loggers that use the same mechanism to capture stdout/stderr.
If I get a chance, I will try replacing the pipe with a temp file, but I'm not sure I will get to it any time soon.
The simple workaround is: Don't let the test blab so much.
The Junit/XML reporter captures stdout/stderr by redirecting into a pipe, then reading it back in the same process. If an individual test prints enough output to fill up the pipe, the test process deadlocks waiting for a reader that is never going to drain the pipe.
Reproduce on Ubuntu 10 by:
and then:
This affects the junit logger and custom loggers that use the same mechanism to capture stdout/stderr.
If I get a chance, I will try replacing the pipe with a temp file, but I'm not sure I will get to it any time soon.
The simple workaround is: Don't let the test blab so much.