4.2.2 release

[John W. Eaton]

There have been about 70 changes made that address at least 50 bugs
since 4.2.1, so it's probably time for a new release.

Are there any additional *critical* bugs that should be fixed on stable
before releasing 4.2.2?

jwe

[Piotr Held]

If I can propose anything it would be:

https://savannah.gnu.org/bugs/?52274

Just because it is a segmentation fault

On Wed, Nov 8, 2017 at 11:17 AM, John W. Eaton <[hidden email]> wrote:

There have been about 70 changes made that address at least 50 bugs since 4.2.1, so it's probably time for a new release.

Are there any additional *critical* bugs that should be fixed on stable before releasing 4.2.2?

jwe

[nrjank]

On Nov 8, 2017 2:17 PM, "John W. Eaton" <[hidden email]> wrote:

Are there any additional *critical* bugs that should be fixed on stable before releasing 4.2.2?

jwe

Not at all critical, but I didn't realize this 2 line fix to pkg was still sitting awaiting review.

https://savannah.gnu.org/bugs/?48151

[Sebastian Schöps]

John W. Eaton wrote
> There have been about 70 changes made that address at least 50 bugs
> since 4.2.1, so it's probably time for a new release.
>
> Are there any additional *critical* bugs that should be fixed on stable
> before releasing 4.2.2?
>
> jwe

