Re: Testing MinGW Octave-3.4.2 binaries

[Tatsuro MATSUOKA]

Hello

On my environment, windows 7 64 bit HomePremium,
The 'clear all' command seems not induce crash.

octave:1> clear all
octave:2>

I will test them on the another computers.

Regards

Tatsuro

--- On Mon, 2011/7/11, Philip Nienhuis <address@hidden> wrote:

> 
> Philip Nienhuis-3 wrote:
> > 
> > Jordi Gutiérrez Hermoso wrote:
> >> On 7 July 2011 17:13, Philip Nienhuis&lt;address@hidden&gt;  wrote:
> >>
> >>> 1. "clear all" leads to a complete crash.
> >>
> >> Under all circumstances?
> > 
> > Always.
> > 
> 
> No, I was wrong: when all traces of the windows package are gone (i.e.,
> unload it, then uninstall it and only then restart Octave) "clear all" works
> OK. 
> Just a "pkg unload windows" is not sufficient.
> 
> Using a debug build, I found that the crash happens in symtab.h, when
> clear_cmdline_function.islocked() is called. Commenting that out &
> recompiling & again running in gdb, I see that the crash (signal) now occurs
> at the next statement.
> That makes me suspicious that something is clobbered up before the call to
> clear_cmdline_function(). Unfortunately I have little experience with gdb,
> so this will take some time to sort out.
> 
> BTW  I made a debug build to sort out other issues with the windows package.
> So this issue actually belongs in the Oct-Dev mailing list (where I already
> have a thread about this).
> 
> 
> 
> 
> >>> 2.  A Matlab script, made by a colleague, that I'm porting to Octave
> >>> creates 34 pictures. On some PC's, using fltk, doing "close all"
> >>> leads to a similar crash as 1. (above)
> >>
> >> This is a long standing race condition with fltk, and I think it's the
> >> biggest thing we have to fix before we switch the default plotting
> >> engine from gnuplot to fltk. Known problem, also happens outside of
> >> Windows.
> > <snip>
> > 
> 
> It can't reproduce this anymore. I can't find the cause.
> As this is at work, I have little time investigating.
> So just forget about this.
> 
> 
> 
> >>> 3. With that script, again on some PCs only, using fltk, titles
> >>> appear only on the first plot. Using gnuplot all plots get the
> >>> proper titles.
> >>>
> >>> 4. Again, on some PCs only, text output in fltk pics is gibberish.
> >>> May be due to lacking fonts - I haven't had time to investigate.
> >>> Gnuplot plots are fine.
> >>
> >> These two may be again more UB symptoms of the same race condition.
> >> Does the stupid workaround described above also work on these?
> > 
> > I'll check at work tomorrow (if I've got time).
> > 
> 
> Regarding the fonts (issue 3): This is a matter of default font setting in
> Octave that seems to be wrong for our work PCs. I don't know how to adapt
> this from the Octave side.
> As this is on a fairly locked down office PC from my employer I can't do
> much about fonts stuff from that side.
> 
> Issue 4: Can't reproduce it anymore.
> In hindsight I think my work PC was a bit overloaded when I tried - IIRC the
> mail system crashed at the end of the day as well.
> So let's forget about this one as well.
> 
> 
> All in all I think Tatsuro's binary works quite good for me. The only issues
> left are #3 and #5 in my original post (edit.m). AFAICS the workaround for
> #5 (using double backslash in the EDITOR string) is "stable".
> 
> In Benjamin's version 3.2.4-MinGW there were issues with the sse3 atlas lib
> with complex arithmetic. Hopefully this is solved now.
> 
> 
> Philip
> 
> --
> View this message in context: 
> http://octave.1599824.n4.nabble.com/Testing-MinGW-Octave-3-4-2-binaries-tp3652644p3659682.html
> Sent from the Octave - Maintainers mailing list archive at Nabble.com.
>