debugging SIGSEV on pclose

debugging SIGSEV on pclose

[Marco atzeri]

Hi,
I am trying to identify the octave segfault, last reported on
http://cygwin.com/ml/cygwin-announce/2011-08/msg00003.html

To reproduce: run octave from xterm and at prompt
-------------------------
  graphics_toolkit ("fltk")
  x=1:10;
  plot(x,x)
  print("fltk.png","-dpng")
-------------------------
the plot is built and printed as file but octave crashes.


After builiding cygwin (cvs), octave and fltk with
gcc-4.5.3 I was able to identify the SIGSEV in cygwin pclose.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 5980.0x164c]
pclose (fp=0x7ffdf000) at 
/pub/cygwin/cvs/src_new/winsup/cygwin/syscalls.cc:4026
4026      if (fh->get_device () != FH_PIPEW && fh->get_device () != 
FH_PIPER)
(gdb) l
4021    int
4022    pclose (FILE *fp)
4023    {
4024      fhandler_pipe *fh = (fhandler_pipe *) cygheap->fdtab[fileno(fp)];
4025
4026      if (fh->get_device () != FH_PIPEW && fh->get_device () != 
FH_PIPER)
4027        {
4028          set_errno (EBADF);
4029          return -1;
4030        }

the pclose is relative to a single popen call:

Breakpoint 1, popen (
     command=0x207e969c "/usr/bin/gs -dQUIET -dNOPAUSE -dBATCH -dSAFER 
-sDEVICE=png16m -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r150x150 
-dEPSCrop -sOutputFile=fltk.png -", in_type=0x1a45b18 "w")
     at /pub/cygwin/cvs/src_new/winsup/cygwin/syscalls.cc:3920
3920    {

and the SIGSEV seems to happen inside NTDLL

Program received signal SIGSEGV, Segmentation fault.
0x7c90e514 in ntdll!LdrAccessResource ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) bt
#0  0x7c90e514 in ntdll!LdrAccessResource ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x7c90df5a in ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2  0x7c8025db in WaitForSingleObjectEx ()
    from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x0000046c in ?? ()
#4  0x00000000 in ?? ()
(gdb)

At this point I am really lost as I have no clue of the
popen/pclose internal interaction, so any suggestion is
really appreciated

thanks
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[jojelino]

On 2011-09-05 PM 9:20, Marco atzeri wrote:
> command=0x207e969c "/usr/bin/gs -dQUIET -dNOPAUSE -dBATCH -dSAFER
> -sDEVICE=png16m -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r150x150
> -dEPSCrop -sOutputFile=fltk.png -", in_type=0x1a45b18 "w")
> at /pub/cygwin/cvs/src_new/winsup/cygwin/syscalls.cc:3920
> 3920 {
as far as i know, -dTextAlphaBits=4 -dGraphicsAlphaBits=4 make gs crash. 
because if textalphabits is used, apple-patented font hinting is 
needed.(although freetype library implemented alternative hinting, it 
doesn't migrated to gs.) so gs calls THROW_PATENTED which uses 
longjmp(yet i can't make sure why it crashed instead of showing error 
message), there is bug report regarding to this issue(but not for this 
sigsegv). 
http://www.ghostscript.com/pipermail/gs-bugs/2009-November/010447.html
i think it would be okay if you remove textalphabits when invoking gs


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[Marco atzeri]

On 9/5/2011 3:26 PM, jojelino wrote:
> On 2011-09-05 PM 9:20, Marco atzeri wrote:
>> command=0x207e969c "/usr/bin/gs -dQUIET -dNOPAUSE -dBATCH -dSAFER
>> -sDEVICE=png16m -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r150x150
>> -dEPSCrop -sOutputFile=fltk.png -", in_type=0x1a45b18 "w")
>> at /pub/cygwin/cvs/src_new/winsup/cygwin/syscalls.cc:3920
>> 3920 {
> as far as i know, -dTextAlphaBits=4 -dGraphicsAlphaBits=4 make gs crash.
> because if textalphabits is used, apple-patented font hinting is
> needed.(although freetype library implemented alternative hinting, it
> doesn't migrated to gs.) so gs calls THROW_PATENTED which uses
> longjmp(yet i can't make sure why it crashed instead of showing error
> message), there is bug report regarding to this issue(but not for this
> sigsegv).
> http://www.ghostscript.com/pipermail/gs-bugs/2009-November/010447.html
> i think it would be okay if you remove textalphabits when invoking gs
>

Hi jojelino,
gs is unlikely crashing as the fltk.png is correctly produced.
 From strace I know that octave crashes before gs complete its output.

Are you sure about the bug number ?
http://www.ghostscript.com/pipermail/gs-bugs/2009-November/010447.html
is referring to patent expiration

Regards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[jan.kolar]

Marco, 
this is not point where octave always crashes, since in an strace dump I
sent you separately, I read
  188 145419026 [main] octave-3.4.2 11704 close: close (6)  
  31 145419057 [main] octave-3.4.2 11704 fhandler_base::close: closing
'pipe:[6]'
  34 145419091 [main] octave-3.4.2 11704 close: 0 = close (6)
which I believe to be produced by
     if (fclose (fp))
just below the code you listed.
Also you give two 'Program received signal SIGSEGV' with different
locations.

This suggests the problem is caused by an asynchronous event.
The event may come from another thread, from OS, or from a child process.

I suggest to replace gs with another program (like cat.exe with a
redirection) and 
test if that makes difference.




marco atzeri-4 wrote:
> 
> Hi,
> I am trying to identify the octave segfault, last reported on
> http://cygwin.com/ml/cygwin-announce/2011-08/msg00003.html
> 
> To reproduce: run octave from xterm and at prompt
> -------------------------
>   graphics_toolkit ("fltk")
>   x=1:10;
>   plot(x,x)
>   print("fltk.png","-dpng")
> -------------------------
> the plot is built and printed as file but octave crashes.
> 
> 
> After builiding cygwin (cvs), octave and fltk with
> gcc-4.5.3 I was able to identify the SIGSEV in cygwin pclose.
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 5980.0x164c]
> pclose (fp=0x7ffdf000) at 
> /pub/cygwin/cvs/src_new/winsup/cygwin/syscalls.cc:4026
> 4026      if (fh->get_device () != FH_PIPEW && fh->get_device () != 
> FH_PIPER)
> (gdb) l
> 4021    int
> 4022    pclose (FILE *fp)
> 4023    {
> 4024      fhandler_pipe *fh = (fhandler_pipe *)
> cygheap->fdtab[fileno(fp)];
> 4025
> 4026      if (fh->get_device () != FH_PIPEW && fh->get_device () != 
> FH_PIPER)
> 4027        {
> 4028          set_errno (EBADF);
> 4029          return -1;
> 4030        }
> 
> the pclose is relative to a single popen call:
> 
> Breakpoint 1, popen (
>      command=0x207e969c "/usr/bin/gs -dQUIET -dNOPAUSE -dBATCH -dSAFER 
> -sDEVICE=png16m -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r150x150 
> -dEPSCrop -sOutputFile=fltk.png -", in_type=0x1a45b18 "w")
>      at /pub/cygwin/cvs/src_new/winsup/cygwin/syscalls.cc:3920
> 3920    {
> 
> and the SIGSEV seems to happen inside NTDLL
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x7c90e514 in ntdll!LdrAccessResource ()
>     from /cygdrive/c/WINDOWS/system32/ntdll.dll
> (gdb) bt
> #0  0x7c90e514 in ntdll!LdrAccessResource ()
>     from /cygdrive/c/WINDOWS/system32/ntdll.dll
> #1  0x7c90df5a in ntdll!ZwWaitForSingleObject ()
>     from /cygdrive/c/WINDOWS/system32/ntdll.dll
> #2  0x7c8025db in WaitForSingleObjectEx ()
>     from /cygdrive/c/WINDOWS/system32/kernel32.dll
> #3  0x0000046c in ?? ()
> #4  0x00000000 in ?? ()
> (gdb)
> 
> At this point I am really lost as I have no clue of the
> popen/pclose internal interaction, so any suggestion is
> really appreciated
> 
> thanks
> Marco
> 
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/debugging-SIGSEV-on-pclose-tp32400695p32405194.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[Marco atzeri]

On 9/6/2011 5:20 AM, jan.kolar wrote:
>
> Marco,
> this is not point where octave always crashes, since in an strace dump I
> sent you separately, I read
>    188 145419026 [main] octave-3.4.2 11704 close: close (6)
>    31 145419057 [main] octave-3.4.2 11704 fhandler_base::close: closing
> 'pipe:[6]'
>    34 145419091 [main] octave-3.4.2 11704 close: 0 = close (6)
> which I believe to be produced by
>       if (fclose (fp))
> just below the code you listed.
> Also you give two 'Program received signal SIGSEGV' with different
> locations.
>
> This suggests the problem is caused by an asynchronous event.
> The event may come from another thread, from OS, or from a child process.
>
> I suggest to replace gs with another program (like cat.exe with a
> redirection) and
> test if that makes difference.
>
Hi Kolar,
first please no top posting on the cygwin mailing list.

Stepping within GDB, I can confirm you that the crash is happening
inside pclose.
The close reported by strace is relative to the pclose call, and the
exception is killing octave not gs.
--------------------------------------------------------------------
   232 103746055 [main] octave-3.4.2 3664 close: close (6)
    33 103746088 [main] octave-3.4.2 3664 fhandler_base::close: closing 
'pipe:[6]' handle 0x470
    33 103746121 [main] octave-3.4.2 3664 close: 0 = close (6)

   205  258249 [main] gs 2840 open: open 
(/usr/share/ghostscript/8.63/lib/gs_wan_e.ps, 0x0)
    30  258279 [main] gs 2840 normalize_posix_path: src 
/usr/share/ghostscript/8.63/lib/gs_wan_e.ps
    30  258309 [main] gs 2840 normalize_posix_path: 
/usr/share/ghostscript/8.63/lib/gs_wan_e.ps = normalize_posix_path 
(/usr/share/ghostscript/8.63/lib/gs_wan_e.ps)
    27  258336 [main] gs 2840 mount_info::conv_to_win32_path: 
conv_to_win32_path (/usr/share/ghostscript/8.63/lib/gs_wan_e.ps)
    26  258362 [main] gs 2840 set_flags: flags: binary (0x2)
    33  258395 [main] gs 2840 mount_info::conv_to_win32_path: src_path 
/usr/share/ghostscript/8.63/lib/gs_wan_e.ps, dst 
E:\cygwin2\usr\share\ghostscript\8.63\lib\gs_wan_e.ps, flags 0x3000A, rc 0
    66  258461 [main] gs 2840 symlink_info::check: 0x0 = NtCreateFile 
(\??\E:\cygwin2\usr\share\ghostscript\8.63\lib\gs_wan_e.ps)
    43  258504 [main] gs 2840 symlink_info::check: not a symlink
--- Process 3664, exception C0000005 at 610ECEFA
[long cut]
39 2360323 [main] gs 2840 pinfo::exit: Calling ExitProcess n 0x0, 
exitcode 0x0
-----------------------------------------------------------------------

stepping inside pclose, line 4026 of syscalls.cc
is where the SIGSEV is generated, but why is the nasty question

-----------------------------------------------------------------------
[long cut]
4024      fhandler_pipe *fh = (fhandler_pipe *) cygheap->fdtab[fileno(fp)];
(gdb) step
4026      if (fh->get_device () != FH_PIPEW && fh->get_device () != 
FH_PIPER)
(gdb) step
0x7c90e480 in ntdll!LdrDisableThreadCalloutsForDll ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) step
Single stepping until exit from function 
ntdll!LdrDisableThreadCalloutsForDll,
which has no line number information.
0x7c92a824 in wcstol () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) step
Single stepping until exit from function wcstol,
which has no line number information.
0x7c9033dc in ntdll!RtlCheckRegistryKey ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) step
Single stepping until exit from function ntdll!RtlCheckRegistryKey,
which has no line number information.
0x7c92a853 in wcstol () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) step
Single stepping until exit from function wcstol,
which has no line number information.
0x7c9033f8 in ntdll!RtlCheckRegistryKey ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) step
Single stepping until exit from function ntdll!RtlCheckRegistryKey,
which has no line number information.
0x7c92a858 in wcstol () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) step
Single stepping until exit from function wcstol,
which has no line number information.
0x7c901118 in ntdll!RtlUnhandledExceptionFilter ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) step
Single stepping until exit from function ntdll!RtlUnhandledExceptionFilter,
which has no line number information.
0x7c92a97b in wcstol () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) step
Single stepping until exit from function wcstol,
which has no line number information.
0x7c92f557 in ntdll!_itow () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) step
Single stepping until exit from function ntdll!_itow,
which has no line number information.
0x7c92aa01 in wcstol () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) step
Single stepping until exit from function wcstol,
which has no line number information.
0x7c910339 in ntdll!RtlInitAnsiString ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) step
Single stepping until exit from function ntdll!RtlInitAnsiString,
which has no line number information.
0x7c9102d9 in ntdll!RtlAppendStringToString ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) step
Single stepping until exit from function ntdll!RtlAppendStringToString,
which has no line number information.
0x7c90e8cb in strchr () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) step
Single stepping until exit from function strchr,
which has no line number information.
0x7c9102e5 in ntdll!RtlAppendStringToString ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) step
Single stepping until exit from function ntdll!RtlAppendStringToString,
which has no line number information.