Maybe we could get Java 9 working for macOS?
(https://savannah.gnu.org/patch/?9439)

Sebastian



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

[Daniel Sebald]

On 11/08/2017 01:17 PM, John W. Eaton wrote:
> There have been about 70 changes made that address at least 50 bugs
> since 4.2.1, so it's probably time for a new release.
>
> Are there any additional *critical* bugs that should be fixed on stable
> before releasing 4.2.2?

I think this one is worth incorporating into 4.2.2 given that it seems
the solution is fairly straightforward to address a segfault issue on MacOS:

bug #50025: Octave window freezes when I quit Octave GUI
https://savannah.gnu.org/bugs/?50025

Crashing even when exiting is kind of annoying as history might not be
saved and if run via a script octave returning an error code could also
cause issues.

The gist of it is that the GUI should wait for the worker process to
finish ending before moving on.  I suspect on MacOS there may be a
problem of quitting the GUI when a thread is not yet finished or is
suspended.  But there may be another means of doing this rather than the
technique in the submitted patch (which itself is based on a Qt
example).  The signal could be changed to have the blocking property.
However, no one has pursued that approach because few of us use MacOS
regularly to test.

Dan

[Mike Miller-4]

On Mon, Nov 20, 2017 at 13:41:53 -0600, Daniel J Sebald wrote:
> I think this one is worth incorporating into 4.2.2 given that it seems the
> solution is fairly straightforward to address a segfault issue on MacOS:
>
> bug #50025: Octave window freezes when I quit Octave GUI
> https://savannah.gnu.org/bugs/?50025

If I remember right, there is no easy way to apply that to the stable
branch.

--
mike

[Daniel Sebald]

On 11/20/2017 01:48 PM, Mike Miller wrote:
> On Mon, Nov 20, 2017 at 13:41:53 -0600, Daniel J Sebald wrote:
>> I think this one is worth incorporating into 4.2.2 given that it seems the
>> solution is fairly straightforward to address a segfault issue on MacOS:
>>
>> bug #50025: Octave window freezes when I quit Octave GUI
>> https://savannah.gnu.org/bugs/?50025
>
> If I remember right, there is no easy way to apply that to the stable
> branch.

You're thinking that things around the exit process have been
restructured so much that we can't be sure the bug even exists on MacOS
still?

Dan

[John W. Eaton]

On 11/20/2017 02:41 PM, Daniel J Sebald wrote:

> On 11/08/2017 01:17 PM, John W. Eaton wrote:
>> There have been about 70 changes made that address at least 50 bugs
>> since 4.2.1, so it's probably time for a new release.
>>
>> Are there any additional *critical* bugs that should be fixed on
>> stable before releasing 4.2.2?
>
> I think this one is worth incorporating into 4.2.2 given that it seems
> the solution is fairly straightforward to address a segfault issue on
> MacOS:
>
> bug #50025: Octave window freezes when I quit Octave GUI
> https://savannah.gnu.org/bugs/?50025
>
> Crashing even when exiting is kind of annoying as history might not be
> saved and if run via a script octave returning an error code could also
> cause issues.
>
> The gist of it is that the GUI should wait for the worker process to
> finish ending before moving on.  I suspect on MacOS there may be a
> problem of quitting the GUI when a thread is not yet finished or is
> suspended.  But there may be another means of doing this rather than the
> technique in the submitted patch (which itself is based on a Qt
> example).  The signal could be changed to have the blocking property.
> However, no one has pursued that approach because few of us use MacOS
> regularly to test.

I remember reworking the way that the interpreter is started from the
GUI and the way things are cleaned up on exit.  I did the work on the
default branch.  Is this crash/hanging problem still present on OS X
with that branch?

jwe

[Dmitri A. Sergatskov]

On Mon, Nov 20, 2017 at 2:02 PM, John W. Eaton <[hidden email]> wrote:

On 11/20/2017 02:41 PM, Daniel J Sebald wrote:

On 11/08/2017 01:17 PM, John W. Eaton wrote:

There have been about 70 changes made that address at least 50 bugs since 4.2.1, so it's probably time for a new release.

Are there any additional *critical* bugs that should be fixed on stable before releasing 4.2.2?

I think this one is worth incorporating into 4.2.2 given that it seems the solution is fairly straightforward to address a segfault issue on MacOS:

bug #50025: Octave window freezes when I quit Octave GUI
https://savannah.gnu.org/bugs/?50025

Crashing even when exiting is kind of annoying as history might not be saved and if run via a script octave returning an error code could also cause issues.

The gist of it is that the GUI should wait for the worker process to finish ending before moving on.  I suspect on MacOS there may be a problem of quitting the GUI when a thread is not yet finished or is suspended.  But there may be another means of doing this rather than the technique in the submitted patch (which itself is based on a Qt example).  The signal could be changed to have the blocking property. However, no one has pursued that approach because few of us use MacOS regularly to test.

I remember reworking the way that the interpreter is started from the GUI and the way things are cleaned up on exit.  I did the work on the default branch.  Is this crash/hanging problem still present on OS X with that branch?

​I am not sure if this is the same problem or not, but 4.2.1 crashes on Fedora 27 after exit (either gui or octave --no-gui; octave-cli is OK)

octave:1> quit

panic: Aborted -- stopping myself...
attempting to save variables to 'octave-workspace'...
panic: attempted clean up failed -- aborting...
Aborted (core dumped)

It did not in Fedora 26. perhaps it is related to Qt up date (it is 5.9.2 in FC27)

 

jwe

​Dmitri.

--

​

[Daniel Sebald]

On 11/20/2017 02:26 PM, Dmitri A. Sergatskov wrote:

> On Mon, Nov 20, 2017 at 2:02 PM, John W. Eaton <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 11/20/2017 02:41 PM, Daniel J Sebald wrote:
>
>         On 11/08/2017 01:17 PM, John W. Eaton wrote:
>
>             There have been about 70 changes made that address at least
>             50 bugs since 4.2.1, so it's probably time for a new release.
>
>             Are there any additional *critical* bugs that should be
>             fixed on stable before releasing 4.2.2?
>
>
>         I think this one is worth incorporating into 4.2.2 given that it
>         seems the solution is fairly straightforward to address a
>         segfault issue on MacOS:
>
>         bug #50025: Octave window freezes when I quit Octave GUI
>         https://savannah.gnu.org/bugs/?50025
>         <https://savannah.gnu.org/bugs/?50025>
>
>         Crashing even when exiting is kind of annoying as history might
>         not be saved and if run via a script octave returning an error
>         code could also cause issues.
>
>         The gist of it is that the GUI should wait for the worker
>         process to finish ending before moving on.  I suspect on MacOS
>         there may be a problem of quitting the GUI when a thread is not
>         yet finished or is suspended.  But there may be another means of
>         doing this rather than the technique in the submitted patch
>         (which itself is based on a Qt example).  The signal could be
>         changed to have the blocking property. However, no one has
>         pursued that approach because few of us use MacOS regularly to test.
>
>
>     I remember reworking the way that the interpreter is started from
>     the GUI and the way things are cleaned up on exit.  I did the work
>     on the default branch.  Is this crash/hanging problem still present
>     on OS X with that branch?
>
>
>
> ​I am not sure if this is the same problem or not, but 4.2.1 crashes on
> Fedora 27 after exit (either gui or octave --no-gui; octave-cli is OK)
>
> octave:1> quit
>
> panic: Aborted -- stopping myself...
> attempting to save variables to 'octave-workspace'...
> panic: attempted clean up failed -- aborting...
> Aborted (core dumped)
>
> It did not in Fedora 26. perhaps it is related to Qt up date (it is
> 5.9.2 in FC27)

That very well may be the issue.  I posted to the bug report inquiring
if someone could check the default branch in MacOS for this problem.

Dan

[John W. Eaton]

On 11/20/2017 03:26 PM, Dmitri A. Sergatskov wrote:

> ​I am not sure if this is the same problem or not, but 4.2.1 crashes on
> Fedora 27 after exit (either gui or octave --no-gui; octave-cli is OK)
>
> octave:1> quit
>
> panic: Aborted -- stopping myself...
> attempting to save variables to 'octave-workspace'...
> panic: attempted clean up failed -- aborting...
> Aborted (core dumped)
>
> It did not in Fedora 26. perhaps it is related to Qt up date (it is
> 5.9.2 in FC27)

4.2.1 also crashes in Debian testing.  It is also linked with Qt5 (5.9.1
on my system).  I get crashes when running with the QT libs (starting
the GUI or using --no-gui) but not with --no-gui-libs.

I do not see the same behavior with the current stable sources.  I'm not
sure what changed.

Can you test to see whether this problem is also fixed on Fedora with
the current stable sources?

jwe

[Dmitri A. Sergatskov]

On Mon, Nov 20, 2017 at 2:35 PM, John W. Eaton <[hidden email]> wrote:

On 11/20/2017 03:26 PM, Dmitri A. Sergatskov wrote:

​I am not sure if this is the same problem or not, but 4.2.1 crashes on Fedora 27 after exit (either gui or octave --no-gui; octave-cli is OK)

octave:1> quit

panic: Aborted -- stopping myself...
attempting to save variables to 'octave-workspace'...
panic: attempted clean up failed -- aborting...
Aborted (core dumped)

It did not in Fedora 26. perhaps it is related to Qt up date (it is 5.9.2 in FC27)

4.2.1 also crashes in Debian testing.  It is also linked with Qt5 (5.9.1 on my system).  I get crashes when running with the QT libs (starting the GUI or using --no-gui) but not with --no-gui-libs.

I do not see the same behavior with the current stable sources.  I'm not sure what changed.

Can you test to see whether this problem is also fixed on Fedora with the current stable sources?

jwe

​I do not remember seen this problem with  dev version​ ever...

Dmitri.

--

[John W. Eaton]

On 11/20/2017 03:41 PM, Dmitri A. Sergatskov wrote:

>
>
> On Mon, Nov 20, 2017 at 2:35 PM, John W. Eaton <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 11/20/2017 03:26 PM, Dmitri A. Sergatskov wrote:
>
>         ​I am not sure if this is the same problem or not, but 4.2.1
>         crashes on Fedora 27 after exit (either gui or octave --no-gui;
>         octave-cli is OK)
>
>         octave:1> quit
>
>         panic: Aborted -- stopping myself...
>         attempting to save variables to 'octave-workspace'...
>         panic: attempted clean up failed -- aborting...
>         Aborted (core dumped)
>
>         It did not in Fedora 26. perhaps it is related to Qt up date (it
>         is 5.9.2 in FC27)
>
>
>     4.2.1 also crashes in Debian testing.  It is also linked with Qt5
>     (5.9.1 on my system).  I get crashes when running with the QT libs
>     (starting the GUI or using --no-gui) but not with --no-gui-libs.
>
>     I do not see the same behavior with the current stable sources.  I'm
>     not sure what changed.
>
>     Can you test to see whether this problem is also fixed on Fedora
>     with the current stable sources?
>
>     jwe
>
>
>
>
> ​I do not remember seen this problem with  dev version​ ever...

What about the stable branch?  Not default (which is what I think of as
dev).

jwe

[Dmitri A. Sergatskov]

On Mon, Nov 20, 2017 at 2:42 PM, John W. Eaton <[hidden email]> wrote:

    jwe




​I do not remember seen this problem with  dev version​ ever...

What about the stable branch?  Not default (which is what I think of as dev).

​I have not looked at those. I will check.​

 

jwe

​Dmitri.

​

[Dmitri A. Sergatskov]

On Mon, Nov 20, 2017 at 2:42 PM, John W. Eaton <[hidden email]> wrote:

​I do not remember seen this problem with  dev version​ ever...

What about the stable branch?  Not default (which is what I think of as dev).

​I guess I need instructions on how to get stable sources....​

 

jwe

​Dmitri.

--

​

[John W. Eaton]

On 11/20/2017 04:02 PM, Dmitri A. Sergatskov wrote:

>
>
> On Mon, Nov 20, 2017 at 2:42 PM, John W. Eaton <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>         ​I do not remember seen this problem with  dev version​ ever...
>
>
>     What about the stable branch?  Not default (which is what I think of
>     as dev).
>
>
> ​I guess I need instructions on how to get stable sources....​

After checking out the sources with hg:

   hg update stable

After that, "hg branch" should report "stable".  Then you can run
bootstrap, configure, and make as usual.

jwe

[Sebastian Schöps]

Daniel Sebald wrote
> That very well may be the issue.  I posted to the bug report inquiring
> if someone could check the default branch in MacOS for this problem.

I did. Stable still crashes on macOS (see
https://savannah.gnu.org/bugs/?50025). The problem was there pretty much
from the first day with qt5.x (I believe x>7) on stable and devel (i.e.,
default).

Bye
Sebastian



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

[Dmitri A. Sergatskov]

​Current stable is OK on FC27

​/run-octave -f -q --no-gui
octave:1> __octave_config_info__ ("hg_id")
ans = 1ad2297f8ece
octave:2> quit

released 4.2.1 (as distributed by Fedora) crashes:

/usr/bin/octave -f -q --no-gui
octave:1> __octave_config_info__ ("hg_id")
ans = 1327ea4f5a93
octave:2> quit

panic: Aborted -- stopping myself...
attempting to save variables to 'octave-workspace'...
panic: attempted clean up failed -- aborting...
Aborted (core dumped)

​Dmitri.

--

​

[John W. Eaton]

On 11/20/2017 05:01 PM, Dmitri A. Sergatskov wrote:

> ​Current stable is OK on FC27
> ​/run-octave -f -q --no-gui
> octave:1> __octave_config_info__ ("hg_id")
> ans = 1ad2297f8ece
> octave:2> quit
>
> released 4.2.1 (as distributed by Fedora) crashes:
>
>
> /usr/bin/octave -f -q --no-gui
> octave:1> __octave_config_info__ ("hg_id")
> ans = 1327ea4f5a93
> octave:2> quit
>
> panic: Aborted -- stopping myself...
> attempting to save variables to 'octave-workspace'...
> panic: attempted clean up failed -- aborting...
> Aborted (core dumped)

I see the same on Debian testing.  4.2.1 crashes at exit (always, not
just if a plot has been created) and current stable doesn't crash on
exit, with or without making a plot first.

jwe

[Daniel Sebald]

On 11/08/2017 01:17 PM, John W. Eaton wrote:
> There have been about 70 changes made that address at least 50 bugs
> since 4.2.1, so it's probably time for a new release.
>
> Are there any additional *critical* bugs that should be fixed on stable
> before releasing 4.2.2?

There are a couple textscan bugs:

https://savannah.gnu.org/bugs/?50485
https://savannah.gnu.org/bugs/?52479

the latter of which has a patch.  textscan() is fairly popular so it
might be nice to address those before a release in order to avoid
redundant bug reports, unless it doesn't really reach critical status
for minor releases.

Dan