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
s
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
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
close 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.
--
=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, 0x610c8
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.
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 al
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 invali
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
p
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
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
>> --
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("flt
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 :
---
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 :
--
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 fou
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 pclo
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 1
ystem32/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:
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_ne
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
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")
--
21 matches
Mail list logo