Program received signal SIGSEGV, Segmentation fault.
0x7c90e514 in ntdll!LdrAccessResource ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
-----------------------------------------------------------------------


Regards
Marco




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[jojelino]

On 2011-09-05 PM 11:01, Marco atzeri wrote:
> Hi jojelino,
> gs is unlikely crashing as the fltk.png is correctly produced.
>  From strace I know that octave crashes before gs complete its output.
>
i'm sorry. mine was not the case.
and after some digging, it is found that fd[6] is *closed* before pclose.

warning: print.m: epstool binary is not available.
Some output formats are not available.
Hardware watchpoint 3: cygheap->fdtab.fds[6]

Old value = (fhandler_base *) 0x0
New value = (fhandler_pipe *) 0x612dbb8c
_pipe (filedes=0x22b370, psize=0x10000, mode=0x10000)
     at /tmp/winsup/winsup/cygwin/pipe.cc:382
382           filedes[0] = fdin;
(gdb) b _sigfe_fclose
Breakpoint 6 at 0x610f080b
(gdb) c
Continuing.
[New Thread 1684.0xf98]

Breakpoint 6, 0x610f080b in _sigfe_fclose ()
    from /cygdrive/d/cygwin/bin/cygwin1.dll
(gdb) bt
#0  0x610f080b in _sigfe_fclose () from /cygdrive/d/cygwin/bin/cygwin1.dll
#1  0x66f6a41f in 
cygoctinterp-0!_ZN13glps_renderer4drawERK15graphics_object ()
    from /cygdrive/d/cygwin/bin/cygoctinterp-0.dll
