Re: segfault during test

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: segfault during test

Rik-4
On 08/01/2012 07:40 AM, [hidden email] wrote:

> Message: 2
> Date: Wed, 1 Aug 2012 14:02:13 +0200
> From: JuanPi <[hidden email]>
> To: Octave Maintainers <[hidden email]>
> Subject: Fresh build segfault
> Message-ID:
> <[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi all,
>
> Compiling on a fresh checkout I get a segmentation fault when running
> "make check" (configured with "./configure" with no flags)
>
> Summary:
>
>   PASS     10472
>   FAIL         1
>   XFAIL        3
>
> See the file test/fntests.log for additional details.
>
> Expected failures (listed as XFAIL above) are known bugs.
> Please help improve Octave by contributing fixes for them.
>
> 356 (of 934) .m files have no tests.
>
> 0 (of 121) .cc files have no tests.
>
> Please help improve Octave by contributing tests for
> these files (see the list in the file fntests.log).
>
> panic: Segmentation fault -- stopping myself...
> panic: attempted clean up apparently failed -- aborting...
> panic: attempted clean up apparently failed -- aborting...
> attempting to save variables to `octave-workspace'...
> panic: attempted clean up apparently failed -- aborting...
> make[1]: *** [check] Aborted (core dumped)
> make[1]: Leaving directory `/home/juanpi/Projects/octave-dev/test'
> make: *** [check] Error 2
>
> Any ideas what can be causing this?
8/1/12

Juan,

I would guess that you might have cruft left over from a previous build.
For example, with the recent change to the src/ directory tree it is
possible that you have dynamically linked functions in the DLD-FUNCTIONS
directory as well as the the built-in versions in the new corefcns
directory.  It is possible that Octave is pulling in an old version of a
function which may have been compiled with different options, etc.

I would try the following from the top-level directory:
make maintainer-clean   # remove all built objects
find . -name '*.lo'    # find any library objects.  These should be deleted.
find . -name '*.la'    # find any library archives.  These should be deleted.
find . -name '*.df'    # find any definition files.  These should be deleted.

Then run the complete build cycle again
./autogen.sh
./configure
make

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: segfault during test

JuanPi
On Wed, Aug 1, 2012 at 5:26 PM, Rik <[hidden email]> wrote:

> On 08/01/2012 07:40 AM, [hidden email] wrote:
>> Message: 2
>> Date: Wed, 1 Aug 2012 14:02:13 +0200
>> From: JuanPi <[hidden email]>
>> To: Octave Maintainers <[hidden email]>
>> Subject: Fresh build segfault
>> Message-ID:
>>       <[hidden email]>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Hi all,
>>
>> Compiling on a fresh checkout I get a segmentation fault when running
>> "make check" (configured with "./configure" with no flags)
>>
>> Summary:
>>
>>   PASS     10472
>>   FAIL         1
>>   XFAIL        3
>>
>> See the file test/fntests.log for additional details.
>>
>> Expected failures (listed as XFAIL above) are known bugs.
>> Please help improve Octave by contributing fixes for them.
>>
>> 356 (of 934) .m files have no tests.
>>
>> 0 (of 121) .cc files have no tests.
>>
>> Please help improve Octave by contributing tests for
>> these files (see the list in the file fntests.log).
>>
>> panic: Segmentation fault -- stopping myself...
>> panic: attempted clean up apparently failed -- aborting...
>> panic: attempted clean up apparently failed -- aborting...
>> attempting to save variables to `octave-workspace'...
>> panic: attempted clean up apparently failed -- aborting...
>> make[1]: *** [check] Aborted (core dumped)
>> make[1]: Leaving directory `/home/juanpi/Projects/octave-dev/test'
>> make: *** [check] Error 2
>>
>> Any ideas what can be causing this?
> 8/1/12
>
> Juan,
>
> I would guess that you might have cruft left over from a previous build.
> For example, with the recent change to the src/ directory tree it is
> possible that you have dynamically linked functions in the DLD-FUNCTIONS
> directory as well as the the built-in versions in the new corefcns
> directory.  It is possible that Octave is pulling in an old version of a
> function which may have been compiled with different options, etc.
>
> I would try the following from the top-level directory:
> make maintainer-clean   # remove all built objects
> find . -name '*.lo'    # find any library objects.  These should be deleted.
> find . -name '*.la'    # find any library archives.  These should be deleted.
> find . -name '*.df'    # find any definition files.  These should be deleted.
>
> Then run the complete build cycle again
> ./autogen.sh
> ./configure
> make
>
> --Rik

Can that be? I am compiling in a repo that was checked out from scratch.


--
JuanPi Carbajal
-----
"The bad economist pursues a small present good, which will be
followed by a great evil to come, while the true economist pursues a
great good to come, at the risk of a small present evil." - Frédéric
Bastiat
-----
http://ailab.ifi.uzh.ch/carbajal/
Reply | Threaded
Open this post in threaded view
|

Re: segfault during test

Rik-4
On 08/01/2012 08:39 AM, JuanPi wrote:

> On Wed, Aug 1, 2012 at 5:26 PM, Rik <[hidden email]> wrote:
>> On 08/01/2012 07:40 AM, [hidden email] wrote:
>>> Message: 2
>>> Date: Wed, 1 Aug 2012 14:02:13 +0200
>>> From: JuanPi <[hidden email]>
>>> To: Octave Maintainers <[hidden email]>
>>> Subject: Fresh build segfault
>>> Message-ID:
>>>       <[hidden email]>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> Hi all,
>>>
>>> Compiling on a fresh checkout I get a segmentation fault when running
>>> "make check" (configured with "./configure" with no flags)
>>>
>>> Summary:
>>>
>>>   PASS     10472
>>>   FAIL         1
>>>   XFAIL        3
>>>
>>> See the file test/fntests.log for additional details.
>>>
>>> Expected failures (listed as XFAIL above) are known bugs.
>>> Please help improve Octave by contributing fixes for them.
>>>
>>> 356 (of 934) .m files have no tests.
>>>
>>> 0 (of 121) .cc files have no tests.
>>>
>>> Please help improve Octave by contributing tests for
>>> these files (see the list in the file fntests.log).
>>>
>>> panic: Segmentation fault -- stopping myself...
>>> panic: attempted clean up apparently failed -- aborting...
>>> panic: attempted clean up apparently failed -- aborting...
>>> attempting to save variables to `octave-workspace'...
>>> panic: attempted clean up apparently failed -- aborting...
>>> make[1]: *** [check] Aborted (core dumped)
>>> make[1]: Leaving directory `/home/juanpi/Projects/octave-dev/test'
>>> make: *** [check] Error 2
>>>
>>> Any ideas what can be causing this?
>> 8/1/12
>>
>> Juan,
>>
>> I would guess that you might have cruft left over from a previous build.
>> For example, with the recent change to the src/ directory tree it is
>> possible that you have dynamically linked functions in the DLD-FUNCTIONS
>> directory as well as the the built-in versions in the new corefcns
>> directory.  It is possible that Octave is pulling in an old version of a
>> function which may have been compiled with different options, etc.
>>
>> I would try the following from the top-level directory:
>> make maintainer-clean   # remove all built objects
>> find . -name '*.lo'    # find any library objects.  These should be deleted.
>> find . -name '*.la'    # find any library archives.  These should be deleted.
>> find . -name '*.df'    # find any definition files.  These should be deleted.
>>
>> Then run the complete build cycle again
>> ./autogen.sh
>> ./configure
>> make
>>
>> --Rik
> Can that be? I am compiling in a repo that was checked out from scratch.
No.  A brand new repo shouldn't have any cruft.  Is this a plain install on
a Linux machine?

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: segfault during test

JuanPi
On Wed, Aug 1, 2012 at 6:13 PM, Rik <[hidden email]> wrote:

> On 08/01/2012 08:39 AM, JuanPi wrote:
>> On Wed, Aug 1, 2012 at 5:26 PM, Rik <[hidden email]> wrote:
>>> On 08/01/2012 07:40 AM, [hidden email] wrote:
>>>> Message: 2
>>>> Date: Wed, 1 Aug 2012 14:02:13 +0200
>>>> From: JuanPi <[hidden email]>
>>>> To: Octave Maintainers <[hidden email]>
>>>> Subject: Fresh build segfault
>>>> Message-ID:
>>>>       <[hidden email]>
>>>> Content-Type: text/plain; charset=ISO-8859-1
>>>>
>>>> Hi all,
>>>>
>>>> Compiling on a fresh checkout I get a segmentation fault when running
>>>> "make check" (configured with "./configure" with no flags)
>>>>
>>>> Summary:
>>>>
>>>>   PASS     10472
>>>>   FAIL         1
>>>>   XFAIL        3
>>>>
>>>> See the file test/fntests.log for additional details.
>>>>
>>>> Expected failures (listed as XFAIL above) are known bugs.
>>>> Please help improve Octave by contributing fixes for them.
>>>>
>>>> 356 (of 934) .m files have no tests.
>>>>
>>>> 0 (of 121) .cc files have no tests.
>>>>
>>>> Please help improve Octave by contributing tests for
>>>> these files (see the list in the file fntests.log).
>>>>
>>>> panic: Segmentation fault -- stopping myself...
>>>> panic: attempted clean up apparently failed -- aborting...
>>>> panic: attempted clean up apparently failed -- aborting...
>>>> attempting to save variables to `octave-workspace'...
>>>> panic: attempted clean up apparently failed -- aborting...
>>>> make[1]: *** [check] Aborted (core dumped)
>>>> make[1]: Leaving directory `/home/juanpi/Projects/octave-dev/test'
>>>> make: *** [check] Error 2
>>>>
>>>> Any ideas what can be causing this?
>>> 8/1/12
>>>
>>> Juan,
>>>
>>> I would guess that you might have cruft left over from a previous build.
>>> For example, with the recent change to the src/ directory tree it is
>>> possible that you have dynamically linked functions in the DLD-FUNCTIONS
>>> directory as well as the the built-in versions in the new corefcns
>>> directory.  It is possible that Octave is pulling in an old version of a
>>> function which may have been compiled with different options, etc.
>>>
>>> I would try the following from the top-level directory:
>>> make maintainer-clean   # remove all built objects
>>> find . -name '*.lo'    # find any library objects.  These should be deleted.
>>> find . -name '*.la'    # find any library archives.  These should be deleted.
>>> find . -name '*.df'    # find any definition files.  These should be deleted.
>>>
>>> Then run the complete build cycle again
>>> ./autogen.sh
>>> ./configure
>>> make
>>>
>>> --Rik
>> Can that be? I am compiling in a repo that was checked out from scratch.
> No.  A brand new repo shouldn't have any cruft.  Is this a plain install on
> a Linux machine?
>
> --Rik

Hi,
The OS is
Ubuntu 12.04 LTS (GNU/Linux 3.2.0-27-generic x86_64)

gcc is
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

The segfault happens after all test are finished.

--
JuanPi Carbajal
-----
"The bad economist pursues a small present good, which will be
followed by a great evil to come, while the true economist pursues a
great good to come, at the risk of a small present evil." - Frédéric
Bastiat
-----
http://ailab.ifi.uzh.ch/carbajal/
Reply | Threaded
Open this post in threaded view
|

Re: segfault during test

Rik-4
On 08/02/2012 04:59 AM, JuanPi wrote:

> On Wed, Aug 1, 2012 at 6:13 PM, Rik <[hidden email]> wrote:
>> On 08/01/2012 08:39 AM, JuanPi wrote:
>>> On Wed, Aug 1, 2012 at 5:26 PM, Rik <[hidden email]> wrote:
>>>> On 08/01/2012 07:40 AM, [hidden email] wrote:
>>>>> Message: 2
>>>>> Date: Wed, 1 Aug 2012 14:02:13 +0200
>>>>> From: JuanPi <[hidden email]>
>>>>> To: Octave Maintainers <[hidden email]>
>>>>> Subject: Fresh build segfault
>>>>> Message-ID:
>>>>>       <[hidden email]>
>>>>> Content-Type: text/plain; charset=ISO-8859-1
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Compiling on a fresh checkout I get a segmentation fault when running
>>>>> "make check" (configured with "./configure" with no flags)
>>>>>
>>>>> Summary:
>>>>>
>>>>>   PASS     10472
>>>>>   FAIL         1
>>>>>   XFAIL        3
>>>>>
>>>>> See the file test/fntests.log for additional details.
>>>>>
>>>>> Expected failures (listed as XFAIL above) are known bugs.
>>>>> Please help improve Octave by contributing fixes for them.
>>>>>
>>>>> 356 (of 934) .m files have no tests.
>>>>>
>>>>> 0 (of 121) .cc files have no tests.
>>>>>
>>>>> Please help improve Octave by contributing tests for
>>>>> these files (see the list in the file fntests.log).
>>>>>
>>>>> panic: Segmentation fault -- stopping myself...
>>>>> panic: attempted clean up apparently failed -- aborting...
>>>>> panic: attempted clean up apparently failed -- aborting...
>>>>> attempting to save variables to `octave-workspace'...
>>>>> panic: attempted clean up apparently failed -- aborting...
>>>>> make[1]: *** [check] Aborted (core dumped)
>>>>> make[1]: Leaving directory `/home/juanpi/Projects/octave-dev/test'
>>>>> make: *** [check] Error 2
>>>>>
>>>>> Any ideas what can be causing this?
>>>> 8/1/12
>>>>
>>>> Juan,
>>>>
>>>> I would guess that you might have cruft left over from a previous build.
>>>> For example, with the recent change to the src/ directory tree it is
>>>> possible that you have dynamically linked functions in the DLD-FUNCTIONS
>>>> directory as well as the the built-in versions in the new corefcns
>>>> directory.  It is possible that Octave is pulling in an old version of a
>>>> function which may have been compiled with different options, etc.
>>>>
>>>> I would try the following from the top-level directory:
>>>> make maintainer-clean   # remove all built objects
>>>> find . -name '*.lo'    # find any library objects.  These should be deleted.
>>>> find . -name '*.la'    # find any library archives.  These should be deleted.
>>>> find . -name '*.df'    # find any definition files.  These should be deleted.
>>>>
>>>> Then run the complete build cycle again
>>>> ./autogen.sh
>>>> ./configure
>>>> make
>>>>
>>>> --Rik
>>> Can that be? I am compiling in a repo that was checked out from scratch.
>> No.  A brand new repo shouldn't have any cruft.  Is this a plain install on
>> a Linux machine?
>>
>> --Rik
> Hi,
> The OS is
> Ubuntu 12.04 LTS (GNU/Linux 3.2.0-27-generic x86_64)
>
> gcc is
> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
>
> The segfault happens after all test are finished.
>
8/2/12

Juan,

It looks like all the easy channels for debug are closed.

I would start by configuring a debug build of Octave with CFLAGS '-g -O0'.
When you have that built, run it under gdb with './run-octave -g'.
This will put you at the gdb prompt.  Type 'run' to start Octave.
When Octave has started, type 'cd test' and then 'fntests'
This will start the integrated test suite usually run by 'make check'.  If
you have separate build and src directories you will need to cd to the
actual location of fntests.m to run it.
When the tests have completed type 'exit'.  Hopefully you will produce a
segfault at that time and you can use the various facilities of gdb such as
'bt' for backtrace to see where in the Octave internals the problem came from.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: segfault during test

Jordi Gutiérrez Hermoso-2
On 2 August 2012 11:57, Rik <[hidden email]> wrote:
> I would start by configuring a debug build of Octave with CFLAGS '-g -O0'.

Don't forget CXXFLAGS='-g' too (and less importantly, FFLAGS).

- Jordi G. H.
Reply | Threaded
Open this post in threaded view
|

Re: segfault during test

John W. Eaton
Administrator
In reply to this post by Rik-4
On  2-Aug-2012, Rik wrote:

| It looks like all the easy channels for debug are closed.
|
| I would start by configuring a debug build of Octave with CFLAGS '-g -O0'.
| When you have that built, run it under gdb with './run-octave -g'.
| This will put you at the gdb prompt.  Type 'run' to start Octave.
| When Octave has started, type 'cd test' and then 'fntests'
| This will start the integrated test suite usually run by 'make check'.  If
| you have separate build and src directories you will need to cd to the
| actual location of fntests.m to run it.

Maybe we should make something like the following change?  Then we
could simplify these instructions to

  run "make check RUN_OCTAVE_FLAGS=-g", then at the (gdb) prompt type "r"

jwe


diff --git a/test/Makefile.am b/test/Makefile.am
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -58,8 +58,11 @@
 include fcn-handle-derived-resolution/module.mk
 include nest/module.mk
 
+RUN_OCTAVE := $(top_builddir)/run-octave
+RUN_OCTAVE_FLAGS := --norc --silent --no-history
+
 check: test_sparse.m test_bc_overloads.m
- $(top_builddir)/run-octave --norc --silent --no-history $(srcdir)/fntests.m $(srcdir)
+ $(RUN_OCTAVE) $(RUN_OCTAVE_FLAGS) $(srcdir)/fntests.m $(srcdir)
 
 test_sparse.m: build_sparse_tests.sh
  $(srcdir)/build_sparse_tests.sh
Reply | Threaded
Open this post in threaded view
|

Re: segfault during test

JuanPi
On Thu, Aug 2, 2012 at 6:45 PM, John W. Eaton <[hidden email]> wrote:

> On  2-Aug-2012, Rik wrote:
>
> | It looks like all the easy channels for debug are closed.
> |
> | I would start by configuring a debug build of Octave with CFLAGS '-g -O0'.
> | When you have that built, run it under gdb with './run-octave -g'.
> | This will put you at the gdb prompt.  Type 'run' to start Octave.
> | When Octave has started, type 'cd test' and then 'fntests'
> | This will start the integrated test suite usually run by 'make check'.  If
> | you have separate build and src directories you will need to cd to the
> | actual location of fntests.m to run it.
>
> Maybe we should make something like the following change?  Then we
> could simplify these instructions to
>
>   run "make check RUN_OCTAVE_FLAGS=-g", then at the (gdb) prompt type "r"
>
> jwe
>
>
> diff --git a/test/Makefile.am b/test/Makefile.am
> --- a/test/Makefile.am
> +++ b/test/Makefile.am
> @@ -58,8 +58,11 @@
>  include fcn-handle-derived-resolution/module.mk
>  include nest/module.mk
>
> +RUN_OCTAVE := $(top_builddir)/run-octave
> +RUN_OCTAVE_FLAGS := --norc --silent --no-history
> +
>  check: test_sparse.m test_bc_overloads.m
> -       $(top_builddir)/run-octave --norc --silent --no-history $(srcdir)/fntests.m $(srcdir)
> +       $(RUN_OCTAVE) $(RUN_OCTAVE_FLAGS) $(srcdir)/fntests.m $(srcdir)
>
>  test_sparse.m: build_sparse_tests.sh
>         $(srcdir)/build_sparse_tests.sh


Using ./run-octave -g after the suggested build produces no segfault.
fntests finishes normally with the summary

  PASS     10476
  FAIL         2
  XFAIL        3

However if I do "make check" I still get the segmentation fault. It is
something after fntests returns.


--
JuanPi Carbajal
-----
"The bad economist pursues a small present good, which will be
followed by a great evil to come, while the true economist pursues a
great good to come, at the risk of a small present evil." - Frédéric
Bastiat
-----
http://ailab.ifi.uzh.ch/carbajal/
Reply | Threaded
Open this post in threaded view
|

Re: segfault during test

Max Brister
On Thu, Aug 2, 2012 at 12:15 PM, JuanPi <[hidden email]> wrote:

> On Thu, Aug 2, 2012 at 6:45 PM, John W. Eaton <[hidden email]> wrote:
>> On  2-Aug-2012, Rik wrote:
>>
>> | It looks like all the easy channels for debug are closed.
>> |
>> | I would start by configuring a debug build of Octave with CFLAGS '-g -O0'.
>> | When you have that built, run it under gdb with './run-octave -g'.
>> | This will put you at the gdb prompt.  Type 'run' to start Octave.
>> | When Octave has started, type 'cd test' and then 'fntests'
>> | This will start the integrated test suite usually run by 'make check'.  If
>> | you have separate build and src directories you will need to cd to the
>> | actual location of fntests.m to run it.
>>
>> Maybe we should make something like the following change?  Then we
>> could simplify these instructions to
>>
>>   run "make check RUN_OCTAVE_FLAGS=-g", then at the (gdb) prompt type "r"
>>
>> jwe
>>
>>
>> diff --git a/test/Makefile.am b/test/Makefile.am
>> --- a/test/Makefile.am
>> +++ b/test/Makefile.am
>> @@ -58,8 +58,11 @@
>>  include fcn-handle-derived-resolution/module.mk
>>  include nest/module.mk
>>
>> +RUN_OCTAVE := $(top_builddir)/run-octave
>> +RUN_OCTAVE_FLAGS := --norc --silent --no-history
>> +
>>  check: test_sparse.m test_bc_overloads.m
>> -       $(top_builddir)/run-octave --norc --silent --no-history $(srcdir)/fntests.m $(srcdir)
>> +       $(RUN_OCTAVE) $(RUN_OCTAVE_FLAGS) $(srcdir)/fntests.m $(srcdir)
>>
>>  test_sparse.m: build_sparse_tests.sh
>>         $(srcdir)/build_sparse_tests.sh

That would be nice.

> Using ./run-octave -g after the suggested build produces no segfault.
> fntests finishes normally with the summary
>
>   PASS     10476
>   FAIL         2
>   XFAIL        3
>
> However if I do "make check" I still get the segmentation fault. It is
> something after fntests returns.

Can you try the same thing, but with
./run-octave -valgrind
instead? It will take forever to run, but valgrind is generally pretty
good about reporting memory related errors.

> --
> JuanPi Carbajal
> -----
> "The bad economist pursues a small present good, which will be
> followed by a great evil to come, while the true economist pursues a
> great good to come, at the risk of a small present evil." - Frédéric
> Bastiat
> -----
> http://ailab.ifi.uzh.ch/carbajal/

Max Brister
Reply | Threaded
Open this post in threaded view
|

Re: segfault during test

John W. Eaton
Administrator
In reply to this post by JuanPi
On  2-Aug-2012, JuanPi wrote:

| Using ./run-octave -g after the suggested build produces no segfault.
| fntests finishes normally with the summary

Weird, when I ran make check with the -g added to the run-octave
command line in the Makefile, it ended with:

  356 (of 935) .m files have no tests.

  0 (of 119) .cc files have no tests.

  Please help improve Octave by contributing tests for
  these files (see the list in the file fntests.log).


  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0x2aaac37b8700 (LWP 23076)]
  0x00002aaac12227e4 in ?? ()
  (gdb) where
  #0  0x00002aaac12227e4 in ?? ()
  #1  0x00002aaac122107e in ?? ()
  #2  0x00002aaac37b8700 in ?? ()
  #3  0x0000000000000000 in ?? ()

But I see no segfault without -g!

And this stack trace is obviously not very helpful to a mere mortal
such as myself.

jwe