Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
4 added 46 characters in body
source | link

Does anyone know what the problem might be or what I am doing wrong?

I don't believe it's anything wrong in your two solutions. There's simply no way these could request the behaviour you describe... without deliberately forking a second process (and you don't call fork()), or killing the time process, or hacking the kernel etc.

Perhaps your computer is broken.

Previously I've had weird behaviour caused by silent disk corruption. I might try running debsums or rpm --verify -a to check.

It could equally be a bug in the chain of software which displays the output.

For example gnome-terminal 3.22 has a crash bug when fed some sequence of binary. Several versions of the Linux kernel had this great bug where sending more than 4kB over a terminal emulator ("pseudo-tty") to a read-line enabled program such as a shell, could lose some lines. Dumping 35MB of text at a time is relatively unusual.

I might try running debsums or rpm --verify -a, there could be some bug like that in this case. Previously I've had weird behaviour caused by silent disk corruptionyour OS.

If you can reproduce the problem with an input file of a mere 100kB, here's a different computer for you which is almost certainly not corrupted in the same way as the host computer it is run on. Console output is pretty slow, there's only a few megabytes of free space as well. The output from running your program under time will not match real seconds for some reason, it shouldn't matter for this question though. The clipboard text box doesn't accept keyboard input for me (Firefox 53), so I used the right-click menu to copy data in through /dev/clipboard as per the FAQ.

Does anyone know what the problem might be or what I am doing wrong?

I don't believe it's anything wrong in your two solutions. There's simply no way these could request the behaviour you describe... without deliberately forking a second process (and you don't call fork()), or killing the time process, or hacking the kernel etc.

Perhaps your computer is broken.

It could be a bug in the chain of software which displays the output.

For example gnome-terminal 3.22 has a crash bug when fed some sequence of binary. Several versions of the Linux kernel had this great bug where sending more than 4kB over a terminal emulator ("pseudo-tty") to a read-line enabled program such as a shell, could lose some lines. Dumping 35MB of text at a time is relatively unusual.

I might try running debsums or rpm --verify -a in this case. Previously I've had weird behaviour caused by silent disk corruption.

If you can reproduce the problem with an input file of a mere 100kB, here's a different computer for you which is almost certainly not corrupted in the same way as the host computer it is run on. Console output is pretty slow, there's only a few megabytes of free space as well. The output from running your program under time will not match real seconds for some reason, it shouldn't matter for this question though. The clipboard text box doesn't accept keyboard input for me (Firefox 53), so I used the right-click menu to copy data in through /dev/clipboard as per the FAQ.

Does anyone know what the problem might be or what I am doing wrong?

I don't believe it's anything wrong in your two solutions. There's simply no way these could request the behaviour you describe... without deliberately forking a second process (and you don't call fork()), or killing the time process, or hacking the kernel etc.

Perhaps your computer is broken.

Previously I've had weird behaviour caused by silent disk corruption. I might try running debsums or rpm --verify -a to check.

It could equally be a bug in the chain of software which displays the output.

For example gnome-terminal 3.22 has a crash bug when fed some sequence of binary. Several versions of the Linux kernel had this great bug where sending more than 4kB over a terminal emulator ("pseudo-tty") to a read-line enabled program such as a shell, could lose some lines. Dumping 35MB of text at a time is relatively unusual, there could be some bug like that in your OS.

If you can reproduce the problem with an input file of a mere 100kB, here's a different computer for you which is almost certainly not corrupted in the same way as the host computer it is run on. Console output is pretty slow, there's only a few megabytes of free space as well. The output from running your program under time will not match real seconds for some reason, it shouldn't matter for this question though. The clipboard text box doesn't accept keyboard input for me (Firefox 53), so I used the right-click menu to copy data in through /dev/clipboard as per the FAQ.

3 added 518 characters in body
source | link

Does anyone know what the problem might be or what I am doing wrong?

I don't believe it's anything wrong in your two solutions. There's simply no way these could request the behaviour you describe... without deliberately forking a second process (and you don't call fork()), or killing the time process, or hacking the kernel etc.

Perhaps your computer is broken.

It could be a bug in the chain of software which displays the output.

For example gnome-terminal 3.22 has a crash bug when fed some sequence of binary. Several versions of the Linux kernel had this great bug where sending more than 4kB over a terminal emulator ("pseudo-tty") to a read-line enabled program such as a shell, could lose some lines. Dumping 35MB of text at a time is relatively unusual.

I might try running debsums or rpm --verify -a in this case. Previously I've had weird behaviour caused by silent disk corruption.

It could also be a bug in the chain of software which displays the output.

