Bug 690209 - unexpected "od: write error" when running od on a large file and redirecting to "head" in tcsh under fvwm
Summary: unexpected "od: write error" when running od on a large file and redirecting ...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: fvwm
Version: 23
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Lemenkov
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-23 15:37 UTC by Jos de Kloe
Modified: 2016-12-20 12:06 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-20 12:06:35 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
output of the command: strace -o strace.output od -t x1 -A n /boot/vmlinuz* | head -n 10000 > temp.hexdump.csh (220.90 KB, application/x-gzip)
2011-05-31 07:25 UTC, Jos de Kloe
no flags Details

Description Jos de Kloe 2011-03-23 15:37:03 UTC
Description of problem:

the od tool produces "write error" warnings on large input files when its output is redirected to a pipe

Version-Release number of selected component (if applicable):

>od --version
od (GNU coreutils) 8.4

How reproducible:

always

Steps to Reproduce:
1. take any large (multi MB) binary file, for example /boot/vmlinuz* (which in my case is vmlinuz-2.6.34.7-56.fc13.i686.PAE)

2. run the od tool on it, and redirect via head to a file:
>od -t x1 -A n /boot/vmlinuz* | head -n 10000 > temp.hexdump2

this will produce the correct output file, but also these 2 messages to stderr:
od: write error
od: write error
Also the exit status of the command is set to 1 now.

3. as reference, do the same using hexdump and all works just as expected:
>hexdump -C /boot/vmlinuz* | head -n 10000 > temp.hexdump
[no errors to stderr here]

Actual results:

as mentioned above, the output file seems correct, but the error printed to stderr was not expected. 

Expected results:

the command should just run silently 
The exit status should be 0.

Additional info:

-if you leave out the head command, the problem does not occur.
-if you use smaller files the problem does not occur

Comment 1 Bug Zapper 2011-05-30 10:54:22 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 2 Ondrej Vasik 2011-05-30 11:26:38 UTC
Strange, I missed that one bug report completely. These write errors are definitely reaction to SIGPIPE, however I'm not able to reproduce it with my od here.
(
[Reset@dhcp-24-196 ~]$ rpm -q coreutils
coreutils-8.4-13.el6.i686
[Reset@dhcp-24-196 ~]$ od -t x1 -A n /boot/vmlinuz-2.6.32-131.0.1.el6.i686 | head -n 40000 >hexdump
[Reset@dhcp-24-196 ~]$ echo $?
0
)

This is with RHEL-6 coreutils, but the od is the same there. Do you still experience the issue? Could you please strace it ?

Comment 3 Jos de Kloe 2011-05-31 07:24:09 UTC
Yes, this problem still occurs on my system. However, I did find out that there is a relation to which shell you are using: it only occurs when I use csh as interactive shell, not if I am using bash, so it might also be a csh problem.

Currently I have these versions installed:

>rpm -qf /usr/bin/od
coreutils-8.5-7.fc14.i686
>rpm -qf /bin/csh
tcsh-6.17-12.fc14.i686
>rpm -qf /bin/bash
bash-4.1.7-3.fc14.i686

This is the output I see on the terminal:

(running the bash as interactive shell)
>csh -c 'od -t x1 -A n /boot/vmlinuz* | head -n 10000 > temp.hexdump.csh' 
>
>od -t x1 -A n /boot/vmlinuz* | head -n 10000 > temp.hexdump.csh
>

result: no errors and identical outputs

(running csh as interactive shell)
>od -t x1 -A n /boot/vmlinuz* | head -n 10000 > temp.hexdump.csh
od: write error
od: write error
>bash -c 'od -t x1 -A n /boot/vmlinuz* | head -n 10000 > temp.hexdump.bash'
od: write error
od: write error
>
result: both cases give the write error. Output is identical to the above case without errors for both cases.

Also when using csh as interactive shell, the command clearly takes much longer to run, i.e. bash seems to communciate to the od command when the head command is done procuding output and stops the od command (or moves it to the background?), but csh does not (I guess).

As requested, I'll attach the strace output for the problematic command:

strace -o strace.output od -t x1 -A n /boot/vmlinuz* | head -n 10000 > temp.hexdump.csh

Comment 4 Jos de Kloe 2011-05-31 07:25:13 UTC
Created attachment 501931 [details]
output of the command:  strace -o strace.output od -t x1 -A n /boot/vmlinuz* | head -n 10000 > temp.hexdump.csh

Comment 5 Ondrej Vasik 2011-05-31 08:58:10 UTC
Thanks for additional info, ah, ok, with tcsh shell ... probably yes, it is probably related to shell, many broken pipes in the strace log - under bash I have only one EPIPE ... adding tcsh maintainer to CC ...

Comment 6 jdekloe 2012-03-22 08:25:07 UTC
problem is still present for Fedora16:

>od -t x1 -A n /boot/vmlinuz-3.2.9-2.fc16.x86_64  | head -n 1000 > temp.hexdump
od: write error
od: write error

>rpm -qf /bin/csh
tcsh-6.17-15.fc16.x86_64

Comment 7 Roman Kollár 2012-08-31 16:21:19 UTC
This is probably not a tcsh issue, tcsh just inherited signal disposition from its parent process - SIGPIPE is set to SIG_IGN and `od` is not killed as it should be. You can check this by running `perl -le 'print $SIG{PIPE}'`.

How exactly do you start tcsh? (from what)

Comment 8 jdekloe 2012-09-02 20:03:36 UTC
output of "perl -le 'print $SIG{PIPE}'" is:
IGNORE

