[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Testing MinGW Octave-3.4.2 binaries
From: |
Tatsuro MATSUOKA |
Subject: |
Re: Testing MinGW Octave-3.4.2 binaries |
Date: |
Tue, 12 Jul 2011 09:21:40 +0900 (JST) |
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<address@hidden> 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.
>