#2  0x6ec0ff2f in _init_fltk__-0!_ZN11OpenGL_fltk4drawEv ()
    from D:/cygwin/lib/octave/3.4.2/oct/i686-pc-cygwin/__init_fltk__.oct
#3  0x6dab19ef in cygfltk_gl-1!_ZN12Fl_Gl_Window5flushEv ()
    from /cygdrive/d/cygwin/bin/cygfltk_gl-1.1.dll
#4  0x6dae2a0f in cygfltk-1!_ZN2Fl5flushEv ()
    from /cygdrive/d/cygwin/bin/cygfltk-1.1.dll
#5  0x6dae2c28 in cygfltk-1!_ZN2Fl4waitEd ()
    from /cygdrive/d/cygwin/bin/cygfltk-1.1.dll
#6  0x6ec21272 in 
_init_fltk__-0!_ZNK21fltk_graphics_toolkit12print_figureERK15graphics_objectRKSsS4_bS4_ 
()
    from D:/cygwin/lib/octave/3.4.2/oct/i686-pc-cygwin/__init_fltk__.oct
#7  0x66ffc52b in cygoctinterp-0!_Z8FdrawnowRK17octave_value_listi ()
    from /cygdrive/d/cygwin/bin/cygoctinterp-0.dll
#8  0x67159266 in 
cygoctinterp-0!_ZN14octave_builtin17do_multi_index_opEiRK17octave_value_listPKSt4listI13octave_lvalueSaIS4_EE 
()
    from /cygdrive/d/cygwin/bin/cygoctinterp-0.dll
