Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Doxygen output BrokenPipeError: [Errorno 32] Broken pipe #74

Open
athola opened this issue Mar 30, 2020 · 1 comment
Open

[Bug] Doxygen output BrokenPipeError: [Errorno 32] Broken pipe #74

athola opened this issue Mar 30, 2020 · 1 comment

Comments

@athola
Copy link

athola commented Mar 30, 2020

When enabling FILTER_SOURCE_FILES tag in Doxyfile.cfg, output to command line after running:

doxygen Doxyfile

causes an output to command line intermittently the following:

Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe

While searching around on the web for this, I found this error popped up in mypy as well, specifically addressed in this issue.

See this comment by user @pkch:

This is not a mypy problem, but rather a well-established behavior of python interpreter.

When head gets its 10 lines, it knows it's done, so it closes the pipe. As a result, the OS (Linux/OSX but not Windows) sends SIGPIPE signal to the previous process in the shell pipe. The default (and usually correct) handling of SIGPIPE is to terminate. This mechanism is designed to make shell pipes like cat hugefile | head work efficiently - without having to read the entire file when you only need the first few lines.

Python interpreter (for reasons that I don't understand) overrides the default handling of SIGPIPE; specifically, it ignores this signal. As a result, any time the pipe is closed on the other end, instead of terminating, a python program would (by default) keep trying to write to the non-existent pipe, thus eventually causing a write error (how soon this happens depends on buffer sizes and policy).

You can observe this behavior by simply running python -c "print('\n'.join('a'*1000000))" | head. It would print the 10 lines, but then report a BrokenPipeError instead of quietly exiting.

To fix this, one would need to override python's handler with the default handler of SIGPIPE (which terminates the process). As @kirbyfan64 suggested, it can be done with signal.signal(signal.SIGPIPE, signal.SIG_DFL).

Windows does not have a SIGPIPE signal at all, and so this solution wouldn't work. Instead, I suppose one could simply catch BrokenPipeError and terminate with exit code 0. But this is only a partial solution because some IO functions in python standard libraries catch and ignore this exception (instead of terminating). This is why sometimes the user sees a message like Exception ignored in: <_io.TextIOWrapper name='' mode='w' encoding='UTF-8'> -- and after that, some effort is wasted by the program that keeps producing output that won't be needed any more. I don't know of any feasible comprehensive solution to this problem under Windows.

I wouldn't consider this a major bug, since the error message only happens after the desired number of lines are displayed by head, so it's just a minor annoyance (unless someone uses the output in some kind of an automated system; or unless the output takes too long to generate).

@athola
Copy link
Author

athola commented Apr 10, 2020

Hey all, I found a temporary workaround for this on Linux. Change the line in py_filter to the following:

doxypypy -a -c -- "${1}" | tail -n +1 | head -n3000

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant