On Wed, Oct 25, 2023 at 1:35 AM tom kronmiller wrote:
> On Tue, Oct 24, 2023 at 12:02 PM Max Nikulin wrote:
>
>> On 24/10/2023 12:18, tom kronmiller wrote:
>> > so I unbuffered stdin and that seemed to make it happy.
>> It might be performance killer. Even fflush(NULL) before fork() may be
>> bett
On Tue, Oct 24, 2023 at 12:02 PM Max Nikulin wrote:
> On 24/10/2023 12:18, tom kronmiller wrote:
> > so I unbuffered stdin and that seemed to make it happy.
> It might be performance killer. Even fflush(NULL) before fork() may be
> better.
>
In the real program in question, it hardly matters. I
On Tue, Oct 24, 2023 at 03:19:43PM -0400, Greg Wooledge wrote:
[...]
> This has been a most educational thread.
Absolutely. Thanks to all :)
Cheers
--
t
signature.asc
Description: PGP signature
On 25/10/2023 02:19, Greg Wooledge wrote:
At this point I still don't know *why* glibc rewinds stdin
intermittently on exit().
Consider a parent process that reads some file. When a specific keyword
appears there, it should start a child that parses the same file till
another keyword. When th
On Tue, Oct 24, 2023 at 03:19:43PM -0400, Greg Wooledge wrote:
> On Tue, Oct 24, 2023 at 11:01:55PM +0700, Max Nikulin wrote:
> > On 24/10/2023 12:18, tom kronmiller wrote:
> > > so I unbuffered stdin and that seemed to make it happy.
> >
> > It might be performance killer. Even fflush(NULL) befor
Greg Wooledge writes:
> On Tue, Oct 24, 2023 at 11:01:55PM +0700, Max Nikulin wrote:
>
> At this point, we can conclude that the bug is in fact in the OP's C
> program. The underlying C compiler, C library, and Linux kernel are
> all behaving within specs.
>
> At this point I still don't know *w
On Tue, Oct 24, 2023 at 11:01:55PM +0700, Max Nikulin wrote:
> On 24/10/2023 12:18, tom kronmiller wrote:
> > so I unbuffered stdin and that seemed to make it happy.
>
> It might be performance killer. Even fflush(NULL) before fork() may be
> better.
>
> https://stackoverflow.com/questions/501109
On 24/10/2023 12:18, tom kronmiller wrote:
so I unbuffered stdin and that seemed to make it happy.
It might be performance killer. Even fflush(NULL) before fork() may be
better.
https://stackoverflow.com/questions/50110992/why-does-forking-my-process-cause-the-file-to-be-read-infinitely
"Why
tom kronmiller wrote:
> I ended up using setvbuf(stdin, NULL, _IONBF, 0) in the parent process and
> that seems to have fixed the actual program I was having trouble with.
thomas schmitt asked:
> stdin ? Not setvbuf(stdout, NULL, _IONBF, 0) ?
Yes, stdin. The problem I was having was stdin gett
Max Nikulin [2023-10-23 23:25:33] wrote:
> On 23/10/2023 15:45, Thomas Schmitt wrote:
>> - Why no "fork() = " after the lines which show their number for the first
>> time ?
> https://stackoverflow.com/questions/2530663/printf-anomaly-after-fork
> fork clones stdout buffer and child exit flushes it
On Mon, Oct 23, 2023 at 10:45:44PM +0200, Thomas Schmitt wrote:
> Greg Wooledge wrote:
> > This is what's causing the loop to iterate more times than it should,
> > and to re-process input.
>
> That's not what i see in my experiments.
> I see stuttering output which first repeats the lines put out
Hi,
Greg Wooledge wrote:
> This is what's causing the loop to iterate more times than it should,
> and to re-process input.
That's not what i see in my experiments.
I see stuttering output which first repeats the lines put out so far
before it adds a new line.
The getline() loop iterates as often
On Mon, Oct 23, 2023 at 10:12:44PM +0200, Thomas Schmitt wrote:
> The one pointed to by Max Nikulin:
>
> > https://stackoverflow.com/questions/2530663/printf-anomaly-after-fork
> > fork clones stdout buffer and child exit flushes its content.
>
> would halfways explain what i see with unwritten d
Hi,
tom kronmiller wrote:
> I ended up using setvbuf(stdin, NULL, _IONBF, 0) in the parent process and
> that seems to have fixed the actual program I was having trouble with.
stdin ? Not setvbuf(stdout, NULL, _IONBF, 0) ?
That would be one of the weirder remedies and explanations which can be
f
I ended up using setvbuf(stdin, NULL, _IONBF, 0) in the parent process and
that seems to have fixed the actual program I was having trouble with.
On Mon, Oct 23, 2023 at 10:19 AM Thomas Schmitt wrote:
> Hi,
>
> it helps to do
> fflush((stdout);
> after each printf(), or to run before the loop:
On Mon, Oct 23, 2023 at 12:34:17PM -0400, gene heskett wrote:
[...]
> This thread seems related to a problem we've encountered when reloading an
> edited file, forcing the user to use the file->open menu to reload a program
> just edited [...]
Throw away your editor. Mine doesn't do that.
Cheer
On 10/23/23 10:16, Jon Leonard wrote:
On Mon, Oct 23, 2023 at 09:31:11AM -0400, Greg Wooledge wrote:
On Mon, Oct 23, 2023 at 11:15:22AM +0200, Thomas Schmitt wrote:
it helps to do
fflush((stdout);
after each printf(), or to run before the loop:
setvbuf(stdout, NULL, _IONBF, 0);
So it is
On 23/10/2023 15:45, Thomas Schmitt wrote:
- Why no "fork() = " after the lines which show their number for the
first time ?
https://stackoverflow.com/questions/2530663/printf-anomaly-after-fork
fork clones stdout buffer and child exit flushes its content.
On Mon, Oct 23, 2023 at 10:29:45AM -0400, tom kronmiller wrote:
> On Mon, Oct 23, 2023 at 10:16 AM Jon Leonard wrote:
>
> > More specifically, fork() does not play nicely with stdio buffering.
> >
>
> But the fork() should not be changing the address space of the calling
> process. The duplicat
On Mon, Oct 23, 2023 at 10:16 AM Jon Leonard wrote:
> More specifically, fork() does not play nicely with stdio buffering.
>
But the fork() should not be changing the address space of the calling
process. The duplicated buffers in the child process might be an issue in
general (they aren't in t
On Mon, Oct 23, 2023 at 09:31:11AM -0400, Greg Wooledge wrote:
> On Mon, Oct 23, 2023 at 11:15:22AM +0200, Thomas Schmitt wrote:
> > it helps to do
> > fflush((stdout);
> > after each printf(), or to run before the loop:
> > setvbuf(stdout, NULL, _IONBF, 0);
> >
> > So it is obvious that the u
On Mon, Oct 23, 2023 at 11:15:22AM +0200, Thomas Schmitt wrote:
> it helps to do
> fflush((stdout);
> after each printf(), or to run before the loop:
> setvbuf(stdout, NULL, _IONBF, 0);
>
> So it is obvious that the usual output buffering of printf() causes the
> repetitions of text.
Yes, it
Hi,
it helps to do
fflush((stdout);
after each printf(), or to run before the loop:
setvbuf(stdout, NULL, _IONBF, 0);
So it is obvious that the usual output buffering of printf() causes the
repetitions of text.
The loop does not do any extra cycles, as i could confirm by inserting
a stderr m
Hi,
i can reproduce the problem with the given example after changing
int main(int, char **) {
to
int main(int argc, char **argv) {
in order to get it through the compiler.
(There is also a memory leak about line_buf which does not matter now.)
Not only the read offset of stdin seems to get r
>
> Try to construct a minimal reproducer, and post it here. Someone may
> be able to spot the issue. The shorter and simpler you can make your
reproducer, the more likely someone will be able to help.
The program:
// gcc -o program program.c
// program < lines
#include
#include
#include
On Sun, Oct 22, 2023 at 10:50:15PM -0400, tom kronmiller wrote:
> I have a small program (extracted from a big program) which reads and
> prints input lines using a loop of getline() calls. The real input lines
> are all expected to be 52 characters long (+1 for the newline => 53),
> that's what m
> I have a small program (extracted from a big program) which reads and
> prints input lines using a loop of getline() calls. The real input lines
> are all expected to be 52 characters long (+1 for the newline => 53),
> that's what my example data for the small program looks like. If there is
>
I have a small program (extracted from a big program) which reads and
prints input lines using a loop of getline() calls. The real input lines
are all expected to be 52 characters long (+1 for the newline => 53),
that's what my example data for the small program looks like. If there is
no fork()
28 matches
Mail list logo
