Re: debugging SIGSEV on pclose

["jan.kolar" <kolar at math dot cas dot cz>]

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