#9  0x67158397 in 
cygoctinterp-0!_ZN14octave_builtin7subsrefERKSsRKSt4listI17octave_value_listSaIS3_EEiPKS2_I13octave_lvalueSaIS8_EE 
()
    from /cygdrive/d/cygwin/bin/cygoctinterp-0.dll
#10 0x67159066 in 
cygoctinterp-0!_ZN14octave_builtin7subsrefERKSsRKSt4listI17oct---Type 
<return> to continue, or q <return> to quit---q
Quit
(gdb)

i think fltk have bad behavior which use fclose to close pipe fd, but it 
should have used pclose. so closing disposed fd yields sigsegv.
http://pubs.opengroup.org/onlinepubs/009695399/functions/pclose.html
we should inspect fltk's glps_renderer::draw(graphics_object const&) for 
this strange behavior.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[Marco atzeri]

On 9/8/2011 2:44 AM, jojelino wrote:
> On 2011-09-05 PM 11:01, Marco atzeri wrote:
>> Hi jojelino,
>> gs is unlikely crashing as the fltk.png is correctly produced.
>> From strace I know that octave crashes before gs complete its output.
>>
> i'm sorry. mine was not the case.
> and after some digging, it is found that fd[6] is *closed* before pclose.

correct, I was not precise:
close(6) is before the pclose call, the crash is before any
further trace activity.

>
> i think fltk have bad behavior which use fclose to close pipe fd, but it
> should have used pclose. so closing disposed fd yields sigsegv.
> http://pubs.opengroup.org/onlinepubs/009695399/functions/pclose.html
> we should inspect fltk's glps_renderer::draw(graphics_object const&) for
> this strange behavior.

Octave is using popen to excute gs and during pclose the SIGSEG arises,
fltk is not directly calling gs.

fltk could have some influence in the overall system,
like corrupting common data, or it is just one drop more
than cygwin can not handle.

I am currently using debug version of cygwin-cvs, flkt-1.10 and octave;
but unfortunaltely the gdb backtrace is already corrupted/unclear at the 
popen call, and I do not know if is real problem on a GDB issue :

