building on macOS?

[bpabbott]

Sebastian / Andrew / others?

I’ve made the switch to Mojave. I’m able to build a functional Octave GUI, but the CLI version is crashing when building the docs.

/bin/sh run-octave --norc --silent --no-history --path /Users/bpabbott/Development/mercurial/default/sources/doc/interpreter/ --eval "geometryimages ('doc/interpreter/', 'voronoi', 'txt');"
fatal: caught signal Segmentation fault: 11 -- stopping myself...
make[2]: *** [doc/interpreter/voronoi.txt] Segmentation fault: 11
make[2]: *** Deleting file `doc/interpreter/voronoi.txt’

I’m not sure if this is due to the switch to 10.14 or due to a change to the sources. If either of you are still running 10.13, can you confirm you’re able to build the docs?

Ben

[Dmitri A. Sergatskov]

On Sun, Nov 4, 2018 at 7:11 PM Ben Abbott <[hidden email]> wrote:

Sebastian / Andrew / others?

I’ve made the switch to Mojave. I’m able to build a functional Octave GUI, but the CLI version is crashing when building the docs.

/bin/sh run-octave --norc --silent --no-history --path /Users/bpabbott/Development/mercurial/default/sources/doc/interpreter/ --eval "geometryimages ('doc/interpreter/', 'voronoi', 'txt');"
fatal: caught signal Segmentation fault: 11 -- stopping myself...
make[2]: *** [doc/interpreter/voronoi.txt] Segmentation fault: 11
make[2]: *** Deleting file `doc/interpreter/voronoi.txt’

I’m not sure if this is due to the switch to 10.14 or due to a change to the sources. If either of you are still running 10.13, can you confirm you’re able to build the docs?

What happens if you type make after the crash? Does it crash again, or

continue building?

Dmitri.

[bpabbott]

On Nov 4, 2018, at 5:13 PM, Dmitri A. Sergatskov <[hidden email]> wrote:

On Sun, Nov 4, 2018 at 7:11 PM Ben Abbott <[hidden email]> wrote:

Sebastian / Andrew / others?

I’ve made the switch to Mojave. I’m able to build a functional Octave GUI, but the CLI version is crashing when building the docs.

/bin/sh run-octave --norc --silent --no-history --path /Users/bpabbott/Development/mercurial/default/sources/doc/interpreter/ --eval "geometryimages ('doc/interpreter/', 'voronoi', 'txt');"
fatal: caught signal Segmentation fault: 11 -- stopping myself...
make[2]: *** [doc/interpreter/voronoi.txt] Segmentation fault: 11
make[2]: *** Deleting file `doc/interpreter/voronoi.txt’

I’m not sure if this is due to the switch to 10.14 or due to a change to the sources. If either of you are still running 10.13, can you confirm you’re able to build the docs?

What happens if you type make after the crash? Does it crash again, or 

continue building?

Dmitri.

Crashes again. If I run manually, the error below occurs.

geometryimages ('doc/interpreter/', 'voronoi', 'txt');

error: fputs: invalid stream number = -1

error: called from

    geometryimages>image_as_txt at line 179 column 3

    geometryimages at line 38 column 5

Seems likely something changed with Mojave (macOS 10.14). But thought I’d ask before burning my free time on this.

Ben

[bpabbott]

On Nov 4, 2018, at 5:35 PM, Ben Abbott <[hidden email]> wrote:

On Nov 4, 2018, at 5:13 PM, Dmitri A. Sergatskov <[hidden email]> wrote:

On Sun, Nov 4, 2018 at 7:11 PM Ben Abbott <[hidden email]> wrote:

Sebastian / Andrew / others?

I’ve made the switch to Mojave. I’m able to build a functional Octave GUI, but the CLI version is crashing when building the docs.

/bin/sh run-octave --norc --silent --no-history --path /Users/bpabbott/Development/mercurial/default/sources/doc/interpreter/ --eval "geometryimages ('doc/interpreter/', 'voronoi', 'txt');"
fatal: caught signal Segmentation fault: 11 -- stopping myself...
make[2]: *** [doc/interpreter/voronoi.txt] Segmentation fault: 11
make[2]: *** Deleting file `doc/interpreter/voronoi.txt’

