Re: wait_for_file ?? [print via pipes - help testing on Windows?]

[Michael D Godfrey]

On 09/18/2010 09:30 AM, Ben Abbott wrote:

On Sep 18, 2010, at 12:12 PM, Michael D Godfrey wrote:

> On 09/18/2010 07:59 AM, Ben Abbott wrote:

>> On Sep 18, 2010, at 12:33 AM, Marco Atzeri wrote:
>> 

>>> > --- Ven 17/9/10, bpabbott <address@hidden> ha scritto:
>>> > 
>>> > This looks good to me. Does the short script below run and produce the "test.txt" file containg "Hello World"?
>>> > 
>>> >   pid = popen ("cat > test.txt", "w");
>>> >   fprintf (pid, "Hello World");
>>> >   waitpid (pid);
>>> >   pclose (pid);
>>> > 
>>> >  Ben
>>> > 
>>> > yes

>>> 

>> I recall the gl2ps renderer includes an fclose(pid). What happens with ...
>> 
>>   pid = popen ("cat > test.txt", "w");
>>   fprintf (pid, "Hello World");
>>   fclose (pid);
>>   waitpid (pid);
>>   pclose (pid);
>> 
>> Ben
>> 

> You may want to recall the requirement from "man popen":
>        The return value from popen() is a normal standard I/O stream in all respects save that it  must  be
>        closed  with  pclose() rather than fclose(3).  Writing to such a stream writes to the standard input
>        of the command; the command’s standard output is the  same  as  that  of  the  process  that  called
>        popen(),  unless this is altered by the command itself.  Conversely, reading from a "popened" stream
>        reads the command’s standard output, and the command’s standard input is the same  as  that  of  the
>        process that called popen().
> 
>        Note that output popen() streams are fully buffered by default.
> 
>        The  pclose()  function waits for the associated process to terminate and returns the exit status of
>        the command as returned by wait4(2).
> 
> ======================================
> Therefore you should be using pclose() not fclose().  But also note, as Shai
> pointed out, the call to the gl2ps code passes pid by value so the first of the 2 examples
> above is more nearly correct.  Actually, the pclose is probably not necessary, and I think
> that the gl2ps code does a waitpid before its pclose, so the waitpid may not be required
> either.   However, if control returns from the fprintf() before the gl2ps
> code has entered the section that uses the passed pid, the closes could be harmful.
> 
> Michael

I added the fclose() as an attempt to mimick the effect of the fclose() that is present in the gl2ps code.

Essentially, I'm just trying an experiment to see if fclose(pid) is the cause of the problem.

Ben

OK. I understand.  Keep in mind that your pid and the one used in the gl2ps code
are separate.  In the seg fault that I am seeing the error occurs at:
#1  0x00007ffff741125f in glps_renderer::draw (this=0xf3c650, go=...) at gl2ps-renderer.cc:83
This is an fclose(fp) where the fp was set by *fp = fdopen(fid, "wb");  The fdopen may be
what generated the "GL2PS error: Bad file pointer" error message from GL2PS.  Anyhow,
the following fclose causes the seg fault.
But I have not found where the fid was originally opened.  (It not having been open
when the fdopen was called would explain the failure.)  Also, I thought
that Shai had changed the fclose (in the case where the open was popen) to a pclose,
but just now I looked and it appears that he has not done that.

In any case I hope that Shai can figure this out!

Michael