bugGNU Octave - Bugs: bug #61821, segfault using tree_parameter_list...


bug #61821: segfault using tree_parameter_list in oct file

Submitter:  None
Submitted:  Fri 14 Jan 2022 09:38:29 AM UTC
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 7.0.90
Operating System:  * Microsoft Windows
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Tue 15 Mar 2022 04:16:08 PM UTC, comment #28: 

Agreed, there is no rush to use std::chrono or std::filesystem but it would be nice to be able to use standard C++ library features if possible.

John W. Eaton <jwe>
Project Administrator
Tue 15 Mar 2022 04:09:01 PM UTC, comment #27: 

That definitely looks interesting. Especially the file system library might help to get rid of some of our platform specific code.
Afaict, the chrono library could replace the functionality that we currently use from the ctime header. However, those parts require C++20. That is still pretty new. And I don't know if it's worth maintaining implementations using the "old" C version (<ctime>) and the "new" C++ version (<chrono>) of the same functionality side by side to still support older compilers/STLs.

Anyway, imho those changes are out of scope of this bug report. (But we should keep them in mind for the future.)

Closing as fixed since our CI still seems to be fine, and the changes avoided the crash for me on Windows 32-bit with the original reproducer.

Markus Mützel <mmuetzel>
Project Member
Mon 14 Mar 2022 04:13:09 PM UTC, comment #26: 

Markus, I was looking at these descriptions:


Some time classes are part of C++11, most are C++20.  The filesystem classes appear to all be C++17.

However, depending on how time objects are defined and how we use them, I suppose they could still present alignment issues for us.

John W. Eaton <jwe>
Project Administrator
Sun 13 Mar 2022 06:35:46 PM UTC, comment #25: 

@jwe: Thanks for taking a look at this.
Could you please give a pointer to the C++17 time libraries that we could potentially use?

Markus Mützel <mmuetzel>
Project Member
Sat 12 Mar 2022 08:06:20 PM UTC, comment #24: 

This change seems like a reasonable solution for now.  Maybe when we require C++ 17 we can use the C++ filesystem and time libraries.

John W. Eaton <jwe>
Project Administrator
Sat 12 Mar 2022 03:30:40 PM UTC, comment #23: 

No comments in a couple of weeks. So, I'm assuming no one has strong feelings against making that change on the stable branch.

I pushed the changes (after a slight cleanup) here:

Marking as ready for test.

Markus Mützel <mmuetzel>
Project Member
Sun 27 Feb 2022 11:26:04 AM UTC, comment #22: 

I compiled with that patch for 32bit Windows. The reproducer from comment #0 no longer crashes Octave. And the test suite still passes.

Markus Mützel <mmuetzel>
Project Member
Sat 26 Feb 2022 01:17:44 PM UTC, comment #21: 

Oops. That should say `OCTAVE_TIME_T` where I wrote `OCTAVE_TYPE_T` in comment #20.

Markus Mützel <mmuetzel>
Project Member
Sat 26 Feb 2022 01:04:18 PM UTC, comment #20: 

Attached is a patch that removes `time_t` from Octave's (public) API.
I opted for using a pre-processor `define` (instead of a `typedef`) so that packages or user code that might be affected by this change could switch over to using `OCTAVE_TYPE_T` and add something like the following to be backward compatible:

#  define OCTAVE_TYPE_T time_t

I don't know if something similarly straight-forward would be possible if we use a `typedef` instead.

The nature of the issue requires to make a "hard cut" and remove the functions that take `time_t` arguments without deprecating them. If we kept them around for a few versions, the API-header mismatch would still be an issue. (Or am I missing something?)

The GitHub-CI still succeeded with these changes on Linux, Windows and MacOS. The latter seems to have a 32-bit wide `time_t` type. So, I'm hopeful that those changes will work on platforms with either a 32-bit or a 64-bit `time_t` type.

I haven't checked if this would actually prevent the crash reported here. But IIUC what the actual issue is, I'd guess it would.