I’m not sure if this is due to the switch to 10.14 or due to a change to the sources. If either of you are still running 10.13, can you confirm you’re able to build the docs?

What happens if you type make after the crash? Does it crash again, or 

continue building?

Dmitri.

Crashes again. If I run manually, the error below occurs.

geometryimages ('doc/interpreter/', 'voronoi', 'txt');

error: fputs: invalid stream number = -1

error: called from

    geometryimages>image_as_txt at line 179 column 3

    geometryimages at line 38 column 5

Seems likely something changed with Mojave (macOS 10.14). But thought I’d ask before burning my free time on this.

Ben

I tried generating a txt file manually. No error.

function image_as_txt (d, nm)

  fid = fopen (fullfile (d, [nm ".txt"]), "wt");

  fputs (fid, "\n");

  fputs (fid, "+---------------------------------+\n");

  fputs (fid, "| Image unavailable in text mode. |\n");

  fputs (fid, "+---------------------------------+\n");

  fclose (fid);

endfunction

image_as_txt (‘./doc/interpreter/', 'foo')

Ben

[Carlo de Falco-2]

> On 5 Nov 2018, at 03:41, Ben Abbott <[hidden email]> wrote:
> I tried generating a txt file manually. No error.
>
> function image_as_txt (d, nm)
>   fid = fopen (fullfile (d, [nm ".txt"]), "wt");
>   fputs (fid, "\n");
>   fputs (fid, "+---------------------------------+\n");
>   fputs (fid, "| Image unavailable in text mode. |\n");
>   fputs (fid, "+---------------------------------+\n");
>   fclose (fid);
> endfunction
> image_as_txt (‘./doc/interpreter/', 'foo')
>
> Ben

Ben,

I am still on HighSierra and I get something similar to you.

If I run make I get a failure :

--------------------------------------------------------------------------------------------------------------
/bin/sh run-octave --norc --silent --no-history --path /Users/carlo/Documents/_Programmi/Miei/C/octave/build-default/../octave/doc/interpreter/ --eval "geometryimages ('doc/interpreter/', 'delaunay', 'txt');"
fatal: caught signal Segmentation fault: 11 -- stopping myself...
make[2]: *** [doc/interpreter/delaunay.txt] Segmentation fault: 11
make[2]: *** Deleting file `doc/interpreter/delaunay.txt'
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
--------------------------------------------------------------------------------------------------------------

If I try to run the same command as shown in the make output manually the command works :

--------------------------------------------------------------------------------------------------------------
$ ./run-octave --no-gui
GNU Octave, version 5.0.0
Copyright (C) 2018 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-apple-darwin17.7.0".

Additional information about Octave is available at https://www.octave.org.

Please contribute if you find this software useful.
For more information, visit https://www.octave.org/get-involved.html

Read https://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.

>> addpath (canonicalize_file_name ("../octave/doc/interpreter/"))
>> geometryimages ('doc/interpreter/', 'delaunay', 'txt')
--------------------------------------------------------------------------------------------------------------

but then I get a segmentation fault when quitting Octave :

--------------------------------------------------------------------------------------------------------------
>> exit
fatal: caught signal Segmentation fault: 11 -- stopping myself...
Segmentation fault: 11
--------------------------------------------------------------------------------------------------------------

HTH,
c.

[bpabbott]

> On Nov 5, 2018, at 3:53 AM, Carlo De Falco <[hidden email]> wrote:
>
>> On 5 Nov 2018, at 03:41, Ben Abbott <[hidden email]> wrote:
>> I tried generating a txt file manually. No error.
>>
>> function image_as_txt (d, nm)
>>  fid = fopen (fullfile (d, [nm ".txt"]), "wt");
>>  fputs (fid, "\n");
>>  fputs (fid, "+---------------------------------+\n");
>>  fputs (fid, "| Image unavailable in text mode. |\n");
>>  fputs (fid, "+---------------------------------+\n");
>>  fclose (fid);
>> endfunction
>> image_as_txt (‘./doc/interpreter/', 'foo')
>>
>> Ben
>
> Ben,
>
> I am still on HighSierra and I get something similar to you.
>
> If I run make I get a failure :
>
> --------------------------------------------------------------------------------------------------------------
> /bin/sh run-octave --norc --silent --no-history --path /Users/carlo/Documents/_Programmi/Miei/C/octave/build-default/../octave/doc/interpreter/ --eval "geometryimages ('doc/interpreter/', 'delaunay', 'txt');"
> fatal: caught signal Segmentation fault: 11 -- stopping myself...
> make[2]: *** [doc/interpreter/delaunay.txt] Segmentation fault: 11
> make[2]: *** Deleting file `doc/interpreter/delaunay.txt'
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> --------------------------------------------------------------------------------------------------------------
>
> If I try to run the same command as shown in the make output manually the command works :
>
> --------------------------------------------------------------------------------------------------------------
> $ ./run-octave --no-gui
> GNU Octave, version 5.0.0
> Copyright (C) 2018 John W. Eaton and others.
> This is free software; see the source code for copying conditions.
> There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
> FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.
>
> Octave was configured for "x86_64-apple-darwin17.7.0".
>
> Additional information about Octave is available at https://www.octave.org.
>
> Please contribute if you find this software useful.
> For more information, visit https://www.octave.org/get-involved.html
>
> Read https://www.octave.org/bugs.html to learn how to submit bug reports.
> For information about changes from previous versions, type 'news'.
>
>>> addpath (canonicalize_file_name ("../octave/doc/interpreter/"))
>>> geometryimages ('doc/interpreter/', 'delaunay', 'txt')
> --------------------------------------------------------------------------------------------------------------
>
> but then I get a segmentation fault when quitting Octave :
>
> --------------------------------------------------------------------------------------------------------------
>>> exit
> fatal: caught signal Segmentation fault: 11 -- stopping myself...
> Segmentation fault: 11
> --------------------------------------------------------------------------------------------------------------
>
> HTH,
> c.

Thanks Carlo.

I recall that I often had to “make” several times to complete the docs.
Perhaps something changed recently to cause the segfault, or something changed to cause the image output to be deleted.

Looks like the deletion is part of the build process. Buried in make process I assume. Is this something we control?

Ben

[bpabbott]

> On Nov 5, 2018, at 7:18 AM, Ben Abbott <[hidden email]> wrote:
>
>> On Nov 5, 2018, at 3:53 AM, Carlo De Falco <[hidden email]> wrote:
>>
>>> On 5 Nov 2018, at 03:41, Ben Abbott <[hidden email]> wrote:
>>> I tried generating a txt file manually. No error.
>>>
>>> function image_as_txt (d, nm)
>>> fid = fopen (fullfile (d, [nm ".txt"]), "wt");
>>> fputs (fid, "\n");
>>> fputs (fid, "+---------------------------------+\n");
>>> fputs (fid, "| Image unavailable in text mode. |\n");
>>> fputs (fid, "+---------------------------------+\n");
>>> fclose (fid);
>>> endfunction
>>> image_as_txt (‘./doc/interpreter/', 'foo')
>>>
>>> Ben
>>
>> Ben,
>>
>> I am still on HighSierra and I get something similar to you.
>>
>> If I run make I get a failure :
>>
>> --------------------------------------------------------------------------------------------------------------
>> /bin/sh run-octave --norc --silent --no-history --path /Users/carlo/Documents/_Programmi/Miei/C/octave/build-default/../octave/doc/interpreter/ --eval "geometryimages ('doc/interpreter/', 'delaunay', 'txt');"
>> fatal: caught signal Segmentation fault: 11 -- stopping myself...
>> make[2]: *** [doc/interpreter/delaunay.txt] Segmentation fault: 11
>> make[2]: *** Deleting file `doc/interpreter/delaunay.txt'
>> make[1]: *** [all-recursive] Error 1
>> make: *** [all] Error 2
>> --------------------------------------------------------------------------------------------------------------
>>
>> If I try to run the same command as shown in the make output manually the command works :
>>
>> --------------------------------------------------------------------------------------------------------------
>> $ ./run-octave --no-gui
>> GNU Octave, version 5.0.0
>> Copyright (C) 2018 John W. Eaton and others.
>> This is free software; see the source code for copying conditions.
>> There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
>> FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.
>>
>> Octave was configured for "x86_64-apple-darwin17.7.0".
>>
>> Additional information about Octave is available at https://www.octave.org.
>>
>> Please contribute if you find this software useful.
>> For more information, visit https://www.octave.org/get-involved.html
>>
>> Read https://www.octave.org/bugs.html to learn how to submit bug reports.
>> For information about changes from previous versions, type 'news'.
>>
>>>> addpath (canonicalize_file_name ("../octave/doc/interpreter/"))
>>>> geometryimages ('doc/interpreter/', 'delaunay', 'txt')
>> --------------------------------------------------------------------------------------------------------------
>>
>> but then I get a segmentation fault when quitting Octave :
>>
>> --------------------------------------------------------------------------------------------------------------
>>>> exit
>> fatal: caught signal Segmentation fault: 11 -- stopping myself...
>> Segmentation fault: 11
>> --------------------------------------------------------------------------------------------------------------
>>
>> HTH,
>> c.
>
> Thanks Carlo.
>
> I recall that I often had to “make” several times to complete the docs.
> Perhaps something changed recently to cause the segfault, or something changed to cause the image output to be deleted.
>
> Looks like the deletion is part of the build process. Buried in make process I assume. Is this something we control?
>
> Ben

This problem does not occur for Octave 4.4.1

Ben

[Pantxo]

bpabbott wrote
>> On Nov 5, 2018, at 7:18 AM, Ben Abbott &lt;

> bpabbott@

> &gt; wrote:
>>
>>> On Nov 5, 2018, at 3:53 AM, Carlo De Falco &lt;

> carlo.defalco@

> &gt; wrote:
>>>
>>>> On 5 Nov 2018, at 03:41, Ben Abbott &lt;

> bpabbott@

> &gt; wrote:
>>>> I tried generating a txt file manually. No error.
>>>>
>>>> function image_as_txt (d, nm)
>>>> fid = fopen (fullfile (d, [nm ".txt"]), "wt");
>>>> fputs (fid, "\n");
>>>> fputs (fid, "+---------------------------------+\n");
>>>> fputs (fid, "| Image unavailable in text mode. |\n");
>>>> fputs (fid, "+---------------------------------+\n");
>>>> fclose (fid);
>>>> endfunction
>>>> image_as_txt (‘./doc/interpreter/', 'foo')
>>>>
>>>> Ben
>>>
>>> Ben,
>>>
>>> I am still on HighSierra and I get something similar to you.
>>>
>>> If I run make I get a failure :
>>>
>>> --------------------------------------------------------------------------------------------------------------
>>> /bin/sh run-octave --norc --silent --no-history --path
>>> /Users/carlo/Documents/_Programmi/Miei/C/octave/build-default/../octave/doc/interpreter/
>>> --eval "geometryimages ('doc/interpreter/', 'delaunay', 'txt');"
>>> fatal: caught signal Segmentation fault: 11 -- stopping myself...
>>> make[2]: *** [doc/interpreter/delaunay.txt] Segmentation fault: 11
>>> make[2]: *** Deleting file `doc/interpreter/delaunay.txt'
>>> make[1]: *** [all-recursive] Error 1
>>> make: *** [all] Error 2
>>> --------------------------------------------------------------------------------------------------------------
>>>
>>> If I try to run the same command as shown in the make output manually
>>> the command works :
>>>
>>> --------------------------------------------------------------------------------------------------------------
>>> $ ./run-octave --no-gui
>>> GNU Octave, version 5.0.0
>>> Copyright (C) 2018 John W. Eaton and others.
>>> This is free software; see the source code for copying conditions.
>>> There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
>>> FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.
>>>
>>> Octave was configured for "x86_64-apple-darwin17.7.0".
>>>
>>> Additional information about Octave is available at
>>> https://www.octave.org.
>>>
>>> Please contribute if you find this software useful.
>>> For more information, visit https://www.octave.org/get-involved.html
>>>
>>> Read https://www.octave.org/bugs.html to learn how to submit bug
>>> reports.
>>> For information about changes from previous versions, type 'news'.
>>>
>>>>> addpath (canonicalize_file_name ("../octave/doc/interpreter/"))
>>>>> geometryimages ('doc/interpreter/', 'delaunay', 'txt')
>>> --------------------------------------------------------------------------------------------------------------
>>>
>>> but then I get a segmentation fault when quitting Octave :
>>>
>>> --------------------------------------------------------------------------------------------------------------
>>>>> exit
>>> fatal: caught signal Segmentation fault: 11 -- stopping myself...
>>> Segmentation fault: 11
>>> --------------------------------------------------------------------------------------------------------------
>>>
>>> HTH,
>>> c.
>>
>> Thanks Carlo.
>>
>> I recall that I often had to “make” several times to complete the docs.
>> Perhaps something changed recently to cause the segfault, or something
>> changed to cause the image output to be deleted.
>>
>> Looks like the deletion is part of the build process. Buried in make
>> process I assume. Is this something we control?
>>
>> Ben
>
> This problem does not occur for Octave 4.4.1
>
> Ben

Hi,

There has been many changes recently including refactoring of the way
graphics toolkits are loaded, and also the way raster outputs are printed.
As a first step, could you revert to e80a87f65997 (see
https://savannah.gnu.org/bugs/?54953) and see if fixes the issue for you?

Pantxo



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

[Carlo de Falco-2]

> On 6 Nov 2018, at 08:41, Pantxo <[hidden email]> wrote:
>
> Hi,
>
> There has been many changes recently including refactoring of the way
> graphics toolkits are loaded, and also the way raster outputs are printed.
> As a first step, could you revert to e80a87f65997 (see
> https://savannah.gnu.org/bugs/?54953) and see if fixes the issue for you?
>
> Pantxo
>

Pantxo,

I reverted to e80a87f65997 which is :

$ hg log -r e80a87f65997
changeset:   26028:e80a87f65997
tag:         qparent
parent:      26026:69050723c9bd
parent:      26027:7a7c31b93216
user:        Mike Miller <[hidden email]>
date:        Wed Oct 24 15:20:43 2018 -0700
summary:     maint: merge stable to default

and made a clean build from scratch (bootstrap + configure + make)
but still get exactly the same behaviour.

Given that release 4.4.1 is working for Ben, I think if someone
has time to bisect they could use

release-4-4-1 25834:1f46d371968c

as the "good" release and e80a87f65997 as the "bad" release.

Thanks,
c.

[Pantxo]

Le mar. 6 nov. 2018 à 11:46, Carlo De Falco <[hidden email]> a écrit :

> On 6 Nov 2018, at 08:41, Pantxo <[hidden email]> wrote:
>
> Hi,
>
> There has been many changes recently including refactoring of the way
> graphics toolkits are loaded, and also the way raster outputs are printed.
> As a first step, could you revert to e80a87f65997 (see
> https://savannah.gnu.org/bugs/?54953) and see if fixes the issue for you?
>
> Pantxo
>


Pantxo,

I reverted to e80a87f65997 which is :

$ hg log -r e80a87f65997
changeset:   26028:e80a87f65997
tag:         qparent
parent:      26026:69050723c9bd
parent:      26027:7a7c31b93216
user:        Mike Miller <[hidden email]>
date:        Wed Oct 24 15:20:43 2018 -0700
summary:     maint: merge stable to default

and made a clean build from scratch (bootstrap + configure + make)
but still get exactly the same behaviour.

Given that release 4.4.1 is working for Ben, I think if someone
has time to bisect they could use

release-4-4-1 25834:1f46d371968c

as the "good" release and e80a87f65997 as the "bad" release.

Thanks,
c.

There has been successful builds on Mac more recently that 4.4.1. I think at least the following is OH since it was tested extensively by Ben:

4e108574385c 

[Carlo de Falco-2]

> On 6 Nov 2018, at 11:46, Carlo De Falco <[hidden email]> wrote:
>
>
>
>> On 6 Nov 2018, at 08:41, Pantxo <[hidden email]> wrote:
>>
>> Hi,
>>
>> There has been many changes recently including refactoring of the way
>> graphics toolkits are loaded, and also the way raster outputs are printed.
>> As a first step, could you revert to e80a87f65997 (see
>> https://savannah.gnu.org/bugs/?54953) and see if fixes the issue for you?
>>
>> Pantxo
>>
>
>
> Pantxo,
>
> I reverted to e80a87f65997 which is :
>
> $ hg log -r e80a87f65997
> changeset:   26028:e80a87f65997
> tag:         qparent
> parent:      26026:69050723c9bd
> parent:      26027:7a7c31b93216
> user:        Mike Miller <[hidden email]>
> date:        Wed Oct 24 15:20:43 2018 -0700
> summary:     maint: merge stable to default
>
> and made a clean build from scratch (bootstrap + configure + make)
> but still get exactly the same behaviour.
>
> Given that release 4.4.1 is working for Ben, I think if someone
> has time to bisect they could use
>
> release-4-4-1 25834:1f46d371968c
>
> as the "good" release and e80a87f65997 as the "bad" release.
>
> Thanks,
> c.

I can confirm that

release-4-4-1 25834:1f46d371968c

also works fine for me.

c.

[Carlo de Falco-2]

> On 6 Nov 2018, at 11:55, Pantxo Diribarne <[hidden email]> wrote:
>
> There has been successful builds on Mac more recently that 4.4.1. I think at least the following is OH since it was tested extensively by Ben:
> 4e108574385c

Indeed 4e108574385c also works for me.

So the procedure to do a bisect would be

 $ hg bisect -g 4e108574385c
 $ hg bisect -b e80a87f65997
Testing changeset 25988:e9c24b5e8673 (72 changesets remaining, ~6 tests)
77 files updated, 0 files merged, 1 files removed, 0 files unresolved

I do not have time to perform the ~6 tests needed right now, I'll try during the weekend
if no one else can do it earlier.

c.

[Carlo de Falco-2]

> On 6 Nov 2018, at 13:07, Carlo De Falco <[hidden email]> wrote:
>
>
>
>> On 6 Nov 2018, at 11:55, Pantxo Diribarne <[hidden email]> wrote:
>>
>> There has been successful builds on Mac more recently that 4.4.1. I think at least the following is OH since it was tested extensively by Ben:
>> 4e108574385c
>
> Indeed 4e108574385c also works for me.
>
> So the procedure to do a bisect would be
>
> $ hg bisect -g 4e108574385c
> $ hg bisect -b e80a87f65997
> Testing changeset 25988:e9c24b5e8673 (72 changesets remaining, ~6 tests)
> 77 files updated, 0 files merged, 1 files removed, 0 files unresolved
>
> I do not have time to perform the ~6 tests needed right now, I'll try during the weekend
> if no one else can do it earlier.
>
> c.

I actually did try some steps of bisection and the latest changeset I tested was 41f665343437
at this chageset sources do not build but the failure I get is different :


Undefined symbols for architecture x86_64:
  "octave::resource_manager::instance_ok()", referenced from:
      annotation_dialog::init() in __init_qt___la-annotation-dialog.o
      annotation_dialog::button_clicked(QAbstractButton*) in __init_qt___la-annotation-dialog.o
  "octave::resource_manager::instance", referenced from:
      annotation_dialog::init() in __init_qt___la-annotation-dialog.o
      annotation_dialog::button_clicked(QAbstractButton*) in __init_qt___la-annotation-dialog.o
  "octave::resource_manager::do_get_settings() const", referenced from:
      annotation_dialog::init() in __init_qt___la-annotation-dialog.o
      annotation_dialog::button_clicked(QAbstractButton*) in __init_qt___la-annotation-dialog.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libgui/graphics/__init_qt__.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


anyone else seen anything like that?

c.

[Dmitri A. Sergatskov]

Back to the original problem. Just now building the latest tip on linux with make -j8 I got:

<<<<

  GEN      doc/interpreter/splinefit3.png
  GEN      doc/interpreter/splinefit4.png
  GEN      doc/interpreter/splinefit6.png
  MAKEINFO ../doc/interpreter/octave.info
  TEXI2DVI doc/interpreter/octave.dvi
  MAKEINFO doc/interpreter/octave.html/.octave-html-stamp
/usr/bin/texi2dvi: etex exited with bad status, quitting.
make[2]: *** [Makefile:30580: doc/interpreter/octave.dvi] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/d2/home/dima/src/octave/gcc_def'
make[1]: *** [Makefile:26948: all-recursive] Error 1
make[1]: Leaving directory '/d2/home/dima/src/octave/gcc_def'
make: *** [Makefile:10811: all] Error 2
>>>>

Re-running "make -j8" :

<<<<

GEN      doc/interpreter/octave.html/splinefit4.png
  GEN      doc/interpreter/octave.html/splinefit6.png
  GEN      doc/interpreter/octave.html/octave.css
  GEN      doc/interpreter/octave_interpreter.qhc
  TEXI2DVI doc/interpreter/octave.dvi
/usr/bin/texi2dvi: etex exited with bad status, quitting.
make[2]: *** [Makefile:30580: doc/interpreter/octave.dvi] Error 1
make[2]: Leaving directory '/d2/home/dima/src/octave/gcc_def'
make[1]: *** [Makefile:26948: all-recursive] Error 1
make[1]: Leaving directory '/d2/home/dima/src/octave/gcc_def'
make: *** [Makefile:10811: all] Error 2
>>>>

Running "make V=1" -- finished building w/o problem.

This is on Fedora 29.

Dmitri.

--

[Sebastian Schöps]

Dmitri A. Sergatskov wrote
> Running "make V=1" -- finished building w/o problem.
> This is on Fedora 29.

I have the same issue on macOS (default branch, with Gui) and "make V=1"
does not help here...
...
/bin/sh run-octave --norc --silent --no-history --path
/private/tmp/octave-octave-app-20181106-78235-s9u83m/doc/interpreter/ --eval
"interpimages ('doc/interpreter/', 'interpn', 'txt');"
fatal: caught signal Segmentation fault: 11 -- stopping myself...

Sebastian



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

[Carlo de Falco-2]

> On 6 Nov 2018, at 22:41, Sebastian Schöps <[hidden email]> wrote:
>
> Dmitri A. Sergatskov wrote
>> Running "make V=1" -- finished building w/o problem.
>> This is on Fedora 29.
>
> I have the same issue on macOS (default branch, with Gui) and "make V=1"
> does not help here...
> ...
> /bin/sh run-octave --norc --silent --no-history --path
> /private/tmp/octave-octave-app-20181106-78235-s9u83m/doc/interpreter/ --eval
> "interpimages ('doc/interpreter/', 'interpn', 'txt');"
> fatal: caught signal Segmentation fault: 11 -- stopping myself...
>
> Sebastian

I completed the bisection search, this seems to be the first bad revision for me :

$ hg bisect -g
The first bad revision is:
changeset:   25994:332be8be16eb
user:        John W. Eaton <[hidden email]>
date:        Fri Sep 28 18:18:09 2018 -0400
summary:     dynamically load qt graphics


can someone confirm that a00379f6f8c4 builds correctly while 332be8be16eb fails?

c.

[John W. Eaton]

On 11/06/2018 05:12 PM, Carlo De Falco wrote:

>
>
>> On 6 Nov 2018, at 22:41, Sebastian Schöps <[hidden email]> wrote:
>>
>> Dmitri A. Sergatskov wrote
>>> Running "make V=1" -- finished building w/o problem.
>>> This is on Fedora 29.
>>
>> I have the same issue on macOS (default branch, with Gui) and "make V=1"
>> does not help here...
>> ...
>> /bin/sh run-octave --norc --silent --no-history --path
>> /private/tmp/octave-octave-app-20181106-78235-s9u83m/doc/interpreter/ --eval
>> "interpimages ('doc/interpreter/', 'interpn', 'txt');"
>> fatal: caught signal Segmentation fault: 11 -- stopping myself...
>>
>> Sebastian
>
> I completed the bisection search, this seems to be the first bad revision for me :
>
> $ hg bisect -g
> The first bad revision is:
> changeset:   25994:332be8be16eb
> user:        John W. Eaton <[hidden email]>
> date:        Fri Sep 28 18:18:09 2018 -0400
> summary:     dynamically load qt graphics
>
>
> can someone confirm that a00379f6f8c4 builds correctly while 332be8be16eb fails?

Can someone also run the failing version under gdb or get a core file
and run gdb on that and the octave-gui executable and see where the
segfault happens?

jwe

[bpabbott]

> On Nov 6, 2018, at 15:38, John W. Eaton <[hidden email]> wrote:
>
> On 11/06/2018 05:12 PM, Carlo De Falco wrote:
>>> On 6 Nov 2018, at 22:41, Sebastian Schöps <[hidden email]> wrote:
>>>
>>> Dmitri A. Sergatskov wrote
>>>> Running "make V=1" -- finished building w/o problem.
>>>> This is on Fedora 29.
>>>
>>> I have the same issue on macOS (default branch, with Gui) and "make V=1"
>>> does not help here...
>>> ...
>>> /bin/sh run-octave --norc --silent --no-history --path
>>> /private/tmp/octave-octave-app-20181106-78235-s9u83m/doc/interpreter/ --eval
>>> "interpimages ('doc/interpreter/', 'interpn', 'txt');"
>>> fatal: caught signal Segmentation fault: 11 -- stopping myself...
>>>
>>> Sebastian
>> I completed the bisection search, this seems to be the first bad revision for me :
>> $ hg bisect -g
>> The first bad revision is:
>> changeset:   25994:332be8be16eb
>> user:        John W. Eaton <[hidden email]>
>> date:        Fri Sep 28 18:18:09 2018 -0400
>> summary:     dynamically load qt graphics
>> can someone confirm that a00379f6f8c4 builds correctly while 332be8be16eb fails?
>
> Can someone also run the failing version under gdb or get a core file and run gdb on that and the octave-gui executable and see where the segfault happens?
>
> jwe

Apple’s clang supports lldb. run-octave needs to be adjusted to use lldb.

I was looking at this yesterday. I think all the needed translation info is at the link below.

https://lldb.llvm.org/lldb-gdb.html

Ben

[bpabbott]

On Nov 6, 2018, at 3:54 PM, Ben Abbott <[hidden email]> wrote:

On Nov 6, 2018, at 15:38, John W. Eaton <[hidden email]> wrote:

On 11/06/2018 05:12 PM, Carlo De Falco wrote:

On 6 Nov 2018, at 22:41, Sebastian Schöps <[hidden email]> wrote:

Dmitri A. Sergatskov wrote

Running "make V=1" -- finished building w/o problem.
This is on Fedora 29.

I have the same issue on macOS (default branch, with Gui) and "make V=1"
does not help here...
...
/bin/sh run-octave --norc --silent --no-history --path
/private/tmp/octave-octave-app-20181106-78235-s9u83m/doc/interpreter/ --eval
"interpimages ('doc/interpreter/', 'interpn', 'txt');"
fatal: caught signal Segmentation fault: 11 -- stopping myself...

Sebastian

I completed the bisection search, this seems to be the first bad revision for me :
$ hg bisect -g
The first bad revision is:
changeset:   25994:332be8be16eb
user:        John W. Eaton <[hidden email]>
date:        Fri Sep 28 18:18:09 2018 -0400
summary:     dynamically load qt graphics
can someone confirm that a00379f6f8c4 builds correctly while 332be8be16eb fails?

Can someone also run the failing version under gdb or get a core file and run gdb on that and the octave-gui executable and see where the segfault happens?

jwe

Apple’s clang supports lldb. run-octave needs to be adjusted to use lldb.

I was looking at this yesterday. I think all the needed translation info is at the link below.

https://lldb.llvm.org/lldb-gdb.html

Ben

In the lldb debugger, octave exists with 

Process 79077 exited with status = 0 (0x00000000) Terminated due to signal 5

For rev  the attached log results when I run manually.

Ben

[Sebastian Schöps]

Carlo de Falco-2 wrote
> $ hg bisect -g
> The first bad revision is:
> changeset:   25994:332be8be16eb
> user:        John W. Eaton &lt;

> jwe@

> &gt;
> date:        Fri Sep 28 18:18:09 2018 -0400
> summary:     dynamically load qt graphics
>
> can someone confirm that a00379f6f8c4 builds correctly while 332be8be16eb
> fails?

so far I can confirm that a00379f6f8c4 builds correctly.

Sebastian



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