If you can reproduce the problem with an input file of a mere 100kB, here's a different computer for you which is almost certainly not corrupted in the same way as the host computer it is run on. Console output is pretty slow, there's only a few megabytes of free space as well. The output from running your program under time will not match real seconds for some reason, it shouldn't matter for this question though. The clipboard text box doesn't accept keyboard input for me (Firefox 53), so I used the right-click menu to copy data in through /dev/clipboard as per the FAQ.

Does anyone know what the problem might be or what I am doing wrong?

I don't believe it's anything wrong in your two solutions. There's simply no way these could request the behaviour you describe... without deliberately forking a second process (and you don't call fork()), or killing the time process, or hacking the kernel etc.

Perhaps your computer is broken.

I might try running debsums or rpm --verify -a in this case. Previously I've had weird behaviour caused by silent disk corruption.

It could also be a bug in the chain of software which displays the output.

If you can reproduce the problem with an input file of a mere 100kB, here's a different computer for you which is almost certainly not corrupted in the same way as the host computer it is run on. Console output is pretty slow, there's only a few megabytes of free space as well. The output from running your program under time will not match real seconds for some reason, it shouldn't matter for this question though. The clipboard text box doesn't accept keyboard input for me (Firefox 53), so I used the right-click menu to copy data in through /dev/clipboard as per the FAQ.

Does anyone know what the problem might be or what I am doing wrong?

I don't believe it's anything wrong in your two solutions. There's simply no way these could request the behaviour you describe... without deliberately forking a second process (and you don't call fork()), or killing the time process, or hacking the kernel etc.

Perhaps your computer is broken.

It could be a bug in the chain of software which displays the output.

For example gnome-terminal 3.22 has a crash bug when fed some sequence of binary. Several versions of the Linux kernel had this great bug where sending more than 4kB over a terminal emulator ("pseudo-tty") to a read-line enabled program such as a shell, could lose some lines. Dumping 35MB of text at a time is relatively unusual.

I might try running debsums or rpm --verify -a in this case. Previously I've had weird behaviour caused by silent disk corruption.

If you can reproduce the problem with an input file of a mere 100kB, here's a different computer for you which is almost certainly not corrupted in the same way as the host computer it is run on. Console output is pretty slow, there's only a few megabytes of free space as well. The output from running your program under time will not match real seconds for some reason, it shouldn't matter for this question though. The clipboard text box doesn't accept keyboard input for me (Firefox 53), so I used the right-click menu to copy data in through /dev/clipboard as per the FAQ.

2 added 518 characters in body
source | link

Does anyone know what the problem might be or what I am doing wrong?

I don't think this should be possiblebelieve it's anything wrong in your two solutions. Perhaps There's simply no way these could request the behaviour you describe... without deliberately forking a second process (and you don't call fork()), or killing the time process, or hacking the kernel etc.

Perhaps your computer is broken.

I might try running debsums or rpm --verify -a in this case. Previously I've had weird behaviour caused by silent disk corruption.

It could also be a bug in the chain of software which displays the output.

If you can reproduce the problem with an input file of a mere 100kB, here's a different computer for you which is almost certainly not corrupted in the same way as the host computer it is run on. (Console Console output is pretty slow, there's only a few megabytes of free space as well). The output from running your program under time will not match real seconds for some reason, it shouldn't matter for this question though. The clipboard text box doesn't accept keyboard input for me (Firefox 53), so I used the right-click menu to copy data in through /dev/clipboard as per the FAQ.

I might try running debsums or rpm --verify -a in this case. Previously I've had weird behaviour caused by silent disk corruption.

I don't think this should be possible. Perhaps your computer is broken.

If you can reproduce the problem with an input file of a mere 100kB, here's a different computer for you. (Console output is pretty slow, there's only a few megabytes of free space as well). The output from running your program under time will not match real seconds for some reason. The clipboard text box doesn't accept keyboard input for me (Firefox 53), so I used the right-click menu to copy data in through /dev/clipboard as per the FAQ.

I might try running debsums or rpm --verify -a in this case. Previously I've had weird behaviour caused by silent disk corruption.

Does anyone know what the problem might be or what I am doing wrong?

I don't believe it's anything wrong in your two solutions. There's simply no way these could request the behaviour you describe... without deliberately forking a second process (and you don't call fork()), or killing the time process, or hacking the kernel etc.

Perhaps your computer is broken.

I might try running debsums or rpm --verify -a in this case. Previously I've had weird behaviour caused by silent disk corruption.

It could also be a bug in the chain of software which displays the output.

If you can reproduce the problem with an input file of a mere 100kB, here's a different computer for you which is almost certainly not corrupted in the same way as the host computer it is run on. Console output is pretty slow, there's only a few megabytes of free space as well. The output from running your program under time will not match real seconds for some reason, it shouldn't matter for this question though. The clipboard text box doesn't accept keyboard input for me (Firefox 53), so I used the right-click menu to copy data in through /dev/clipboard as per the FAQ.

1
source | link