I based that patch on the stable branch. But I'd like to get feedback before pushing it anywhere.

(file #52935)

Markus Mützel <mmuetzel>
Project Member
Thu 24 Feb 2022 07:16:19 PM UTC, comment #19: 

It may be useful to use gdb to print the layout of the classes "octave_user_function" and "octave_user_code" when time_t is 64 bit.
"time_t" is used in class "octave::sys::time". "octave_user_code" has two members "m_t_parsed" and "m_t_checked" of type "octave::sys::time".
There is another macro _USE_32BIT_TIME_T that can be used to change the type of time_t.

(gdb)  ptype /o 'octave_user_function'
/* offset      |    size */  type = class octave_user_function : public octave_user_code {
/*    208      |       4 */    octave::tree_parameter_list *m_param_list;
/*    212      |       4 */    octave::tree_parameter_list *m_ret_list;
/*    216      |       4 */    octave::comment_list *m_lead_comm;
/*    220      |       4 */    octave::comment_list *m_trail_comm;
/*    224      |       4 */    int m_location_line;
/*    228      |       4 */    int m_location_column;
/*    232      |       4 */    int m_end_location_line;
/*    236      |       4 */    int m_end_location_column;
/*    240      |       1 */    bool m_system_fcn_file;
/* XXX  3-byte hole      */
/*    244      |       4 */    int m_num_named_args;
/*    248      |       1 */    bool m_subfunction;
/*    249      |       1 */    bool m_inline_function;
/*    250      |       1 */    bool m_anonymous_function;
/*    251      |       1 */    bool m_nested_function;
/*    252      |       4 */    octave_user_function::class_method_type m_class_constructor;
/*    256      |       4 */    octave_user_function::class_method_type m_class_method;
                               static int t_id;
                               static const std::string t_name;
                               static const std::string c_name;
/* XXX  4-byte padding   */

                               /* total size (bytes):  264 */

(gdb)  ptype /o 'octave_user_code'
/* offset      |    size */  type = class octave_user_code : public octave_function {
/*    132      |       8 */    class octave::symbol_scope {
/*    132      |       8 */        class std::shared_ptr<octave::symbol_scope_rep>
    [with _Tp = octave::symbol_scope_rep]
        : public std::__shared_ptr<_Tp, (__gnu_cxx::_Lock_policy)2> {

                                       /* total size (bytes):    8 */
                                   } m_rep;

                                   /* total size (bytes):    8 */
                               } m_scope;
/*    140      |      24 */    std::string m_file_name;
/* XXX  4-byte hole      */
/*    168      |      16 */    class octave::sys::time {
/*    168      |       8 */        time_t m_ot_unix_time;
/*    176      |       4 */        long m_ot_usec;
/* XXX  4-byte padding   */

                                   /* total size (bytes):   16 */
                               } m_t_parsed;
/*    184      |      16 */    class octave::sys::time {
/*    184      |       8 */        time_t m_ot_unix_time;
/*    192      |       4 */        long m_ot_usec;
/* XXX  4-byte padding   */

                                   /* total size (bytes):   16 */
                               } m_t_checked;
/*    200      |       4 */    octave::file_info *m_file_info;
/*    204      |       4 */    octave::tree_statement_list *m_cmd_list;

                               /* total size (bytes):  208 */

Thu 24 Feb 2022 04:07:34 PM UTC, comment #18: 

Nice find! Thank you.

Are those problematic types in `oct-time.h`? That's the only (public) header I found that is using this type.

Could we just change the types of those member variables to `int64_t` and have it cast to the correct type implicitly when calling the corresponding C functions (or wrappers) on systems where `time_t` is 32 bits wide?

Markus Mützel <mmuetzel>
Project Member
Thu 24 Feb 2022 03:52:57 PM UTC, comment #17: 

Thanks for finding the reason for this problem.  Longer term, I would like to ensure that system dependencies like this do not affect the layout of Octave classes.  I don't think we want to define things like __MINGW_USE_VC5005_COMPAT in octave-config.h but instead see whether we can hide time_t completely from the public interface for Octave classes.

John W. Eaton <jwe>
Project Administrator
Thu 24 Feb 2022 05:36:05 AM UTC, comment #16: 

The problem is related to:

#define __MINGW_USE_VC2005_COMPAT 1

that is defined in "config.h" but not in "octave-config.h".
This option makes time_t a 64 bit integer and without it time_t will be defined as a 32 bit integer.
time_t is used in one of sub-objects of octave_user_function and therefore octave_user_function will have two different layouts when building Octave and when building a .oct file.
I placed the definition of __MINGW_USE_VC2005_COMPAT in the test source and it compiles and runs without any error.

Wed 23 Feb 2022 10:32:53 PM UTC, comment #15: 

I installed the msys based Octave following the instructions in comment #13. octave --gui works but the test case results in segfault.
octave-cli cannot execute any command. As shown in the attached screenshot after typing disp(1) it does nothing and it cannot even return to the command prompt.

Wed 23 Feb 2022 05:39:57 PM UTC, comment #14: 

Thanks for the installation instructions! I understand the correct way of installation is what you explained but I extracted the artifact to the installation folder to get results faster!!! Sorry.

In the case of the offset I concentrate on Octave 7. I also used gdb to add break-points line by line and as explained in comment #10 I found that instead of  "m_ret_list" the memebr "m_end_location_line" is changed by "octave_user_function::define_ret_list". The data member octave_user_function::m_end_location_line is placed in higher offset than octave_user_function::m_ret_list. Using some tricks I found the offset of m_ret_list that is 0xc0 but the offset 0xd4 is somewhere between the offset of m_end_location_line and the next member.

I used Process Monitor from Sysinternals[1] to inspect the compiler options that are used when using ./configure & make.
The problematic option is -DHAVE_CONFIG_H .
I compiled ov-usr-fcn.cc with and without -DHAVE_CONFIG_H. Without -DHAVE_CONFIG_H the offset ,correctly, is computed as 0xc0 and with -DHAVE_CONFIG_H the offset ,wrongly, is computed as 0xd4.

[1] https://docs.microsoft.com/en-us/sysinternals/

Wed 23 Feb 2022 10:20:50 AM UTC, comment #13: 

Sorry, I haven't been clearer before. You shouldn't mix the MSYS2 version with the "official" version of Octave for Windows.
Instead, install an MSYS2 environment, run their bash (for their MINGW32 environment) and execute the following commands:

pacman -Syu  # might update the bash itself. So, you'll need to run it again after restarting the bash to get the "actual" updates.
pacman -Syu
# In the folder where you extracted the build artifact:
pacman -U mingw-w64-i686-octave-7.0.90-1-any

# start that Octave to do your tests:
octave --gui

You might want to install their compiler as well:

pacman -S mingw-w64-i686-cc

Also: I'm not sure how you determined which are the offsets in the classes of both versions. Octave 6 and Octave 7 are not ABI compatible, and it might be correct that the offsets are different in both versions.

Markus Mützel <mmuetzel>
Project Member
Tue 22 Feb 2022 09:32:49 PM UTC, comment #12: 

Thanks! I downloaded the artifact and extracted it into the official installed alpha version. Some of dependencies are different between the official and the artifact so I placed the required libraries and I now can run octave but the test case results in segfault.
I decided to compile ov-usr-fcn.cc manually. I used the command shell of the official alpha version. The only used compiler options was -O2.
Two errors were generated:

-line 647  "Fwarning"  should be replaced by "octave::Fwarning"
-line 885  "set_internal_variable" should be replaced by "octave::set_internal_variable"

After correcting the errors and compiling I inspected the disassembly of "octave_user_function::define_ret_list".

00001570 <__ZN20octave_user_function15define_ret_listEPN6octave19tree_parameter_listE>:
    1570:        8b 54 24 04                  mov    0x4(%esp),%edx
    1574:        89 c8                        mov    %ecx,%eax
    1576:        89 91 c0 00 00 00            mov    %edx,0xc0(%ecx)
    157c:        c2 04 00                     ret    $0x4
    157f:        90                           nop

It shows that the code is correctly generated and 0xc0 is generated instead of 0xd4.

Using the same shell I used ./configure and make to build Octave. Wonderfully no compiler error was generated when building "ov-usr-fcn.cc". The disassembly of "liboctave_value_la-ov-usr-fcn.o" shows that the code is wrongly generated:

00001590 <__ZN20octave_user_function15define_ret_listEPN6octave19tree_parameter_listE>:
    1590:        8b 54 24 04                  mov    0x4(%esp),%edx
    1594:        89 c8                        mov    %ecx,%eax
    1596:        89 91 d4 00 00 00            mov    %edx,0xd4(%ecx)
    159c:        c2 04 00                     ret    $0x4
    159f:        90                           nop

I broke the make process and corrected "ov-usr-fcn.cc" and executed make again but the generated code still is wrong.
So it may be a configure/compiler option that forces gcc to generate wrong code?!

Tue 22 Feb 2022 02:37:37 PM UTC, comment #11: 

Thank you for hunting this down.

Just to give some background: The "official" Octave for Windows isn't compiled with the compiler that is included in its installation. Instead, it is cross-compiled on Linux with a cross-compiler that is built in the packaging process by MXE Octave. [1]
The compiler that is bundled with Octave for Windows is also cross-compiled on Linux (for a mingw host and target).

There is another version of Octave that is built natively on Windows (e.g. using the tools of the MINGW32 environment) as part of the MSYS2 project. [2]
That is pretty new. And tbh, we didn't get much feedback for that version yet.
That project also uses GCC. But the build tools and compiler version and configuration might be different. And maybe that bug only occurs when Octave was cross-compiled.
If you are interested, maybe you could test if that version of Octave on Windows also exhibits that strange behavior for 32-bit.

The version currently distributed by MSYS2 is Octave 6.4.0. But you could try with the build artifacts of the first release candidate. [3]

[1]: https://hg.octave.org/mxe-octave/
[2]: https://www.msys2.org/
[3]: https://github.com/mmuetzel/MINGW-packages/actions/runs/1664815400

Markus Mützel <mmuetzel>
Project Member
Fri 21 Jan 2022 04:37:20 AM UTC, comment #10: 

Inspecting function arguments and return values shows that octave_user_function::define_ret_list() doesn't work correctly. The function signature is:

octave_user_function *
octave_user_function::define_ret_list (octave::tree_parameter_list *t)
  m_ret_list = t;

  return this;

 I extracted the disassembly of "define_ret_list" both for Octave 6.3.0 and 7.0.90 (It's the first time I am using assembly):

Octave 6.3.0

0x00edabb0 <+0>:     mov    0x4(%esp),%edx
0x00edabb4 <+4>:     mov    %ecx,%eax
0x00edabb6 <+6>:     mov    %edx,0xc0(%ecx)
0x00edabbc <+12>:    ret    $0x4
0x00edabbf <+15>:    nop

Octave 7.0.90

0x00df95a0 <+0>:     mov    0x4(%esp),%edx
0x00df95a4 <+4>:     mov    %ecx,%eax
0x00df95a6 <+6>:     mov    %edx,0xd4(%ecx)
0x00df95ac <+12>:    ret    $0x4
0x00df95af <+15>:    nop

It computes the offset of "m_ret_list" from the beginning of the class and puts "t" in that address. In Octave 6.3.0 the offset is correctly computed as 0xc0 while for Octave 7.0.90 it wrongly computed as 0xd4, therefore define_ret_list(t)  puts "t" in a wrong address. Actually instead of changing the member "m_ret_list" it changes "m_end_location_line".

It appears that GCC 11.2.0 that bundled with Octave 7.0.90 has a bug.

Mon 17 Jan 2022 03:09:55 PM UTC, comment #9: 

> I think that segfault can be explained by symbol visibility.

Rest assured that Octave 7 (including 7.0.90) for Windows is not compiled with visibility flags. All symbols are exported (just like in prior versions of Octave).

Markus Mützel <mmuetzel>
Project Member
Mon 17 Jan 2022 02:56:36 PM UTC, comment #8: 

Regarding the comment #3:

>Is it possible to see your application or package that does not work with the restricted symbol visibility?

Sure! I think you have seen it: https://github.com/shsajjadi/OctaveCoder

Please consider that I don't want to impose my package and I think there are possibly a limited number of packages that depend on such non public features. Therefor if disabling the visibility makes Octave more faster and reliable go forward and close this issue as won't fix.

I think that segfault can be explained by symbol visibility. Both coder and the example encounter segfault permanently.

I have relatively limited insight and some of the contents of my previous comment are from googling. My writing skill is also limited, sorry!
I periodically fill bugs anonymously and provide some suggestions that some of them has been rejected.

Discourse is a good place for such discussions. I can suggest multiple ideas here or on discourse about Octave but discussion should be converted to sensible result (code). I know that there are a few developers here that don't have time even to respond to bug reports. I appreciate your efforts of Octave development. Thank you very much!

Mon 17 Jan 2022 02:18:12 PM UTC, comment #7: 

Tried again with the 32-bit version of Octave. With it, I can reproduce the crash.

Top of the backtrace:

(gdb) c
[Thread 3448.0x3ee8 exited with code 0]
[Thread 3448.0x1a3c exited with code 0]
[New Thread 3448.0x5644]

Thread 18 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 3448.0x54c0]
0x6c08172d in std::__cxx11::list<octave::tree_decl_elt*, std::allocator<octave::tree_decl_elt*> >::empty (this=<optimized out>) at d:/svn/octave/test/octave~2.90-/octave~1.90-/mingw32/lib/gcc/i686-w64-mingw32/11.2.0/include/c++/bits/stl_list.h:1056
1056          { return this->_M_impl._M_node._M_next == &this->_M_impl._M_node; }
(gdb) bt
#0  0x6c08172d in std::__cxx11::list<octave::tree_decl_elt*, std::allocator<octave::tree_decl_elt*> >::empty (
    this=<optimized out>)
    at d:/svn/octave/test/octave~2.90-/octave~1.90-/mingw32/lib/gcc/i686-w64-mingw32/11.2.0/include/c++/bits/stl_list.h:1056
#1  octave::base_list<octave::tree_decl_elt*>::empty (this=<optimized out>)
    at d:/svn/octave/test/octave~2.90-/octave~1.90-/mingw32/include/octave-7.0.90/octave/base-list.h:50
#2  Fparams (args=..., nargout=0) at params.cc:15
#3  0x6ea1009c in liboctinterp-9!_ZN14octave_builtin7executeERN6octave14tree_evaluatorEiRK17octave_value_list ()
   from D:\SVN\Octave\test\OCTAVE~2.90-\OCTAVE~1.90-\mingw32\bin\liboctinterp-9.dll
#4  0x6ea4722e in liboctinterp-9!_ZN15octave_function4callERN6octave14tree_evaluatorEiRK17octave_value_list ()
   from D:\SVN\Octave\test\OCTAVE~2.90-\OCTAVE~1.90-\mingw32\bin\liboctinterp-9.dll
#5  0x6eb19e40 in liboctinterp-9!_ZN6octave15tree_identifier10evaluate_nERNS_14tree_evaluatorEi ()
   from D:\SVN\Octave\test\OCTAVE~2.90-\OCTAVE~1.90-\mingw32\bin\liboctinterp-9.dll
#6  0x6f092e75 in liboctinterp-9!_ZN6octave15tree_identifier8evaluateERNS_14tree_evaluatorEi ()
   from D:\SVN\Octave\test\OCTAVE~2.90-\OCTAVE~1.90-\mingw32\bin\liboctinterp-9.dll
#7  0x6eb15c9f in liboctinterp-9!_ZN6octave14tree_evaluator15visit_statementERNS_14tree_statementE ()
   from D:\SVN\Octave\test\OCTAVE~2.90-\OCTAVE~1.90-\mingw32\bin\liboctinterp-9.dll
#8  0x6eb04d89 in liboctinterp-9!_ZN6octave14tree_evaluator20visit_statement_listERNS_19tree_statement_listE ()
   from D:\SVN\Octave\test\OCTAVE~2.90-\OCTAVE~1.90-\mingw32\bin\liboctinterp-9.dll
#9  0x6eb062ed in liboctinterp-9!_ZN6octave14tree_evaluator4evalERSt10shared_ptrINS_19tree_statement_listEEb ()
   from D:\SVN\Octave\test\OCTAVE~2.90-\OCTAVE~1.90-\mingw32\bin\liboctinterp-9.dll
#10 0x6eb11f76 in liboctinterp-9!_ZN6octave14tree_evaluator4replEv ()
   from D:\SVN\Octave\test\OCTAVE~2.90-\OCTAVE~1.90-\mingw32\bin\liboctinterp-9.dll
#11 0x6edd04eb in liboctinterp-9!_ZN6octave11interpreter7executeEv ()
   from D:\SVN\Octave\test\OCTAVE~2.90-\OCTAVE~1.90-\mingw32\bin\liboctinterp-9.dll
#12 0x6c30b7e0 in liboctgui-6!_ZN6octave19interpreter_qobject7executeEv ()
   from D:\SVN\Octave\test\OCTAVE~2.90-\OCTAVE~1.90-\mingw32\bin\liboctgui-6.dll
#13 0x66b20bbd in ZN14QMetaCallEvent13placeMetaCallEP7QObject ()
   from D:\SVN\Octave\test\OCTAVE~2.90-\OCTAVE~1.90-\mingw32\bin\Qt5Core.dll

Markus Mützel <mmuetzel>
Project Member
Mon 17 Jan 2022 02:08:47 PM UTC, comment #6: 

No crash here:

GNU Octave, version 7.0.90
Copyright (C) 2021-2022 The Octave Project Developers.
This is free software; see the source code for copying conditions.
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-w64-mingw32".

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'.

>> mkoctfile params.cc
>> params
ans = 1
>> a=params
a = 1

Markus Mützel <mmuetzel>
Project Member
Mon 17 Jan 2022 01:57:12 PM UTC, comment #5: 

@mmuetzel: Can you reproduce the problem of comment #0?

Kai Torben Ohlhus <siko1056>
Project Member
Mon 17 Jan 2022 12:39:51 PM UTC, comment #4: 

Compiling with visibility flags isn't completely implemented for Octave 7. It is disabled by default (and only thought to be used by developers at this point).
Any help in completing that task is very much appreciated. Preferably in the form of patches submitted to savannah. (Please open new reports for those if you like.)

Since the version of Octave for Windows is not compiled with visibility flags (i.e., it's exporting all symbols indiscriminately), that's probably not the cause for the issue in comment #0.

Markus Mützel <mmuetzel>
Project Member
Mon 17 Jan 2022 12:16:56 PM UTC, comment #3: 

The issue seems to be larger than the toy example.  Luckily for this reason Octave's release candidates are for: finding problems before the official release 🙂  Thus thanks for trying out in time.

Is it possible to see your application or package that does not work with the restricted symbol visibility?

You seem to have lots of insight into MS Windows DLL development.
 Would you like to join in the dicussion on Octave Discourse?

Just for the sake of completenes: does the toy example of the original post cause reliably a segmentation fault on MS Windows, as I cannot reproduce it?

Kai Torben Ohlhus <siko1056>
Project Member
Mon 17 Jan 2022 11:44:52 AM UTC, comment #2: 

Thank you for your attention!
I'm on Windows 7 32-bit. I downloaded octave-7.0.90-w32.7z from alpha.gnu.org.
Initially my guess was the issue may be a config bug or it possibly may be related to gcc bug but after I found that it may be related to visibility of symbols. I searched the bug archive for the "visibility" word and received to these threads:
  oct-file has an undefined symbol https://savannah.gnu.org/bugs/?60567
  build fails on macOS with visibility settings  https://savannah.gnu.org/bugs/?59820  

From there I reached to this discourse topic:  

Previously I used to think I could use all headers that shipped with Octave to develop packages/stand-alone programs. However I currently is noticed that only those functions and classes that are explicitly tagged with macros like OCTARRAY_API and  OCTINTERP_API are parts of the official interface to oct API. With the recent decision all symbols, other than the tagged symbols, of the Octave core libraries are made hidden (using a gcc capability). Therefore it is very difficult and painful to develop packages that are relied on those non tagged functions, if it is not impossible! The workaround may be including Octave source codes in the packages or fetch them from the repository when building the packages. However the workaround may fail because the linker may refer to fake symbols in the core dlls and refuse to using the compiled sources.
All package maintainer should check the package sources line by line to find those abandoned features, otherwise the packages compiles successfully but in the runtime may encounter segfault.
I also have found some buggy features. Consider this example:

// A.h
struct A


  void func (const A& a = A())

I have defined two classes "A" and "B" that one of them , "B", is a part of public API and the other, "A", isn't. The constructor of "A" will be defined in "A.cpp". However "B" is using "A" from its member function. Calling "func ()" results in segfault because it is using "A" that isn't a part of API. I have seen such classes in Octave source tree. Even "B" is a part of the public API it won't be usable at all.

There are possibly some issues related to import libraries that needs further checks.

Mon 17 Jan 2022 08:42:35 AM UTC, comment #1: 

With the information given, I cannot crash Octave.

I saved the given code in a file "params.cc" on MS Windows 10 (21H2), and using Octave 6.4.0, 7.0.90, 7.0.91 (each w64), I get:

>> mkoctfile params.cc
>> params
ans = 1

The code itself also does not look suspicious, even though the code digs deep into Octave internals.

Is the oct file recompiled for each used Octave version?  There is no perfect binary compatibility between releases (even minor ones).

Kai Torben Ohlhus <siko1056>
Project Member
Fri 14 Jan 2022 09:38:29 AM UTC, original submission:  

A segfault appeared when running a .oct file. I reduced the problem to a minimal example:

#include <octave/oct.h>
#include <octave/pt-all.h>

DEFUN_DLD (params, args, nargout,
           "segfault in user fcn")
    octave::tree_parameter_list *lst = new octave::tree_parameter_list(octave::tree_parameter_list::in);

    octave_user_function *fcn = new octave_user_function ();

    fcn->define_ret_list (lst);

    octave::tree_parameter_list *ret_list = fcn->return_list ();

    bool emp = ret_list->empty ();

    return octave_value(emp);

Simply I created an empty parameter list then set it as the return list of an empty user function and get it back via "return_list()" method of the "octave_user_function". Now calling any methods of the returned parameter list results in segfault. Segfault appeared here:

bool emp = ret_list->empty ();

The above code runs without error on Octave 6.3.0.
Note that the following code runs without any problem in 7.0.90:

    octave::tree_parameter_list *lst = new octave::tree_parameter_list(octave::tree_parameter_list::in);
    bool emp = lst->empty ();

The parameter list first must be saved into a user function and be retrieved back to reproduce the segfault.
Is may be a bug in GCC or a bug in Octave config and build system. Other API functions also may be affected.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #52916:  cli.png added by None (15KiB - image/png)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.





    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-03-15 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2022-03-12 mmuetzel StatusPatch Submitted Ready For Test
    2022-02-26 mmuetzel Attached File- Added bug61821-no-time_t-in-API.patch, #52935
        StatusConfirmed Patch Submitted
    2022-02-23 None Attached File- Added cli.png, #52916
    2022-01-17 mmuetzel StatusNeed Info Confirmed
    2022-01-17 siko1056 StatusNone Need Info
        Summarysegfault in oct interface segfault using tree_parameter_list in oct file

    Back to the top

    Powered by Savane 3.9