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
