Re: debugging SIGSEV on pclose
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
Re: debugging SIGSEV on pclose
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 0x0240 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 0x01b0 in ?? ()
warning: (Internal error: pc 0x1af in read in psymtab, but not in symtab.)
#4 0x61e193de in Arraydouble::nil_rep() const::nr ()
from
E:/cygwin2/pub/hg/octave_build/src/DLD-FUNCTIONS/.libs/__init_fltk__.dll
#5 0x 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
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
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
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/msg3.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
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/msg3.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
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
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.0 +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
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.0 +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
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
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
marco atzeri-4 wrote: Hi, I am trying to identify the octave segfault, last reported on http://cygwin.com/ml/cygwin-announce/2011-08/msg3.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
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
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
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
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=0x1, mode=0x1) 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
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 C005 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
debugging SIGSEV on pclose
Hi,
I am trying to identify the octave segfault, last reported on
http://cygwin.com/ml/cygwin-announce/2011-08/msg3.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
4021int
4022pclose (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 0x046c in ?? ()
#4 0x 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
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
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
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/msg3.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
4021int
4022pclose (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 0x046c in ?? ()
#4 0x 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