My preferred window manager is fvwm, and I use a simple python script called by fvwm's "InitFunction" to start a bunch of xterms using tcsh after login.

As mentioned above, the od:write error occurs if I manually issue the od command on the commandline.

The original problem occurred while doing some tests in a csh script that was called from a Makefile.

My current system is Fedora17 using these software versions:

tcsh.x86_64   6.17-18.fc17
coreutils.x86_64   8.15-7.fc17
fvwm.x86_64   2.6.5-1.fc17
python.x86_64  2.7.3-7.2.fc17
xterm.x86_64   278-1.fc17  

and this still shows the reported problem.

Comment 9 Kamil Dudka 2012-09-02 20:52:33 UTC
There used to be a problem with libdbus causing tcsh to behave like this:

https://bugs.freedesktop.org/show_bug.cgi?id=13318

Comment 10 Ondrej Vasik 2012-09-03 11:48:12 UTC
This libdbus issue should be solved in dbus-1.4.4 - and we have 1.4.10 in f16/f17 ... however - as already noted, most probably not coreutils and likely not tcsh shell issue - any idea where to reassign?

Comment 11 Jos de Kloe 2013-02-05 20:48:27 UTC
Just tested again, and this still occurs in an xterm running tcsh on Fedora18:

>od -t x1 -A n /boot/vmlinuz-3.6.11-1.fc17.x86_64 | head -n 10000 > temp.hexdump2
od: write error
od: write error
>

My current software versions are:

tcsh-6.18.00-3.fc18.x86_64
coreutils-8.17-8.fc18.x86_64
fvwm-2.6.5-3.fc18.x86_64
xterm-287-1.fc18.x86_64

It's no big problem for me, but somehow this should be fixed some day I think.

Comment 12 Ondrej Vasik 2013-02-05 21:39:39 UTC
Yes, it would be good to fix it, however I don't know what is the good place to reassign - I think I can't do much in coreutils package. Roman thinks this is not tcsh issue and I tend to agree... as written in comment#7, SIGPIPE is set to SIG_IGN and thus causing this behaviour. This is inherited from parent process or maybe set by fvwm... Let's try fvwm guys if they have any idea what can be done here.

Comment 13 Jos de Kloe 2013-07-22 14:04:15 UTC
still present in fedora 19:

>od -t x1 -A n /boot/vmlinuz-3.9.9-302.fc19.x86_64 | head -n 1000 > temp.hexdump
od: write error
od: write error: Broken pipe
>

my current software versions:

tcsh-6.18.00-7.fc19.x86_64
coreutils-8.21-11.fc19.x86_64
fvwm-2.6.5-4.fc19.x86_64
xterm-293-1.fc19.x86_64

Comment 14 Jos de Kloe 2014-02-07 10:01:13 UTC
and also in fedora 20:

>od -t x1 -A n /boot/vmlinuz-3.12.9-301.fc20.x86_64  | head -n 1000 > temp.hexdump
od: write error
od: write error: Broken pipe
>

my current software versions:

tcsh-6.18.01-5.fc20.x86_64
coreutils-8.21-20.fc20.x86_64
fvwm-2.6.5-6.fc20.x86_64
xterm-297-1.fc20.x86_64

Comment 15 Jos de Kloe 2015-05-13 07:14:17 UTC
on Fedora 21 the problem has disappeared.

The command:

>od -t x1 -A n /boot/vmlinuz-3.12.9-301.fc20.x86_64  | head -n 1000 > temp.hexdump
>

is silent now, as expected.

My current software versions:

tcsh-6.18.01-13.fc21.x86_64
coreutils-8.22-19.fc21.x86_64
fvwm-2.6.5-9.fc21.x86_64
xterm-308-3.fc21.x86_64

So as soon as Fedora 20 hits EOL I think this bug can be closed.

Comment 16 Fedora End Of Life 2015-05-29 08:38:44 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 17 Jos de Kloe 2015-06-10 10:16:29 UTC
I am sorry, but I have to report that the issue is back again on Fedora 21:

>od -t x1 -A n /boot/vmlinuz-4.0.4-202.fc21.x86_64 | head -n 10000 > temp.hexdump2
od: write error
od: write error: Broken pipe
>

my current software versions are:

tcsh-6.18.01-13.fc21.x86_64
coreutils-8.22-22.fc21.x86_64
fvwm-2.6.5-9.fc21.x86_64
xterm-308-3.fc21.x86_64

Comment 18 Fedora End Of Life 2015-11-04 11:30:44 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 19 Jos de Kloe 2015-11-15 15:23:45 UTC
Still the same issue for Fedora 23:

>od -t x1 -A n /boot/vmlinuz-4.2.5-300.fc23.x86_64   | head -n 1000 > temp.hexdump
od: write error
od: write error: Broken pipe
>
(run us regular user from an xterm inside the fvwm window manager)

my current software versions are:

tcsh-6.19.00-3.fc23.x86_64
coreutils-8.24-4.fc23.x86_64
fvwm-2.6.5-10.fc23.x86_64
xterm-318-2.fc23.x86_64

Comment 20 Fedora End Of Life 2016-11-24 10:30:15 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 21 Jos de Kloe 2016-11-26 10:23:12 UTC
problem still persists with Fedora 24, but since there seems no hope to solve this anytime soon, I'll let it be closed by the EOL of F23.
If anyone thinks otherwise, then feel free to respond.

Comment 22 Fedora End Of Life 2016-12-20 12:06:35 UTC
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.