-------------------------------------------------------------------------------
Breakpoint 2, popen (
     command=0x207e75cc "/usr/bin/gs -dQUIET -dNOPAUSE -dBATCH -dSAFER 
-sDEVICE=png16m -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r150x150 
-dEPSCrop -sOutputFile=fltk.png -", in_type=0x61e199f7 "w")
     at /pub/cygwin/cvs/src_new/winsup/cygwin/syscalls.cc:3920
3920    {
(gdb) bt
#0  popen (
     command=0x207e75cc "/usr/bin/gs -dQUIET -dNOPAUSE -dBATCH -dSAFER 
-sDEVICE=png16m -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r150x150 
-dEPSCrop -sOutputFile=fltk.png -", in_type=0x61e199f7 "w")
     at /pub/cygwin/cvs/src_new/winsup/cygwin/syscalls.cc:3920
#1  0x610cf2e5 in _sigfe () from /usr/bin/cygwin1.dll
warning: (Internal error: pc 0x23f in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x23f in read in psymtab, but not in symtab.)

#2  0x00000240 in ?? ()
warning: (Internal error: pc 0x23f in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x1af in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x1af in read in psymtab, but not in symtab.)

#3  0x000001b0 in ?? ()
warning: (Internal error: pc 0x1af in read in psymtab, but not in symtab.)

#4  0x61e193de in Array<double>::nil_rep() const::nr ()
    from 
E:/cygwin2/pub/hg/octave_build/src/DLD-FUNCTIONS/.libs/__init_fltk__.dll
#5  0x00000000 in ?? ()

----------------------------------------------------------------

Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[jojelino]

On 2011-09-08 PM 6:50, Marco atzeri wrote:
> I am currently using debug version of cygwin-cvs, flkt-1.10 and octave;
> but unfortunaltely the gdb backtrace is already corrupted/unclear at the
> popen call, and I do not know if is real problem on a GDB issue :
>
> -------------------------------------------------------------------------------
>
you need to do b _sigfe_popen, because the generated sigfe.s doesn't 
emit any sort of dwarf 2 cfi, which gdb needed to backtrace.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[Marco atzeri]

On 9/8/2011 12:20 PM, jojelino wrote:
> On 2011-09-08 PM 6:50, Marco atzeri wrote:
>> I am currently using debug version of cygwin-cvs, flkt-1.10 and octave;
>> but unfortunaltely the gdb backtrace is already corrupted/unclear at the
>> popen call, and I do not know if is real problem on a GDB issue :
>>
>> -------------------------------------------------------------------------------
>>
>>
> you need to do b _sigfe_popen, because the generated sigfe.s doesn't
> emit any sort of dwarf 2 cfi, which gdb needed to backtrace.
>

thanks,
very useful

Breakpoint 4, 0x610d0843 in _sigfe_pclose () from /usr/bin/cygwin1.dll
(gdb) bt
#0  0x610d0843 in _sigfe_pclose () from /usr/bin/cygwin1.dll
#1  0x61e041c5 in _fu14___ZNSs4_Rep20_S_empty_rep_storageE ()
     at ../../octave/src/DLD-FUNCTIONS/__init_fltk__.cc:166
#2  0x68441a03 in Fl_Gl_Window::flush (this=0x206bbf30) at 
Fl_Gl_Window.cxx:347
#3  0x0b68171f in flush (this=<optimized out>) at ../FL/x.H:126

and it matches the octave source code
----------------------------------------------
     if (print_mode)
       {
         FILE *fp = octave_popen (print_cmd.c_str (), "w");
         glps_renderer rend (fileno (fp), print_term);

         rend.draw (gh_manager::get_object (number));

         octave_pclose (fp);
         print_mode = false;
----------------------------------------------

regards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[Marco atzeri]

On 9/5/2011 2:20 PM, Marco atzeri wrote:
> Hi,
> I am trying to identify the octave segfault, last reported on
> http://cygwin.com/ml/cygwin-announce/2011-08/msg00003.html
>
> To reproduce: run octave from xterm and at prompt
> -------------------------
> graphics_toolkit ("fltk")
> x=1:10;
> plot(x,x)
> print("fltk.png","-dpng")
> -------------------------
> the plot is built and printed as file but octave crashes.
>
>
> After builiding cygwin (cvs), octave and fltk with
> gcc-4.5.3 I was able to identify the SIGSEV in cygwin pclose.
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 5980.0x164c]
> pclose (fp=0x7ffdf000) at
> /pub/cygwin/cvs/src_new/winsup/cygwin/syscalls.cc:4026
> 4026 if (fh->get_device () != FH_PIPEW && fh->get_device () != FH_PIPER)
> (gdb) l
> 4021 int
> 4022 pclose (FILE *fp)
> 4023 {
> 4024 fhandler_pipe *fh = (fhandler_pipe *) cygheap->fdtab[fileno(fp)];

Answering myself while kicking the head on the wall

the SIGSEV on 4026 is obvious as fh is NULL

(gdb) p fh
$7 = (fhandler_pipe *) 0x0
(gdb) p fp
$8 = (FILE *) 0x20204f94

> 4025
> 4026 if (fh->get_device () != FH_PIPEW && fh->get_device () != FH_PIPER)

Question:
is a mistake in pclose to assume that fh could be invalid

or something is just trashing cygheap->fdtab ?

Regards
Marco



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[Christopher Faylor]

On Thu, Sep 08, 2011 at 04:15:47PM +0200, Marco atzeri wrote:
>On 9/5/2011 2:20 PM, Marco atzeri wrote:
>> Hi,
>> I am trying to identify the octave segfault, last reported on
>> http://cygwin.com/ml/cygwin-announce/2011-08/msg00003.html
>>
>> To reproduce: run octave from xterm and at prompt
>> -------------------------
>> graphics_toolkit ("fltk")
>> x=1:10;
>> plot(x,x)
>> print("fltk.png","-dpng")
>> -------------------------
>> the plot is built and printed as file but octave crashes.
>>
>>
>> After builiding cygwin (cvs), octave and fltk with
>> gcc-4.5.3 I was able to identify the SIGSEV in cygwin pclose.
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 5980.0x164c]
>> pclose (fp=0x7ffdf000) at
>> /pub/cygwin/cvs/src_new/winsup/cygwin/syscalls.cc:4026
>> 4026 if (fh->get_device () != FH_PIPEW && fh->get_device () != FH_PIPER)
>> (gdb) l
>> 4021 int
>> 4022 pclose (FILE *fp)
>> 4023 {
>> 4024 fhandler_pipe *fh = (fhandler_pipe *) cygheap->fdtab[fileno(fp)];
>
>Answering myself while kicking the head on the wall
>
>the SIGSEV on 4026 is obvious as fh is NULL
>
>(gdb) p fh
>$7 = (fhandler_pipe *) 0x0
>(gdb) p fp
>$8 = (FILE *) 0x20204f94
>
>> 4025
>> 4026 if (fh->get_device () != FH_PIPEW && fh->get_device () != FH_PIPER)
>
>Question:
>is a mistake in pclose to assume that fh could be invalid

I'm not sure what you're asking here.  It's not a mistake to assume that
pclose is being passed a valid fp.  Linux also crashes if the fp is
closed twice.

>or something is just trashing cygheap->fdtab ?

Who knows?  strace should show if the fp is closed twice.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[Marco atzeri]

On 9/8/2011 4:27 PM, Christopher Faylor wrote:
> On Thu, Sep 08, 2011 at 04:15:47PM +0200, Marco atzeri wrote:

>> Question:
>> is a mistake in pclose to assume that fh could be invalid
>
> I'm not sure what you're asking here.  It's not a mistake to assume that
> pclose is being passed a valid fp.  Linux also crashes if the fp is
> closed twice.

Just as I noticed earlier on syscall.cc a defensive approuch

-----------------------------------------------
close_all_files (bool norelease)
{
   cygheap->fdtab.lock ();

   semaphore::terminate ();

   fhandler_base *fh;
   HANDLE h = NULL;

   for (int i = 0; i < (int) cygheap->fdtab.size; i++)
     if ((fh = cygheap->fdtab[i]) != NULL)
       {
------------------------------------------------

>
>> or something is just trashing cygheap->fdtab ?
>
> Who knows?  strace should show if the fp is closed twice.
>
> cgf

correct, it looks I have two close in excess for fd 5 and 6

Thanks
Marco



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[Marco atzeri]

On 9/8/2011 5:12 PM, Marco atzeri wrote:
> On 9/8/2011 4:27 PM, Christopher Faylor wrote:
>> On Thu, Sep 08, 2011 at 04:15:47PM +0200, Marco atzeri wrote:
>
>>> Question:
>>> is a mistake in pclose to assume that fh could be invalid
>>
>> I'm not sure what you're asking here. It's not a mistake to assume that
>> pclose is being passed a valid fp. Linux also crashes if the fp is
>> closed twice.
>
> Just as I noticed earlier on syscall.cc a defensive approuch
>
> -----------------------------------------------
> close_all_files (bool norelease)
> {
> cygheap->fdtab.lock ();
>
> semaphore::terminate ();
>
> fhandler_base *fh;
> HANDLE h = NULL;
>
> for (int i = 0; i < (int) cygheap->fdtab.size; i++)
> if ((fh = cygheap->fdtab[i]) != NULL)
> {
> ------------------------------------------------

using the same defensive approuch on pclose,
I see no more SEGFAULT, just some lost popen childs
that are closed on octave exit.

--- syscalls.cc~        2011-08-02 20:19:18.000000000 +0200
+++ syscalls.cc 2011-09-08 16:31:03.109375000 +0200
@@ -4023,7 +4023,7 @@
  {
    fhandler_pipe *fh = (fhandler_pipe *) cygheap->fdtab[fileno(fp)];

-  if (fh->get_device () != FH_PIPEW && fh->get_device () != FH_PIPER)
+  if ( !fh ||(fh->get_device () != FH_PIPEW && fh->get_device () != 
FH_PIPER))
      {
        set_errno (EBADF);
        return -1;


Does it make sense ?

>
>>
>>> or something is just trashing cygheap->fdtab ?
>>
>> Who knows? strace should show if the fp is closed twice.
>>
>> cgf
>
> correct, it looks I have two close in excess for fd 5 and 6
>
> Thanks
> Marco
>
>

too fast, the mismatch are the pipe closure,
that are reported differently as opening

I see a double pipe closure

$ grep 'pipe:\[5\]'  octave.strace
    24     595 [main] sh 2840 fhandler_base::fixup_after_exec: here for 
'/dev/fd/pipe:[5]'
    35 103396815 [main] octave-3.4.2 3664 fhandler_base::close: closing 
'/dev/fd/pipe:[5]' handle 0x46C
    37     896 [main] gs 2840 fhandler_base::fixup_after_exec: here for 
'/dev/fd/pipe:[5]'
    48   93072 [main] sh 2840! fhandler_base::close: closing 
'/dev/fd/pipe:[5]' handle 0x46C
    31 2358333 [main] gs 2840 fhandler_base::close: closing 
'/dev/fd/pipe:[5]' handle 0x46C

but I guess they are the two sides of the pipe


spawn_guts: 2840 = spawn_guts (/bin/sh, E:\cygwin2\bin\sh.exe -c 
"/usr/bin/gs -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=png16m 
-dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r150x150 -dEPSCrop 
-sOutputFile=plot.png -")


Marco


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[Christopher Faylor]

On Thu, Sep 08, 2011 at 06:20:26PM +0200, Marco atzeri wrote:
>On 9/8/2011 5:12 PM, Marco atzeri wrote:
>> On 9/8/2011 4:27 PM, Christopher Faylor wrote:
>>> On Thu, Sep 08, 2011 at 04:15:47PM +0200, Marco atzeri wrote:
>>
>>>> Question:
>>>> is a mistake in pclose to assume that fh could be invalid
>>>
>>> I'm not sure what you're asking here. It's not a mistake to assume that
>>> pclose is being passed a valid fp. Linux also crashes if the fp is
>>> closed twice.
>>
>> Just as I noticed earlier on syscall.cc a defensive approuch
>>
>> -----------------------------------------------
>> close_all_files (bool norelease)
>> {
>> cygheap->fdtab.lock ();
>>
>> semaphore::terminate ();
>>
>> fhandler_base *fh;
>> HANDLE h = NULL;
>>
>> for (int i = 0; i < (int) cygheap->fdtab.size; i++)
>> if ((fh = cygheap->fdtab[i]) != NULL)
>> {
>> ------------------------------------------------
>
>using the same defensive approuch on pclose,
>I see no more SEGFAULT, just some lost popen childs
>that are closed on octave exit.
>
>--- syscalls.cc~        2011-08-02 20:19:18.000000000 +0200
>+++ syscalls.cc 2011-09-08 16:31:03.109375000 +0200
>@@ -4023,7 +4023,7 @@
>  {
>    fhandler_pipe *fh = (fhandler_pipe *) cygheap->fdtab[fileno(fp)];
>
>-  if (fh->get_device () != FH_PIPEW && fh->get_device () != FH_PIPER)
>+  if ( !fh ||(fh->get_device () != FH_PIPEW && fh->get_device () != 
>FH_PIPER))
>      {
>        set_errno (EBADF);
>        return -1;
>
>
>Does it make sense ?

As I said, on Linux, if you call pclose twice in succession you get
a SEGV.  I am comfortable with Cygwin's behavior especially since you
seem to be seeing an actual program problem.

>>
>>>
>>>> or something is just trashing cygheap->fdtab ?
>>>
>>> Who knows? strace should show if the fp is closed twice.
>>>
>>> cgf
>>
>> correct, it looks I have two close in excess for fd 5 and 6
>>
>> Thanks
>> Marco
>>
>>
>
>too fast, the mismatch are the pipe closure,
>that are reported differently as opening
>
>I see a double pipe closure
>
>$ grep 'pipe:\[5\]'  octave.strace
>    24     595 [main] sh 2840 fhandler_base::fixup_after_exec: here for 
>'/dev/fd/pipe:[5]'
>    35 103396815 [main] octave-3.4.2 3664 fhandler_base::close: closing 
>'/dev/fd/pipe:[5]' handle 0x46C
>    37     896 [main] gs 2840 fhandler_base::fixup_after_exec: here for 
>'/dev/fd/pipe:[5]'
>    48   93072 [main] sh 2840! fhandler_base::close: closing 
>'/dev/fd/pipe:[5]' handle 0x46C
>    31 2358333 [main] gs 2840 fhandler_base::close: closing 
>'/dev/fd/pipe:[5]' handle 0x46C
>
>but I guess they are the two sides of the pipe

Well, one of them is in an execed process.  Some of the others are in
different processes.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[Marco atzeri]

On 9/8/2011 6:52 PM, Christopher Faylor wrote:

>
> As I said, on Linux, if you call pclose twice in succession you get
> a SEGV.  I am comfortable with Cygwin's behavior especially since you
> seem to be seeing an actual program problem.

unlikely a octave issue as it SEGFAULT's only on cygwin,
and all the other platforms are fine: Linux, BSD, Apple.

I suspect more a borderline cygwin issue that octave
is just hitting. But of course I could be wrong.

>>
>> $ grep 'pipe:\[5\]'  octave.strace
>>     24     595 [main] sh 2840 fhandler_base::fixup_after_exec: here for
>> '/dev/fd/pipe:[5]'
>>     35 103396815 [main] octave-3.4.2 3664 fhandler_base::close: closing
>> '/dev/fd/pipe:[5]' handle 0x46C
>>     37     896 [main] gs 2840 fhandler_base::fixup_after_exec: here for
>> '/dev/fd/pipe:[5]'
>>     48   93072 [main] sh 2840! fhandler_base::close: closing
>> '/dev/fd/pipe:[5]' handle 0x46C
>>     31 2358333 [main] gs 2840 fhandler_base::close: closing
>> '/dev/fd/pipe:[5]' handle 0x46C
>>
>> but I guess they are the two sides of the pipe
>
> Well, one of them is in an execed process.  Some of the others are in
> different processes.
>
> cgf

I will further look

Marco



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[Christopher Faylor]

On Thu, Sep 08, 2011 at 07:16:17PM +0200, Marco atzeri wrote:
>On 9/8/2011 6:52 PM, Christopher Faylor wrote:
>>As I said, on Linux, if you call pclose twice in succession you get a
>>SEGV.  I am comfortable with Cygwin's behavior especially since you
>>seem to be seeing an actual program problem.
>
>unlikely a octave issue as it SEGFAULT's only on cygwin, and all the
>other platforms are fine: Linux, BSD, Apple.
>
>I suspect more a borderline cygwin issue that octave is just hitting.
>But of course I could be wrong.

Sure it could be but adding a band-aid to work around the issue is not
the way to go.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[jan.kolar]

marco atzeri-4 wrote:
> 
> Hi,
> I am trying to identify the octave segfault, last reported on
> http://cygwin.com/ml/cygwin-announce/2011-08/msg00003.html
> 
> To reproduce: run octave from xterm and at prompt
> -------------------------
>   graphics_toolkit ("fltk")
>   x=1:10;
>   plot(x,x)
>   print("fltk.png","-dpng")
> -------------------------
> the plot is built and printed as file but octave crashes.
> 
> 

I think the problem is not in  fltk nor in cygwin but in octave.
fclose() that closes fd=6  is called from /usr/bin/cygoctinterp-0.dll:

Breakpoint 8, 0x6b14a41a in
cygoctinterp-0!_ZN13glps_renderer4drawERK15graphics_object () from
/usr/bin/cygoctinterp-0.dll

Recommendations:
 *  Use   popen() with added test for null fh.
     gdb is much more stable.
 * For each 'run' restart gdb.
    The program seemed to go differently on the second 'run'.



https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2010-September/020770.html
wrote:
> 
>>> Shai does drawnow() take care of closing the pipe/file? ... or should a
>>> fclose(fid) follow the drawnow. Basically, I'm confused how the
>>> pipe/file
>>> should be closed given the asynchronous behavior.
>>>
>> glps-renderer::draw does an fclose on the pipe file once it's done
>> outputting. This should take care of everything.
>> Note: it's not really asynchronous -- it all happens in one thread,
>> just not when you expect it to happen -- it might be when you call
>> drawnow, or maybe later, at the octave prompt.
>>
>> Shai
> 
> [...]
> 
> What we can do is use pclose instead of fclose in glps-renderer::draw,
> but that would mean the code would only work for pipes. Is the OK?
> 
> [...]
> I'm ready for a "hell no" ... but if pclose() will not interfere with
> GL2PS output, then 
> [...]
> 

So the problem is on the side of octave.


Breakpoint 8, 0x6b14a41a in
cygoctinterp-0!_ZN13glps_renderer4drawERK15graphics_object () from
/usr/bin/cygoctinterp-0.dll
(gdb) ni
0x6b745798 in openat_proc_name () from /usr/bin/cygoctinterp-0.dll
(gdb) ni
0x610c8dcf in _sigfe_fclose () from /usr/bin/cygwin1.dll
(gdb) ena 3 5
(gdb) c
Continuing.
Breakpoint 3, fclose (fp=0xf1952c) at
/usr/src/cygwin-1.7.9-1-merge/newlib/libc/stdio/fclose.c:116
116       return _fclose_r(_REENT, fp);
(gdb) p fp
$16 = (FILE *) 0xf1952c
(gdb) p fp->_file
$17 = 6
(gdb) p  cygheap->fdtab->fds[6]
$15 = (class fhandler_base *) 0x6124f934
(gdb) c
+c
Continuing.

Breakpoint 5, 0x610c82ca in _sigbe () from /usr/bin/cygwin1.dll
Current language:  auto; currently c++
(gdb) p  cygheap->fdtab->fds[6]
+p  cygheap->fdtab->fds[6]
$18 = (class fhandler_base *) 0x0
(gdb)
-- 
View this message in context: http://old.nabble.com/debugging-SIGSEV-on-pclose-tp32400695p32427472.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[jan.kolar]

Christopher Faylor-8 wrote:
> 
>>I suspect more a borderline cygwin issue that octave is just hitting.
>>But of course I could be wrong.
> 
> Sure it could be but adding a band-aid to work around the issue is not
> the way to go.
> 


So we have sequence
  1.   popen  
  2.   fclose   
  3.   pclose
that is done by octave, not directly for purpose, might be for convenience.

And I do not what we should expect from 2. and 3.
Should fclose() complain or close the pipe?
Is pclose() supposed to wait for the child even if the file was closed?

Sometimes its handy to signal EOF to the child (fclose?), do some
independent work
and then wait for the childs exit status (popen?).
Well, sequence 1.2.3. does not look like to serve this purpose since (I
think)
fclose(fp) is supposed to free the FILE structure so that fp is invalid
afterwards :-(

The safest seems if fclose complains(?) and does free the FILE structure.
If it sends EOF, would be nice.
What actually Linux does?

Jan
-- 
View this message in context: http://old.nabble.com/debugging-SIGSEV-on-pclose-tp32400695p32427575.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[Christopher Faylor]

On Thu, Sep 08, 2011 at 03:00:54PM -0700, jan.kolar wrote:
>Recommendations:
> *  Use   popen() with added test for null fh.
>     gdb is much more stable.
>
> * For each 'run' restart gdb.
>    The program seemed to go differently on the second 'run'.

If gdb is acting differently when restarting a program, that's a *gdb*
issue.  We don't fix gdb problems by changing Cygwin.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[jan.kolar]

Christopher Faylor-8 wrote:
> 
> On Thu, Sep 08, 2011 at 03:00:54PM -0700, jan.kolar wrote:
>>Recommendations:
>> *  Use   popen() with added test for null fh.
>>     gdb is much more stable.
>>
>> * For each 'run' restart gdb.
>>    The program seemed to go differently on the second 'run'.
> 
> If gdb is acting differently when restarting a program, that's a *gdb*
> issue.  We don't fix gdb problems by changing Cygwin.
> 

I did not mind anyone to fix gdb. Neither I said gdb is acting differently.
I just wanted to hint those around here who debug octave how to avoid a
trouble.
Neither I hoped this to be most helpfull part of the mail.

The main message was that the problem is in glps_renderer::draw ()
(and its interactions) and that there was related discussion of 
octave-maintainers last year.
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2010-September/020770.html
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2010-September/020770.html 

jk
-- 
View this message in context: http://old.nabble.com/debugging-SIGSEV-on-pclose-tp32400695p32427987.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: debugging SIGSEV on pclose

[Marco atzeri]

On 9/8/2011 8:22 PM, Christopher Faylor wrote:
> On Thu, Sep 08, 2011 at 07:16:17PM +0200, Marco atzeri wrote:
>> On 9/8/2011 6:52 PM, Christopher Faylor wrote:
>>> As I said, on Linux, if you call pclose twice in succession you get a
>>> SEGV.  I am comfortable with Cygwin's behavior especially since you
>>> seem to be seeing an actual program problem.
>>
>> unlikely a octave issue as it SEGFAULT's only on cygwin, and all the
>> other platforms are fine: Linux, BSD, Apple.
>>
>> I suspect more a borderline cygwin issue that octave is just hitting.
>> But of course I could be wrong.
>
> Sure it could be but adding a band-aid to work around the issue is not
> the way to go.
>
> cgf
>

Cgf,

If I am not fooling myself, octave sequence is this:

- popen , creating pipe 5 and 6 (handle 0x20204F9C)
   (pipe 5 is closed as the communication is unidirectional)

- fdopen (6) duplicating the handle (new handle 0x2020500C)

- a lot of writing to 6

- fclose (0x2020500C)
   this is causing fclose to call : close(6)
-----------------------------------------------
Run till exit from #0  fclose (fp=0x2020500c)
     at ../../../../../src_new/newlib/libc/stdio/fclose.c:116

Breakpoint 6, close (fd=6)
     at /pub/cygwin/cvs/src_new/winsup/cygwin/syscalls.cc:1214
------------------------------------------------

- pclose(0x20204F9C)
   that SEGFAULT's as fd=6 is already closed

The close(6) seems an abnormal beahviour of fclose as there is another
FILE handle still open.

How does cygwin track the number of open FILE handles for each
file descriptor  ?

Regards
Marco





--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple