bugGNU Octave - Bugs: bug #59228, embedded.cc example crashes with...

 
 

bug #59228: embedded.cc example crashes with segfault

Submitter:  Carlo de Falco <cdf>
Submitted:  Tue 06 Oct 2020 01:28:05 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 6.0.90 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 20 Oct 2020 05:44:52 PM UTC, comment #40: 

I pushed the following change on stable and merged with default:

http://hg.savannah.gnu.org/hgweb/octave/rev/bcfa15435e4c

John W. Eaton <jwe>
Group administrator
Tue 20 Oct 2020 04:23:19 AM UTC, comment #39: 

@jwe , yes, the patch in file #50016 also removes the crash.
thanks

Carlo de Falco <cdf>
Group Member
Mon 19 Oct 2020 07:05:30 PM UTC, comment #38: 

I think the intent is that the destructor is not supposed to be called for the static nil_rep object because the reference count is never supposed to be zero.  But the dim_vector object appears to construct the nil_rep object in a way that it would be called.  Does the attached patch also avoid the crash?



(file #50016)

John W. Eaton <jwe>
Group administrator
Mon 19 Oct 2020 06:27:49 PM UTC, comment #37: 

@mmuetzel yes, the patch in file #50015
does prevent the example of comment #31
from crashing.





Carlo de Falco <cdf>
Group Member
Mon 19 Oct 2020 05:43:41 PM UTC, comment #36: 

Thanks for testing.
I guess that proves that freerep is called on the nil_rep. IIUC, this shouldn't happen. (Is that so?)

Does the attached patch (instead of the previous one) fix the crash?

(file #50015)

Markus Mützel <mmuetzel>
Group administrator
Mon 19 Oct 2020 05:34:47 PM UTC, comment #35: 

@mmuetzel thanks for your patch!

With the patch installed I get the following failed assertion error :


$ mkoctfile --link-stand-alone pippo2.cc -o pippo
$ ./pippo
Assertion failed: (rep != nil_rep ()), function freerep, file /Users/carlo/Documents/_Programmi/Miei/C/octave//octave/liboctave/array/dim-vector.h, line 162.
Abort trap: 6



Carlo de Falco <cdf>
Group Member
Mon 19 Oct 2020 02:46:34 PM UTC, comment #34: 

Again, I still haven't looked into how the reference counter works. So, I can't tell if or why that counter should or should not reach 0 for nil_rep.
But since a similar change seems to have avoided the previous crash, does the attached patch avoid the crash from comment #31?

(file #50014)

Markus Mützel <mmuetzel>
Group administrator
Mon 19 Oct 2020 02:23:14 PM UTC, comment #33: 

@Rik, thanks for your test!

IIUC "__cxa_finalize_ranges" seems to be a system
function responsible of clearing global and static
variable memory, so even though the issue is different
it may not be completely unrelated ...

it may well be macos only, but it is definitely
new in 6.0.91 as I just tested with octave 4.4
and 5.1 and cannot get similar crashes ...

I'll look more into it an maybe post a separate bug report.

Carlo de Falco <cdf>
Group Member
Mon 19 Oct 2020 01:39:35 PM UTC, comment #32: 

I think this might be some other issue, perhaps the weirdness that is sometimes found on Macs.  The original example definitely produced a segfault for me.  However, the code from comments #28, #30, and #31 do not.  I compiled and ran the executable 10,000 times and never saw a failure.  This is on a garden variet Linux (Kubuntu) system.

Rik <rik5>
Group administrator
Mon 19 Oct 2020 06:09:32 AM UTC, comment #31: 

wait! even an empty "main ()" seems to crash when compiled with
mkoctfile --link-stand-alone


int main ()
{
  return (0);
}


build with


mkoctfile  --link-stand-alone  ../../test/intrp_test.cpp -o intrp_test


here is the backtrace in lldb


(lldb) run
Process 42084 launched: '/Users/carlo/Documents/_Programmi/Miei/C/octave_file_io/BUILD/test/intrp_test' (x86_64)
intrp_test(42084,0x1000a45c0) malloc: *** error for object 0x109b00000: pointer being freed was not allocated
intrp_test(42084,0x1000a45c0) malloc: *** set a breakpoint in malloc_error_break to debug
Process 42084 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff5c7da2c2 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff5c7da2c2 <+10>: jae    0x7fff5c7da2cc            ; <+20>
    0x7fff5c7da2c4 <+12>: movq   %rax, %rdi
    0x7fff5c7da2c7 <+15>: jmp    0x7fff5c7d4453            ; cerror_nocancel
    0x7fff5c7da2cc <+20>: retq
Target 0: (intrp_test) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff5c7da2c2 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff5c895bf1 libsystem_pthread.dylib`pthread_kill + 284
    frame #2: 0x00007fff5c7446a6 libsystem_c.dylib`abort + 127
    frame #3: 0x00007fff5c853077 libsystem_malloc.dylib`malloc_vreport + 545
    frame #4: 0x00007fff5c852e38 libsystem_malloc.dylib`malloc_report + 151
    frame #5: 0x00000001000d1f6a liboctinterp.8.dylib`dim_vector::freerep(this=0x000000010420d868) at dim-vector.h:162:5
    frame #6: 0x000000010360acb7 liboctave.8.dylib`dim_vector::~dim_vector(this=0x000000010420d868) at dim-vector.h:325:7
    frame #7: 0x00000001035f8035 liboctave.8.dylib`dim_vector::~dim_vector(this=0x000000010420d868) at dim-vector.h:319:3
    frame #8: 0x0000000103a8a85c liboctave.8.dylib`idx_vector::idx_vector_rep::~idx_vector_rep(this=0x000000010420d830) at idx-vector.cc:451:1
    frame #9: 0x0000000103a88a05 liboctave.8.dylib`idx_vector::idx_vector_rep::~idx_vector_rep(this=0x000000010420d830) at idx-vector.cc:446:1
    frame #10: 0x00007fff5c7453cf libsystem_c.dylib`__cxa_finalize_ranges + 319
    frame #11: 0x00007fff5c7456b3 libsystem_c.dylib`exit + 55
    frame #12: 0x00007fff5c69f3dc libdyld.dylib`start + 8
(lldb)


Carlo de Falco <cdf>
Group Member
Mon 19 Oct 2020 05:59:05 AM UTC, comment #30: 

this one is also sufficient to trigger the crash :


#include <octave/oct.h>

int main (int argc, char **argv)
{
  octave_idx_type n;
  return (0);
}


Carlo de Falco <cdf>
Group Member
Mon 19 Oct 2020 05:28:47 AM UTC, comment #29: 

regarding comment #28 ,
the crash is generated with the stable branch and it appears to be in


dim_vector::freerep()


I'll send a full bactrace ASAP

Carlo de Falco <cdf>
Group Member
Mon 19 Oct 2020 05:26:10 AM UTC, comment #28: 

Hi,

Sorry for replying late!

Thanks jwe for your analysis, and patch for my code.

I've been testing your patch for my code and still got a few crashes.

While trying to strip down the example to a minimum
I found, to my surprise, the following VERY minimal
example also crashes
(as usual the crash is random, need many runs to trigger):



#include <iostream>


#include <octave/oct.h>
#include <cassert>
#include <vector>

int main (int argc, char **argv)
{
  std::vector<octave_idx_type> n;
  std::vector<double>          x;

  return (0);
}


this does not seem to involve the interpreter at all,
though, so maybe I should add a new bug for it?

Carlo de Falco <cdf>
Group Member
Sat 17 Oct 2020 02:33:49 PM UTC, comment #27: 

I agree with Rik's comment #25.

IIUC, static instances of the interpreter must be manually deleted before the end of main. If this is the case, this should be documented somewhere imho.

Markus Mützel <mmuetzel>
Group administrator
Fri 16 Oct 2020 09:26:09 PM UTC, comment #26: 

Should we close this as invalid?  Or should we modify the documentation to mention that static instances of the interpreter are not recommended/allowed?

Rik <rik5>
Group administrator
Wed 14 Oct 2020 08:11:11 PM UTC, comment #25: 

I really like the idea of shifting more of the load on to standard libraries like shared_ptr rather than maintaining our own code to provide equivalent functionality.  The main C++ libraries will get much more testing and performance optimization than we can do ourselves.

Rik <rik5>
Group administrator
Wed 14 Oct 2020 06:59:32 PM UTC, comment #24: 

Thinking about this more, even if allocated memory remains valid until after all the destructors are called, Octave also has a number of global objects that could cause trouble.  Is there any guarantee about the order that they are deleted?  Is it possible that some of those global objects are deleted before the singleton destructor calls the interpreter shutdown method and destructor?  When the interpreter shutdown method is called, it needs to be able to execute arbitrary functions.  We can't expect that to work if some necessary global objects have already been destroyed.

If this is correct, then it seems to me that we can't expect the interpreter destructor to properly shut down after main returns until we can ensure that the shutdown process doesn't rely on any global or static(?) variables.

John W. Eaton <jwe>
Group administrator
Wed 14 Oct 2020 05:07:30 PM UTC, comment #23: 

Carlo: I think the problem is the way the singleton object is cleaned up in your program.

The static object is not deleted until after main is finished executing.  At that point, the destructor for the static octave_file_io_intf object is called.  But also at that point, any memory allocated by new may have already been reused.  So executing shutdown on the interpreter or calling delete may fail because the interpreter shutdown function does a lot more than just deleting memory.  Do you need to use a singleton or static objects?

If you like the convenience of the singleton object and still want to shutdown the interpreter, you could make some changes like those in the attached patch.  I left in some statements to trace execution if you want to trace what happens with or without the new octave_io_cleanup function

Either way, I think you need to ensure that the interpreter is cleaned up before main returns.

(file #49980)

John W. Eaton <jwe>
Group administrator
Wed 14 Oct 2020 04:32:46 PM UTC, comment #22: 


comment #17:

> I would like to try to help with this issue.  When I try to build the package from comment #14 I'm getting undefined references to MPI functions.
>
> Is there a simpler example that doesn't depend on external packages?



I pushed a branch in the repository of comment #14 that does not need mpi, if that may help in testing

Carlo de Falco <cdf>
Group Member
Wed 14 Oct 2020 04:30:54 PM UTC, comment #21: 


comment #20:

> Oops, wait, I may have spoken too soon.  I was able to generate a core file.  Stack trace is
>


Thanks for testing this!
Yest the stack trace looks the same as what I see ...

I also get the crash a few times out of many runs.

Carlo de Falco <cdf>
Group Member
Wed 14 Oct 2020 04:08:07 PM UTC, comment #20: 

Oops, wait, I may have spoken too soon.  I was able to generate a core file.  Stack trace is


(gdb) thread apply all bt

Thread 1 (Thread 0x7f72ceb15b40 (LWP 3414079)):
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f72d6435537 in __GI_abort () at abort.c:79
#2  0x00007f72d648e828 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f72d659ce31 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007f72d6495b1a in malloc_printerr (str=str@entry=0x7f72d659f170 "free(): double free detected in tcache 2") at malloc.c:5347
#4  0x00007f72d6497115 in _int_free (av=0x7f72d65ceb80 <main_arena>, p=0x559a72453e60, have_lock=0) at malloc.c:4201
#5  0x00007f72d7f6e115 in dim_vector::freerep (this=0x7ffc126d5638, this=0x7ffc126d5638) at /home/jwe/src/octave-stable/liboctave/array/dim-vector.h:162
#6  dim_vector::~dim_vector (this=0x7ffc126d5638, __in_chrg=<optimized out>) at /home/jwe/src/octave-stable/liboctave/array/dim-vector.h:325
#7  octave_base_value::isempty (this=<optimized out>) at /home/jwe/src/octave-stable/libinterp/octave-value/ov-base.h:357
#8  0x00007f72d835fcbe in octave_value::isempty (this=<optimized out>) at /home/jwe/src/octave-stable/libinterp/octave-value/ov.h:558
#9  Fget (interp=..., args=...) at /home/jwe/src/octave-stable/libinterp/corefcn/graphics.cc:12886
#10 0x00007f72d7f644d6 in octave_builtin::execute (this=0x559a72385900, tw=..., nargout=1, args=...) at /home/jwe/src/octave-stable/libinterp/octave-value/ov-builtin.cc:65
#11 0x00007f72d7fc2548 in octave_function::call (this=0x559a72385900, tw=..., nargout=1, args=...) at /home/jwe/src/octave-stable/libinterp/octave-value/ov-fcn.cc:57
#12 0x00007f72d8122e02 in octave::tree_index_expression::evaluate_n (this=0x7ffc126d5c00, tw=..., nargout=1) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-idx.cc:402
#13 0x00007f72d812390c in octave::tree_index_expression::evaluate (this=<optimized out>, tw=..., nargout=<optimized out>) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-idx.h:107
#14 0x00007f72d80f5a71 in octave::tree_simple_assignment::evaluate (this=0x559a724eed90, tw=...) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-assign.cc:101
#15 0x00007f72d810feb3 in octave::tree_evaluator::visit_statement (this=0x559a722ea318, stmt=...) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-eval.cc:3031
#16 0x00007f72d8101ad0 in octave::tree_statement::accept (tw=..., this=0x559a724eedd0) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-stmt.h:124
#17 octave::tree_evaluator::visit_statement_list (this=0x559a722ea318, lst=...) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-eval.cc:3090
#18 0x00007f72d810a3ca in octave::tree_statement_list::accept (tw=..., this=0x559a72609f10) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-stmt.h:201
#19 octave::tree_evaluator::execute_user_function (this=this@entry=0x559a722ea318, user_function=..., nargout=nargout@entry=0, xargs=...) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-eval.cc:2770
#20 0x00007f72d8041cc1 in octave_user_function::execute (args=..., nargout=<optimized out>, tw=..., this=0x559a722126c0) at /home/jwe/src/octave-stable/libinterp/octave-value/ov-usr-fcn.cc:496
#21 octave_user_function::call (this=0x559a722126c0, tw=..., nargout=0, args=...) at /home/jwe/src/octave-stable/libinterp/octave-value/ov-usr-fcn.cc:489
#22 0x00007f72d84783bf in octave::interpreter::feval (this=0x559a722e9580, name="close", args=..., nargout=0) at /home/jwe/src/octave-stable/libinterp/corefcn/interpreter.cc:1534
--Type <RET> for more, q to quit, c to continue without paging--
#23 0x00007f72d847843a in octave::interpreter::feval (this=0x559a722e9580, name=<optimized out>, args=..., nargout=0) at /usr/include/c++/10/ext/new_allocator.h:79
#24 0x00007f72d8479e9a in octave::interpreter::shutdown (this=0x559a722e9580) at /home/jwe/src/octave-stable/libinterp/octave-value/ovl.h:211
#25 0x00007f72d8a039b3 in octave_file_io_intf::~octave_file_io_intf (this=0x7f72d8a09240 <octave_file_io_intf::get_instance()::instance>, __in_chrg=<optimized out>) at octave_file_io.cpp:96
#26 0x00007f72d644e5a7 in __run_exit_handlers (status=0, listp=0x7f72d65ce718 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108
#27 0x00007f72d644e74a in __GI_exit (status=<optimized out>) at exit.c:139
#28 0x00007f72d6436cd1 in __libc_start_main (main=0x559a713caeb0 <main(int, char**)>, argc=1, argv=0x7ffc126d65c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc126d65b8) at ../csu/libc-start.c:342
#29 0x0000559a713cbdfa in _start () at io_test_par.cpp:126


I'll see if I can figure out why that happens.

John W. Eaton <jwe>
Group administrator
Wed 14 Oct 2020 04:00:49 PM UTC, comment #19: 

OK, I was finally able to figure out how to link with openmpi on my system but repeatedly running make check doesn't seem to cause the example from comment #14 to fail for me, with or without calling shutdown and deleting the interpreter object.  I've run "make check" several hundred times in a loop both ways.  I'm using Octave 6.0.91, hg id 66b52ae69d73

What else should I try to duplicate the problem?

John W. Eaton <jwe>
Group administrator
Wed 14 Oct 2020 03:09:45 PM UTC, comment #18: 

Markus, I don't think that the reference count for the static objects can ever be zero but the static analyzer can't determine that.

But maybe I'm wrong.  We could test with an assert about the reference count for the nil_rep object being zero.  If it is triggered, then I would like to understand how and why that happens.

I would also like to move away from our custom reference counting and use standard shared_ptr templates instead.  But in some cases, it seems tricky to understand what is happening with reference counts.  For example, I was looking at idx_vector yesterday and there is a lot of unexplained (or insufficiently explained) magic in that set of classes.  Of course, this indicates potential future maintenance trouble and I would like to improve things to both avoid bugs and improve reliability.

When I've looked at the output of the clang static analyzer in the past, it seemed to be so full of noise that it wasn't really helpful.  If I am just misunderstanding the report, then I'd be grateful for someone to give me some clues.

John W. Eaton <jwe>
Group administrator
Wed 14 Oct 2020 02:58:41 PM UTC, comment #17: 

I would like to try to help with this issue.  When I try to build the package from comment #14 I'm getting undefined references to MPI functions.

Is there a simpler example that doesn't depend on external packages?

John W. Eaton <jwe>
Group administrator
Wed 14 Oct 2020 02:51:29 PM UTC, comment #16: 

I used the report Dmitri posted on the mailing list a few weeks back:
https://lists.gnu.org/archive/html/octave-maintainers/2020-10/msg00026.html

I believe there were instructions somewhere on how to create such a report (maybe on the wiki?). IIRC, I was able to reproduce those steps a while back. But I can't find the instructions right now. Maybe comment #0 in bug #58569 might help...

Tbh, I didn't anticipate that that change would actually fix anything. I haven't looked in detail at how we are counting references. But there are a lot of issues in the analysis report related to the reference counter (double free, double delete, ...). The majority (or all?) of those are probably false positives. (But tbh again, I can't really judge.)
In that particular case, I just figured that the additional checks wouldn't hurt much and it was quite clear what the analysis was complaining about.
Other issues in that report aren't that clear to me...

There are quite a few reported dead assignments that might also be easy fixes. But those can't cause segfaults afaict...

Markus Mützel <mmuetzel>
Group administrator
Wed 14 Oct 2020 02:31:47 PM UTC, comment #15: 

I applied your patch to the stable branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/d4d8c004457f) and then merged with default.  I've been checking in a lot of code lately and haven't been keeping up with the QA (quality assurance).

It's a shame that the segfault issues are not completely resolved.  It may mean that there are still instances in Octave where variables are being freed from the stack.  I'm adding Markus to the CC list since he might know the answer.

@Markus: is there an automated way to detect incorrect freeing of variables on the stack?  Were you working from a static analysis of the code?

Rik <rik5>
Group administrator
Wed 14 Oct 2020 07:51:40 AM UTC, comment #14: 

The original code still crashes randomly.
I'll try to work out another smaller example.

If anyone wants to check it out in the mean time,
the original code is here :

https://github.com/carlodefalco/octave_file_io

uncomment lines 96-97 here :

https://github.com/carlodefalco/octave_file_io/blob/master/src/octave_file_io.cpp#L96

then run "configure; make; make check" to reproduce
the crash.

the tests may not always fail so "make check" should be
run repetedly

Carlo de Falco <cdf>
Group Member
Wed 14 Oct 2020 07:35:18 AM UTC, comment #13: 

The example from comment #7 does not crash anymore (whatever the scope of the object "s").

I'd like to test with the original larger code which motivated tha test before closing the bug.


Carlo de Falco <cdf>
Group Member
Wed 14 Oct 2020 07:31:27 AM UTC, comment #12: 





$ mkoctfile --link-stand-alone embedded.cc -o embedded
embedded.cc:80:3: error: use of undeclared identifier 'interp'
  interp->shutdown ();
  ^
1 error generated.


Trivial patch attached ( file #49975 )

Carlo de Falco <cdf>
Group Member
Wed 14 Oct 2020 03:54:02 AM UTC, comment #11: 

That change for the embedded.cc example should be OK.

Ideally, we would just be able to execute all the shutdown steps from inside the interpreter destructor method but I don't know whether we can do that now.

John W. Eaton <jwe>
Group administrator
Tue 13 Oct 2020 10:32:14 PM UTC, comment #10: 

Markus just checked in this change which prevents freeing variables that are still alive on the stack (http://hg.savannah.gnu.org/hgweb/octave/rev/02f0649f43d7).  This seems to fix the problem for me.  I tried the code from comment #7 where 's' was first a file static variable and then a local variable in the function main() and both work.

But, the original embedded.cc code still produces a segfault.  Hence, I think we really do need to shut down the interpreter cleanly.  I made that change here http://hg.savannah.gnu.org/hgweb/octave/rev/66b52ae69d73.

Marking as Ready for Test.

Rik <rik5>
Group administrator
Sun 11 Oct 2020 10:59:03 AM UTC, comment #9: 

comment #8:

> The stripped down example crashes for me repeatedly.  However, I had to reverse the commented out code.  When s is a file static variable there is no crash.  When it is a local variable within a function (the function is main() in this case) then the crash happens.


Hi, thanks for testing!
Were you testing with dev or stable?

Anyway, I think the fact that the crash is unpredictable
(maybe depends on compiler used?) and somewhat random is
an argument in favor of trying to fix the way memory is
cleared in the interpreter destructor ...

Carlo de Falco <cdf>
Group Member
Sun 11 Oct 2020 03:10:31 AM UTC, comment #8: 

The stripped down example crashes for me repeatedly.  However, I had to reverse the commented out code.  When s is a file static variable there is no crash.  When it is a local variable within a function (the function is main() in this case) then the crash happens.

Rik <rik5>
Group administrator
Thu 08 Oct 2020 03:56:47 PM UTC, comment #7: 

Here is the stripped down example I had promised :


#include <octave/oct.h>
#include <octave/parse.h>
#include <iostream>


struct s_ {
  octave::interpreter* interp;
  s_ () {
    std::cout << "ctor" << std::endl;
    interp = new octave::interpreter ();
    int status = interp->execute ();
    std::cout << "status = " << status << std::endl;
  }
 ~s_ () {
   std::cout << "dtor" << std::endl;
   interp->shutdown ();
   delete interp;
 }

  void
  write_stuff () {
    try {
      octave_value_list out;
      interp->feval ("date", out, 1);
    }
    catch (octave::execution_exception& ) {
      std::cerr << "exception raised" << std::endl;
    }
  }
};



// uncomment next line to produce crash
// s_ s;

int main () {
  // comment next line to produce crash
  s_ s;
  s.write_stuff ();
  return 0;
}


The scope in which the object "s" is created is relevant in order for the crash to happen.
The crash does not happen at every run, when it does occur I get the following output :


$ mkoctfile --link-stand-alone -O0 -g prova4.cc -o prova4
$ ./prova4
ctor
status = 0
dtor

$ ./prova4
ctor
status = 0
dtor
prova4(7839,0x10c6965c0) malloc: *** error for object 0x7fb4ba8edf20: pointer being freed was not allocated
prova4(7839,0x10c6965c0) malloc: *** set a breakpoint in malloc_error_break to debug
Abort trap: 6

$



if I run in the debugger I get the following backtrace :


(lldb) run
Process 7946 launched: '/tmp/prova4' (x86_64)
ctor
status = 0
dtor
prova4(7946,0x1000af5c0) malloc: *** error for object 0x109c3d2a0: pointer being freed was not allocated
prova4(7946,0x1000af5c0) malloc: *** set a breakpoint in malloc_error_break to debug
Process 7946 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff5c7da2c2 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff5c7da2c2 <+10>: jae    0x7fff5c7da2cc            ; <+20>
    0x7fff5c7da2c4 <+12>: movq   %rax, %rdi
    0x7fff5c7da2c7 <+15>: jmp    0x7fff5c7d4453            ; cerror_nocancel
    0x7fff5c7da2cc <+20>: retq
Target 0: (prova4) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff5c7da2c2 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff5c895bf1 libsystem_pthread.dylib`pthread_kill + 284
    frame #2: 0x00007fff5c7446a6 libsystem_c.dylib`abort + 127
    frame #3: 0x00007fff5c853077 libsystem_malloc.dylib`malloc_vreport + 545
    frame #4: 0x00007fff5c852e38 libsystem_malloc.dylib`malloc_report + 151
    frame #5: 0x00000001000030ea prova4`dim_vector::freerep() + 122
    frame #6: 0x00000001000dcf67 liboctinterp.8.dylib`dim_vector::~dim_vector(this=0x00007ffeefbfc3d0) at dim-vector.h:325:7
    frame #7: 0x00000001000dcd45 liboctinterp.8.dylib`dim_vector::~dim_vector(this=0x00007ffeefbfc3d0) at dim-vector.h:319:3
    frame #8: 0x00000001001d4fa9 liboctinterp.8.dylib`octave_base_value::isempty(this=0x0000000109ad3190) const at ov-base.h:357:31
    frame #9: 0x0000000100590eb8 liboctinterp.8.dylib`octave_value::isempty(this=0x0000000109ae5ba0) const at ov.h:558:17
    frame #10: 0x0000000100e25b8f liboctinterp.8.dylib`Fget(interp=0x000000010a01ba00, args=0x00007ffeefbfd2b8, (null)=1) at graphics.cc:12886:15
    frame #11: 0x00000001005f83d8 liboctinterp.8.dylib`octave_builtin::execute(this=0x0000000109a47b20, tw=0x000000010a01c540, nargout=1, args=0x00007ffeefbfd2b8) at ov-builtin.cc:65:16
    frame #12: 0x00000001006b2dc9 liboctinterp.8.dylib`octave_function::call(this=0x0000000109a47b20, tw=0x000000010a01c540, nargout=1, args=0x00007ffeefbfd2b8) at ov-fcn.cc:57:10
    frame #13: 0x00000001009ad834 liboctinterp.8.dylib`octave::tree_index_expression::evaluate_n(this=0x000000010e8079a0, tw=0x000000010a01c540, nargout=1) at pt-idx.cc:402:35
    frame #14: 0x00000001009af2b2 liboctinterp.8.dylib`octave::tree_index_expression::evaluate(this=0x000000010e8079a0, tw=0x000000010a01c540, nargout=1) at pt-idx.h:107:34
    frame #15: 0x000000010092109e liboctinterp.8.dylib`octave::tree_simple_assignment::evaluate(this=0x000000010e8e4390, tw=0x000000010a01c540, (null)=0) at pt-assign.cc:101:43
    frame #16: 0x0000000100955d08 liboctinterp.8.dylib`octave::tree_evaluator::visit_statement(this=0x000000010a01c540, stmt=0x0000000109ab3750) at pt-eval.cc:3031:49
    frame #17: 0x00000001009d1821 liboctinterp.8.dylib`octave::tree_statement::accept(this=0x0000000109ab3750, tw=0x000000010a01c540) at pt-stmt.h:124:10
    frame #18: 0x0000000100956059 liboctinterp.8.dylib`octave::tree_evaluator::visit_statement_list(this=0x000000010a01c540, lst=0x000000010e8e43d0) at pt-eval.cc:3090:18
    frame #19: 0x000000010054ea91 liboctinterp.8.dylib`octave::tree_statement_list::accept(this=0x000000010e8e43d0, tw=0x000000010a01c540) at pt-stmt.h:201:10
    frame #20: 0x000000010095552b liboctinterp.8.dylib`octave::tree_evaluator::visit_if_command_list(this=0x000000010a01c540, lst=0x0000000109ac0960) at pt-eval.cc:2885:25
    frame #21: 0x0000000100955391 liboctinterp.8.dylib`octave::tree_if_command_list::accept(this=0x0000000109ac0960, tw=0x000000010a01c540) at pt-select.h:118:10
    frame #22: 0x0000000100955344 liboctinterp.8.dylib`octave::tree_evaluator::visit_if_command(this=0x000000010a01c540, cmd=0x000000010e8093c0) at pt-eval.cc:2863:12
    frame #23: 0x00000001009cffe1 liboctinterp.8.dylib`octave::tree_if_command::accept(this=0x000000010e8093c0, tw=0x000000010a01c540) at pt-select.h:151:10
    frame #24: 0x0000000100955be7 liboctinterp.8.dylib`octave::tree_evaluator::visit_statement(this=0x000000010a01c540, stmt=0x000000010e8e3a80) at pt-eval.cc:3008:22
    frame #25: 0x00000001009d1821 liboctinterp.8.dylib`octave::tree_statement::accept(this=0x000000010e8e3a80, tw=0x000000010a01c540) at pt-stmt.h:124:10
    frame #26: 0x0000000100956059 liboctinterp.8.dylib`octave::tree_evaluator::visit_statement_list(this=0x000000010a01c540, lst=0x000000010e8e3ab0) at pt-eval.cc:3090:18
    frame #27: 0x000000010054ea91 liboctinterp.8.dylib`octave::tree_statement_list::accept(this=0x000000010e8e3ab0, tw=0x000000010a01c540) at pt-stmt.h:201:10
    frame #28: 0x000000010095552b liboctinterp.8.dylib`octave::tree_evaluator::visit_if_command_list(this=0x000000010a01c540, lst=0x000000010e8093f0) at pt-eval.cc:2885:25
    frame #29: 0x0000000100955391 liboctinterp.8.dylib`octave::tree_if_command_list::accept(this=0x000000010e8093f0, tw=0x000000010a01c540) at pt-select.h:118:10
    frame #30: 0x0000000100955344 liboctinterp.8.dylib`octave::tree_evaluator::visit_if_command(this=0x000000010a01c540, cmd=0x000000010e8d6cf0) at pt-eval.cc:2863:12
    frame #31: 0x00000001009cffe1 liboctinterp.8.dylib`octave::tree_if_command::accept(this=0x000000010e8d6cf0, tw=0x000000010a01c540) at pt-select.h:151:10
    frame #32: 0x0000000100955be7 liboctinterp.8.dylib`octave::tree_evaluator::visit_statement(this=0x000000010a01c540, stmt=0x000000010e8d6d20) at pt-eval.cc:3008:22
    frame #33: 0x00000001009d1821 liboctinterp.8.dylib`octave::tree_statement::accept(this=0x000000010e8d6d20, tw=0x000000010a01c540) at pt-stmt.h:124:10
    frame #34: 0x0000000100956059 liboctinterp.8.dylib`octave::tree_evaluator::visit_statement_list(this=0x000000010a01c540, lst=0x000000010e8d6d50) at pt-eval.cc:3090:18
    frame #35: 0x000000010054ea91 liboctinterp.8.dylib`octave::tree_statement_list::accept(this=0x000000010e8d6d50, tw=0x000000010a01c540) at pt-stmt.h:201:10
    frame #36: 0x000000010095552b liboctinterp.8.dylib`octave::tree_evaluator::visit_if_command_list(this=0x000000010a01c540, lst=0x0000000109ab5f00) at pt-eval.cc:2885:25
    frame #37: 0x0000000100955391 liboctinterp.8.dylib`octave::tree_if_command_list::accept(this=0x0000000109ab5f00, tw=0x000000010a01c540) at pt-select.h:118:10
    frame #38: 0x0000000100955344 liboctinterp.8.dylib`octave::tree_evaluator::visit_if_command(this=0x000000010a01c540, cmd=0x000000010e8ec540) at pt-eval.cc:2863:12
    frame #39: 0x00000001009cffe1 liboctinterp.8.dylib`octave::tree_if_command::accept(this=0x000000010e8ec540, tw=0x000000010a01c540) at pt-select.h:151:10
    frame #40: 0x0000000100955be7 liboctinterp.8.dylib`octave::tree_evaluator::visit_statement(this=0x000000010a01c540, stmt=0x000000010e8ec570) at pt-eval.cc:3008:22
    frame #41: 0x00000001009d1821 liboctinterp.8.dylib`octave::tree_statement::accept(this=0x000000010e8ec570, tw=0x000000010a01c540) at pt-stmt.h:124:10
    frame #42: 0x0000000100956059 liboctinterp.8.dylib`octave::tree_evaluator::visit_statement_list(this=0x000000010a01c540, lst=0x000000010e8c9af0) at pt-eval.cc:3090:18
    frame #43: 0x000000010054ea91 liboctinterp.8.dylib`octave::tree_statement_list::accept(this=0x000000010e8c9af0, tw=0x000000010a01c540) at pt-stmt.h:201:10
    frame #44: 0x00000001009547c8 liboctinterp.8.dylib`octave::tree_evaluator::execute_user_function(this=0x000000010a01c540, user_function=0x000000010e8d2000, nargout=0, xargs=0x00007ffeefbff410) at pt-eval.cc:2770:19
    frame #45: 0x000000010078dc12 liboctinterp.8.dylib`octave_user_function::execute(this=0x000000010e8d2000, tw=0x000000010a01c540, nargout=0, args=0x00007ffeefbff410) at ov-usr-fcn.cc:496:13
    frame #46: 0x000000010078db1c liboctinterp.8.dylib`octave_user_function::call(this=0x000000010e8d2000, tw=0x000000010a01c540, nargout=0, args=0x00007ffeefbff410) at ov-usr-fcn.cc:489:10
    frame #47: 0x0000000100ed8113 liboctinterp.8.dylib`octave::interpreter::feval(this=0x000000010a01ba00, name="close", args=0x00007ffeefbff410, nargout=0) at interpreter.cc:1534:16
    frame #48: 0x0000000100ed70fb liboctinterp.8.dylib`octave::interpreter::feval(this=0x000000010a01ba00, name="close", args=0x00007ffeefbff410, nargout=0) at interpreter.cc:1520:12
    frame #49: 0x0000000100ed434b liboctinterp.8.dylib`octave::interpreter::shutdown(this=0x000000010a01ba00) at interpreter.cc:874:5
    frame #50: 0x00000001000029c8 prova4`s_::~s_() + 88
    frame #51: 0x0000000100001b95 prova4`s_::~s_() + 21
    frame #52: 0x00007fff5c7453cf libsystem_c.dylib`__cxa_finalize_ranges + 319
    frame #53: 0x00007fff5c7456b3 libsystem_c.dylib`exit + 55
    frame #54: 0x00007fff5c69f3dc libdyld.dylib`start + 8
(lldb)


Carlo de Falco <cdf>
Group Member
Wed 07 Oct 2020 09:58:15 PM UTC, comment #6: 

For dev version, you need to make sure that you do 'make install' so that the mkoctfile version that you get on the command line matches the libraries that are installed.

Also,


mkoctfile embedded.cc


produces file "embedded.oct" so any "a.out" that you ran was from some previous compilation.

However, having done the steps above and set my LD_LIBRARY_PATH to guarantee I am picking up the right libraries, I get a segfault too.

I used


mkoctfile -g -v --link-stand-alone embedded.cc


and then ran under gdb.  The backtrace is totally useless.


Program received signal SIGSEGV, Segmentation fault.
main () at embedded.cc:9
9       {
(gdb) bt
#0  main () at embedded.cc:9




Rik <rik5>
Group administrator
Wed 07 Oct 2020 06:19:00 PM UTC, comment #5: 

Slightly different problem here. Compiling embedded.cc with g++ works as OP describes, but mkoctfile does not. This is with dev version 7.0.0.

Original version:

$ tail -4 embedded.cc
    }

  return 0;
}
$ g++ embedded.cc -I /usr/local/include/octave-7.0.0/ -L /usr/local/lib/octave/7.0.0/ -loctinterp -loctave
$ ./a.out
GCD of [10, 15] is 5
Segmentation fault (core dumped)


Add the line interpreter.shutdown() to the end:

$ tail -5 embedded.cc
    }

  interpreter.shutdown();
  return 0;
}
$ g++ embedded.cc -I /usr/local/include/octave-7.0.0/ -L /usr/local/lib/octave/7.0.0/ -loctinterp -loctave
$ ./a.out
GCD of [10, 15] is 5


Try the same with mkoctfile, with and without the interpreter.shutdown():

$ mkoctfile embedded.cc
$ ./a.out
Segmentation fault (core dumped)
$ mkoctfile --link-stand-alone embedded.cc
$ ./a.out
Segmentation fault (core dumped)


Anonymous
Wed 07 Oct 2020 05:42:37 PM UTC, comment #4: 

invoking interpreter::shutdown solves the problem
for this particular example, but I have a larger
piece of code where that seems to not be sufficient.

The crash seems to depend on what command is run
in the interpreter before shutdown and also it
appears to be random, i.e., it occurs about 30%
of the times the code is run.

The current code is too large to post but I am trying
to produce a minimal working example.

Carlo de Falco <cdf>
Group Member
Wed 07 Oct 2020 04:03:30 PM UTC, comment #3: 

Confirmed on a Linux platform as well.  Changing the Operating System to "Any".

I ran under gdb and the backtrace is:


#0  0x0000000000000000 in ?? ()
#1  0x00007ffff712f40f in octave::cdef_object_rep::release(octave::cdef_object const&) () from /home/rik/local/lib/octave/6.0.91/liboctinterp.so.8
#2  0x00007ffff718ca68 in octave_classdef_meta::~octave_classdef_meta() () from /home/rik/local/lib/octave/6.0.91/liboctinterp.so.8
#3  0x00007ffff7874bca in std::_Sp_counted_ptr<octave::fcn_info::fcn_info_rep*, (__gnu_cxx::_Lock_policy)2>::_M_dispose() ()
   from /home/rik/local/lib/octave/6.0.91/liboctinterp.so.8
#4  0x00007ffff76b652a in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info>, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> >*) () from /home/rik/local/lib/octave/6.0.91/liboctinterp.so.8
#5  0x00007ffff76b6495 in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info>, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> >*) () from /home/rik/local/lib/octave/6.0.91/liboctinterp.so.8
#6  0x00007ffff76b6495 in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info>, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> >*) () from /home/rik/local/lib/octave/6.0.91/liboctinterp.so.8
#7  0x00007ffff76b6495 in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info>, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> >*) () from /home/rik/local/lib/octave/6.0.91/liboctinterp.so.8
#8  0x00007ffff76b6495 in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info>, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> >*) () from /home/rik/local/lib/octave/6.0.91/liboctinterp.so.8
#9  0x00007ffff76b6495 in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info>, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> >*) () from /home/rik/local/lib/octave/6.0.91/liboctinterp.so.8
#10 0x00007ffff76b6495 in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info>, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> >*) () from /home/rik/local/lib/octave/6.0.91/liboctinterp.so.8
#11 0x00007ffff76b6495 in std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info>, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> > >::_M_erase(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, octave::fcn_info> >*) () from /home/rik/local/lib/octave/6.0.91/liboctinterp.so.8
#12 0x00007ffff76b3d29 in octave::interpreter::~interpreter() () from /home/rik/local/lib/octave/6.0.91/liboctinterp.so.8
#13 0x0000555555555a40 in main ()


It starts in the destructor for the interpreter (#12) and then ends up in the destructor for octave_classdef_meta.  I also verified that adding interpreter.shutdown () resolves this issue.

We can certainly make that change to the example code to demonstrate best practice.  Still, I think it is a decision for jwe as to whether an object going out of existence, in this case the interpreter, should be able to cause a segfault.


Rik <rik5>
Group administrator
Tue 06 Oct 2020 08:04:17 PM UTC, comment #2: 

Verified bug. Verified fix works for me too.

Anonymous
Tue 06 Oct 2020 02:54:45 PM UTC, comment #1: 

it seems the fix is simply to add


interpreter.shutdown ();


at the and of the file


Carlo de Falco <cdf>
Group Member
Tue 06 Oct 2020 01:28:05 PM UTC, original submission:  

I tested the examples/code/embedded.cc example
with the stable release and it crashes with a segfault.

The result of the test is displayed correctly,
so maybe the crash is occurring in the interpreter destructor?

I tested on macos 10.14.6 but I am not sure this is relevant.


$ mkoctfile --link-stand-alone embedded.cc -o embedded
$ ./embedded
GCD of [10, 15] is 5
Segmentation fault: 11


Carlo de Falco <cdf>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #50016:  dim-vector-diffs.txt added by jwe (417B - text/plain)
file #50015:  bug59228_do_not_delete_nilrep.patch added by mmuetzel (769B - application/octet-stream)
file #50014:  bug59228_assert_not_nilrep.patch added by mmuetzel (747B - application/octet-stream)
file #49980:  diffs.txt added by jwe (2KiB - text/plain)
file #49975:  open_1qoGjSNZ.txt added by cdf (666B - text/plain - fix for typo in previous changeset)
file #49928:  open_vDz1nh8P.txt added by cdf (684B - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by cdf (Submitted the item)
  •  

    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 group members can vote.

     

    Follow 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-10-23 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2020-10-19 jwe Attached File- Added dim-vector-diffs.txt, #50016
    2020-10-19 mmuetzel Attached File- Added bug59228_do_not_delete_nilrep.patch, #50015
    2020-10-19 mmuetzel Attached File- Added bug59228_assert_not_nilrep.patch, #50014
    2020-10-14 jwe Attached File- Added diffs.txt, #49980
    2020-10-14 rik5 Carbon-Copy- Added mmuetzel
    2020-10-14 cdf Attached File- Added open_1qoGjSNZ.txt, #49975
    2020-10-13 rik5 StatusConfirmed Ready For Test
    2020-10-07 rik5 CategoryNone Interpreter
        StatusNone Confirmed
        Operating SystemMac OS Any
        Carbon-Copy- Added jwe
    2020-10-06 cdf Attached File- Added open_vDz1nh8P.txt, #49928

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code