Re: debugging SIGSEV on pclose

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

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