bugGNU Octave - Bugs: bug #63388, Octave may crash with uitable...

 
 

bug #63388: Octave may crash with uitable containing true/false data

Submitter:  Liang Tang <lt1234>
Submitted:  Sun 20 Nov 2022 01:30:22 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  lt1234 Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  8.1.0 Planned Release:  8.1.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 03 Dec 2022 12:42:05 PM UTC, comment #26: 

Arun, thanks. 

I don't have capability to provide feedback for a code fix in c file. 

Because the original issue is caused by the 'data' update and the fix is to redo the table, please verify that the table appearance, such as non-default column width, would not be altered with the fix. 

Thanks,


Liang Tang <lt1234>
Sat 03 Dec 2022 02:59:05 AM UTC, comment #25: 

Closing as Fixed. This will show up in the upcoming 8.1 release.

Arun Giridhar <arungiridhar>
Group Member
Tue 29 Nov 2022 01:07:31 PM UTC, comment #24: 

Thanks for testing.
I pushed the patch to the stable branch here:
https://hg.savannah.gnu.org/hgweb/octave/rev/7d7e04fc21ba

Markus Mützel <mmuetzel>
Group administrator
Tue 29 Nov 2022 11:46:31 AM UTC, comment #23: 

The patch fixed crash for me as well.

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Tue 29 Nov 2022 10:58:31 AM UTC, comment #22: 

Hi Markus, Thanks.

I don't have the environment to handle c files.  The two m files I submitted cover what I tried here.  FYI only:  The only test case that did not crash here is, in m file, to delete uitable and pause(2) before create a new uitable.  Without the pause(2), software still crashed.

Liang Tang <lt1234>
Tue 29 Nov 2022 10:24:57 AM UTC, comment #21: 

I'm attaching a patch that avoids the crashes for me by re-drawing the entire uitable each time the data changes.
That is most likely over-kill and it might be better to fix this on a more granular level (i.e., only when Boolean changes to non-Boolean or vice-versa, or only for the affected rows/columns/cells). But that would likely require major changes to the existing implementation.
The attached patch (while likely leading to a slow-down in uitable updates) is probably less likely to cause unexpected regressions. It would probably be fine to go on stable.

Does the patch also avoid the crashes for you?


(file #54036)

Markus Mützel <mmuetzel>
Group administrator
Thu 24 Nov 2022 04:00:03 PM UTC, comment #20: 

Arun, thanks. 

In additional to your recommendations, there are two more workaround possible:

(1) convert true/false to 'true'/'false' and handle with some small processing overhead.  I have not seen any issue for a table with mixed character and numeric types. 
(2) delete uitable and rebuild uitable every time the troublesome table contents change occurs.  

In the most recent m file I sent, (2) above may still crash w/o a pause(2), 2 is a arbitrary number, between delete and rebuild. So I am bit concern about the fast for-loop may be introducing some unintended things.

Liang Tang <lt1234>
Thu 24 Nov 2022 02:46:11 PM UTC, comment #19: 

Yes, Qt is very much external to Octave. If we can show the same crash from a standalone C++ program without Octave, then that can be submitted to the Qt maintainers as a bug report. Right now we don't have that sort of minimum reproducer.

The workaround so far to avoid the crash is to keep booleans as booleans. That is, for all your different forms, if one of them had a boolean in the 3rd location, that needs to be boolean for all your forms. Other data types can be switched as needed but booleans create a checkbox widget and that goes wrong somewhere. The cause isn't known yet.

Arun Giridhar <arungiridhar>
Group Member
Thu 24 Nov 2022 12:50:04 PM UTC, comment #18: 

Hi Arun,

I did try to read the files you sent yesterday evening.  But I don't have the ability to understand the traces you provided. 

I do have two questions:

(1) I assume that Qt is a 3rd party library. Correct?  If yes, is there a feasible mean to debug this issue w/o vendor involvement?
(2) From what I know in the distant past, crash mostly came from two sources: code error or corrupted memory.  Based on your observation, which one is more likely?

I attach another m file to reflect what I know from the comments you post.  The intention is to further simplify the test case. If it introduce more confusion, we don't need to use it.  

Using test_crash_submit_1([],[],7)  will not crash.  But cut/paste the associated lines, including the function definitions, into the command window, crashed 100% of time for me. 

The outcome from case 4 vs 5 is also surprising to me. 

Thanks,


(file #54008)

Liang Tang <lt1234>
Thu 24 Nov 2022 12:37:50 AM UTC, comment #17: 

I built Octave with these settings:

export CC="gcc"
export CXX="g++"
export F77="gfortran"
export CFLAGS="-pipe -march=native -O0 -ggdb3 -fsanitize=thread,undefined"
export CXXFLAGS="$CFLAGS"
export FFLAGS="$CFLAGS"

../configure --enable-64 --enable-openmp --disable-java --disable-docs --disable-lib-visibility-flags


(The disable-lib-visibility was required with "-fsanitize=undefined" otherwise it kept giving undefined symbol linker errors).

Running the two tests from the OP, there are several race conditions that show up. Attached logs if anyone finds them useful.

(file #54001, file #54002)

Arun Giridhar <arungiridhar>
Group Member
Mon 21 Nov 2022 03:59:40 PM UTC, comment #16: 

It is always the same for me. I sturt octave as "./run-octave -g"
and then running "test_crash_submit ([], [], 2)" results in


<...deleted...>
 [2,2] = 0.8000
  [3,2] = sus
}


Thread 1 "octave-gui" received signal SIGSEGV, Segmentation fault.
QWidget::show (this=0x60400156df50) at kernel/qwidget.cpp:7662
7662        void QWidget::show()


before I can even say "thread apply all bt".

I do see some differences -- sometimes it manages to pop-up the
gui window and sometimes it does not.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 21 Nov 2022 03:44:34 PM UTC, comment #15: 

I am attaching the results of multiple traces (had to compress it since it's more than 4 files). Each trial (whether "bt" or "thread apply all bt") was done in a fresh instance of gdb. All tests invoked the original post's "octave:1> test_crash_submit ([], [], 2)".

If using "bt" alone, then it crashes in the same place each time, in QWidget::show().

If using "thread apply all bt", it shows that it progresses to a different location each time before the crash is triggered, and there are memory access messages on subsequent runs, like "rhs=<error reading variable: Cannot create a lazy
string with address 0x0, and a non-zero length.>" which may be error messages from previous trials, but indicating the same problem.


(file #53987)

Arun Giridhar <arungiridhar>
Group Member
Mon 21 Nov 2022 01:33:47 PM UTC, comment #14: 

I haven't done any debugging, but if, as you say in comment #10, "The crashes seem to be happening in different locations on each run" then it seems like it could be a threading/data lifetime problem.

John W. Eaton <jwe>
Group administrator
Mon 21 Nov 2022 12:47:19 PM UTC, comment #13: 

After tracing it through set() in graphics.cc, I can't see anything that Octave should do differently. All the cases pass through the very last else-block in the big if-else ladder (Case V in the attached diagoostics diff). All that else block does is splice in the new argument to the argument list, and request a redraw through the local variable drawnow_requested, which in turn triggers a redraw through Vdrawnow_requested.

The bug does seem to be inside Qt as dasergatskov said. It seems to have trouble with constructing and destroying a checkbox in certain circumstances, such as replacing it with another widget like a string or a number.

Attaching a patch to add cout statements to graphics.cc, if anyone wants to trace the diagnostics.

(file #53979)

Arun Giridhar <arungiridhar>
Group Member
Mon 21 Nov 2022 12:13:27 PM UTC, comment #12: 

Take the code from comment #11 and change the subfunctions like this.
This works without any problems:

function parameters=opt_pso_parameters1(varargin);
  ii=0;
  ii=ii+1;parameters(ii).name='method';           parameters(ii).value='foofoo';
  ii=ii+1;parameters(ii).name='plotFun' ;         parameters(ii).value= 'barbar';
  ii=ii+1;parameters(ii).name='flagVectorize' ;   parameters(ii).value= false;
  ii=ii+1;parameters(ii).name='guessWeight';      parameters(ii).value= int8(1);
endfunction

function parameters=opt_pso_parameters2(varargin);
  ii=0;
  ii=ii+1;parameters(ii).name='method';           parameters(ii).value='bar';
  ii=ii+1;parameters(ii).name='guessWeight';      parameters(ii).value= 1.5;
  ii=ii+1;parameters(ii).name='flagVectorize' ;   parameters(ii).value= true;
  ii=ii+1;parameters(ii).name='plotFun' ;         parameters(ii).value= 'foo';
endfunction


But this seemingly trivial change (changing the order of two parameters)
causes a crash:

function parameters=opt_pso_parameters1(varargin);
  ii=0;
  ii=ii+1;parameters(ii).name='method';           parameters(ii).value='foofoo';
  ii=ii+1;parameters(ii).name='flagVectorize' ;   parameters(ii).value= false;
  ii=ii+1;parameters(ii).name='plotFun' ;         parameters(ii).value= 'barbar';
  ii=ii+1;parameters(ii).name='guessWeight';      parameters(ii).value= int8(1);
endfunction

function parameters=opt_pso_parameters2(varargin);
  ii=0;
  ii=ii+1;parameters(ii).name='method';           parameters(ii).value='bar';
  ii=ii+1;parameters(ii).name='guessWeight';      parameters(ii).value= 1.5;
  ii=ii+1;parameters(ii).name='flagVectorize' ;   parameters(ii).value= true;
  ii=ii+1;parameters(ii).name='plotFun' ;         parameters(ii).value= 'foo';
endfunction


So an extra clue is that if a parameter changes data type from boolean to something
else or vice versa, it causes a crash. If parameter #3 (say) in all the
different cases stays boolean, then it doesn't cause a crash. In other words:
constructing and destroying that checkbox to show a boolean is causing an error.

Arun Giridhar <arungiridhar>
Group Member
Mon 21 Nov 2022 11:59:02 AM UTC, comment #11: 

Trying to isolate the bug, I found that the cause of the crash is not passing the boolean by itself, but a combination of that with other things.

This test for me does not cause the crash. If you run it, you will see a checkbox blinking on and off as the code specifies.

function []=mytest3(varargin);

  opt_id=figure('name', 'Crash uitable', 'position', [300   200   600   800] , 'tag', 'main_figure' );

  init_parameters=cellfun(@num2str,num2cell(rand(2,2)), 'UniformOutput', false);

  h.table= uitable (opt_id, 'unit', 'normalized',   'Position', [ 0.15 0.15 0.70 0.70 ], ...
  'Data', init_parameters, 'ColumnName', {'Parameters', 'Values'}, 'units', 'normalized', ...
  'ColumnWidth', {200 200}, 'ColumnEditable',true, 'tag', 'uitable_crash' );

  for ii=1:20
    parameters=opt_pso_parameters1;
    parameters=struct2cell(parameters)
    set(findobj(0, 'tag', 'uitable_crash'), 'data', [parameters(1,:)' parameters(2,:)']);
    [parameters(1,:)' parameters(2,:)'];
    pause(0.25)

    parameters=opt_pso_parameters2;
    parameters=struct2cell(parameters)
    set(findobj(0, 'tag', 'uitable_crash'), 'data', [parameters(1,:)' parameters(2,:)']);
    [parameters(1,:)' parameters(2,:)'];
    pause(0.25)
  end
endfunction

function parameters=opt_pso_parameters1(varargin);
  ii=0;
  ii=ii+1;parameters(ii).name='method';           parameters(ii).value='global_opt';
  ii=ii+1;parameters(ii).name='guessWeight';      parameters(ii).value= 0.5;
  ii=ii+1;parameters(ii).name='flagVectorize' ;   parameters(ii).value= false;
  ii=ii+1;parameters(ii).name='plotFun' ;         parameters(ii).value= '';
endfunction

function parameters=opt_pso_parameters2(varargin);
  ii=0;
  ii=ii+1;parameters(ii).name='method';           parameters(ii).value='global_opt';
  ii=ii+1;parameters(ii).name='guessWeight';      parameters(ii).value= 0.5;
  ii=ii+1;parameters(ii).name='flagVectorize' ;   parameters(ii).value= true;
  ii=ii+1;parameters(ii).name='plotFun' ;         parameters(ii).value= '';
endfunction


Also if none of the parameter values have boolean, that works OK too (comment out the calls to PSO in the original test and call only the other subfunctions).

Changing size of parameters (only 3 in some, 4 in others) is also not a factor. I could add dummy fourth parameters to the smaller sets and the crash happened if booleans were mixed, and didn't happen if booleans weren't mixed.

Somehow having some of the parameters have booleans and the others not have booleans causes a crash.

I'm not sure yet if the bug is inside Qt or if we are somehow passing bad data to Qt. Next I'm adding cout statements to the set function in graphics.cc (near line 13000) to trace what happens.

Arun Giridhar <arungiridhar>
Group Member
Sun 20 Nov 2022 04:10:30 PM UTC, comment #10: 

With -ggdb3 instead of -g I could replicate dasergatskov's first-attempt crash as well. Trace attached.

The crashes seem to be happening in different locations on each run for me. I have attached the one that looks to be the most helpful.

This part is where it went wrong at least on that attempt:


#8  0x00007ffff6fee202 in std::__cxx11::list<octave::octave_lvalue, std::allocator<octave::octave_lvalue> >::push_back (this=0x7fffb77541f0, __x=...) at /usr/include/c++/12.2.0/bits/stl_list.h:1306
#9  0x00007ffff6febb56 in octave::tree_simple_assignment::evaluate (this=0x7fffac7bd810, tw=...) at ../libinterp/parse-tree/pt-assign.cc:90
#10 0x00007ffff7005516 in octave::tree_evaluator::visit_statement (this=0x7fffac0058d8, stmt=...) at ../libinterp/parse-tree/pt-eval.cc:3919
#11 0x00007ffff7034de8 in octave::tree_statement::accept (this=0x7fffac7bd850, tw=...) at ../libinterp/parse-tree/pt-stmt.h:124


The next statement (chronologically) is extremely long and looks like this after cutting for brevity:

#7  0x00007ffff6fee43e in std::__cxx11::list<octave::octave_lvalue, std::allocator<octave::octave_lvalue> >::_M_insert<octave::octave_lv
alue const&> (this=0x7fffb77541f0, __position={m_sym = {m_rep = <error reading variable: Cannot access memory at address 0x3ff0000000000
008>}, m_frame = <error reading variable: Cannot access memory at address 0x3ff0000000000008>, m_black_hole = true, m_type = "", m_idx =
 std::__cxx11::list = {[0] = {m_data = std::vector of length 17592010158985, capacity 17592010158985

(ETC ETC, ENDING WITH:)

annot access memory at address 0x4810408d480098ac><error reading variable: Cannot access memory at address 0x10ec8348e5894855>...}}) at /usr/include/c++/12.2.0/bits/stl_list.h:2005



(file #53977)

Arun Giridhar <arungiridhar>
Group Member
Sun 20 Nov 2022 03:58:27 PM UTC, comment #9: 

Just fyi, here is qwidget.cpp  around line 7662 (--> void QWidget::show())


/*!
    Shows the widget and its child widgets.

    This is equivalent to calling showFullScreen(), showMaximized(), or setVisible(true),
    depending on the platform's default behavior for the window flags.

     \sa raise(), showEvent(), hide(), setVisible(), showMinimized(), showMaximized(),
    showNormal(), isVisible(), windowFlags()
*/
void QWidget::show()
{
    Qt::WindowState defaultState = QGuiApplicationPrivate::platformIntegration()->defaultWindowState(data->window_flags);
    if (defaultState == Qt::WindowFullScreen)
        showFullScreen();
    else if (defaultState == Qt::WindowMaximized)
        showMaximized();
    else
        setVisible(true); // Don't call showNormal() as not to clobber Qt::Window(Max/Min)imized
}


Dmitri A. Sergatskov <dasergatskov>
Sun 20 Nov 2022 03:56:03 PM UTC, comment #8: 

Hi Dimitri and Arun,

My originally submitted m file contained three traps to represent what I had seen.  As a user, I want to catch "all" of them if there is more than one issue.  

(1) Crash in the first run
(2) Crash in the 2nd run "after the first figure is closed" - I am sure about that all the figures have been closed except one. 
(3) Crash - I must show the issue or this is a no-discussion.  With that in mind, I put the for-loop in.  I am assuming randomly occurring bad things will get caught this way.  You folks know, I don't, what those bad things might be.   

Thanks,

Liang Tang <lt1234>
Sun 20 Nov 2022 03:50:19 PM UTC, comment #7: 

Sorry, crossed with dasergatskov.

Building it with slightly different debug flags now to see if it's more repeatable for me.

Arun Giridhar <arungiridhar>
Group Member
Sun 20 Nov 2022 03:43:14 PM UTC, comment #6: 

Case 1 was much harder to crash but eventually I got one by putting it in an infinite loop like this:


while (true); close all; test_crash_submit ([], [], 1); endwhile


If this helps localize it: running that test function when there are no figures makes it crash very little. Running it when there's already a figure hanging around from a previous run causes it to crash more quickly. (Remove the "close all" from the above while-loop.)

Stack trace attached.

(file #53976)

Arun Giridhar <arungiridhar>
Group Member
Sun 20 Nov 2022 03:36:26 PM UTC, comment #5: 

Test #2 crashes the same way:


octave:1> cd ~/Downloads/
octave:2> test_crash_submit([],[],2)
warning: set: allowing unit to match uitable property units
warning: called from
    uitable at line 224 column 8
    test_crash_submit at line 7 column 8

ans =
{

<...deleted...>
  [2,2] = 0.5000
  [3,2] = 0
  [4,2] =
}


Thread 1 "octave-gui" received signal SIGSEGV, Segmentation fault.
QWidget::show (this=0x604001575a90) at kernel/qwidget.cpp:7662
7662        void QWidget::show()



This is hg id
2ec625c04947 (stable)

on Fedora 35

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 20 Nov 2022 03:32:26 PM UTC, comment #4: 

If I compile w/ debugging (-O0 -ggdb3) flags, the first test
crashes on the very first run:


octave:1> cd ~/Downloads/
octave:2> test_crash_submit([],[],1);
warning: set: allowing unit to match uitable property units
warning: called from
    uitable at line 224 column 8
    test_crash_submit at line 7 column 8

ans =
{
  [1,1] = method
  [2,1] = MaxFunEvals
  [3,1] = obj_fcn_form
  [1,2] = global_opt
  [2,2] = 500
  [3,2] = classical
}

ans =
{
  [1,1] = method
  [2,1] = guessWeight
  [3,1] = flagVectorize
  [4,1] = plotFun
  [1,2] = global_opt
  [2,2] = 0.5000
  [3,2] = 0
  [4,2] =
}

ans =
{
  [1,1] = method
  [2,1] = GGAP
  [3,1] = SEL_F
  [1,2] = global_opt
  [2,2] = 0.8000
  [3,2] = sus
}

ans =
{
  [1,1] = method
  [2,1] = guessWeight
  [3,1] = flagVectorize
  [4,1] = plotFun
  [1,2] = global_opt
  [2,2] = 0.5000
  [3,2] = 0
  [4,2] =
}

octave:3>
Thread 1 "octave-gui" received signal SIGSEGV, Segmentation fault.
QWidget::show (this=0x60400155d050) at kernel/qwidget.cpp:7662
7662        void QWidget::show()
<...deleted...>
Thread 1 (Thread 0x7fffedef6380 (LWP 3056905) "octave-gui"):
#0  QWidget::show() (this=0x60400155d050) at kernel/qwidget.cpp:7662
#1  0x00007ffff2e2cbbd in QAbstractItemView::updateEditorGeometries() (this=0x6040015d2110) at itemviews/qabstractitemview.cpp:2732
#2  0x00007ffff2e2417b in QAbstractItemView::updateGeometries() (this=0x6040015d2110) at itemviews/qabstractitemview.cpp:2765
#3  0x00007ffff2e238d1 in QAbstractItemView::doItemsLayout() (this=0x6040015d2110) at itemviews/qabstractitemview.cpp:1222
#4  0x00007ffff2e85d0e in QTableView::doItemsLayout() (this=<optimized out>) at itemviews/qtableview.cpp:1262
#5  0x00007ffff2e275e2 in QAbstractItemView::timerEvent(QTimerEvent*) (this=0x6040015d2110, event=<optimized out>) at itemviews/qabstractitemview.cpp:2552
#6  0x00007ffff1ed12cf in QObject::event(QEvent*) (this=this@entry=0x6040015d2110, e=e@entry=0x7fffffffbd90) at kernel/qobject.cpp:1336
#7  0x00007ffff2bf0ed9 in QWidget::event(QEvent*) (this=this@entry=0x6040015d2110, event=event@entry=0x7fffffffbd90) at kernel/qwidget.cpp:9081
#8  0x00007ffff2c9ea22 in QFrame::event(QEvent*) (this=0x6040015d2110, e=0x7fffffffbd90) at widgets/qframe.cpp:550
#9  0x00007ffff2bae443 in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=<optimized out>, receiver=0x6040015d2110, e=0x7fffffffbd90) at kernel/qapplication.cpp:3632
#10 0x00007ffff69a3295 in octave::octave_qapplication::notify(QObject*, QEvent*) (this=0x6020000063d0, receiver=0x6040015d2110, ev=0x7fffffffbd90) at ../libgui/src/octave-qobject.cc:148

<...deleted...>


Entire bt is attached.

This looks like a bug in Qt library.

Dmitri.
--


(file #53975)

Dmitri A. Sergatskov <dasergatskov>
Sun 20 Nov 2022 03:01:20 PM UTC, comment #3: 

Hi Arun,

Please also run the case #1 on your debug code. My read from the log is that crash is before the end of the first for-loop.  That is also something that I had seen.  The for-loop was meant to make sure that the issue shows consistently.  Thanks.

Liang Tang <lt1234>
Sun 20 Nov 2022 02:46:10 PM UTC, comment #2: 

Stack trace attached.

Debug settings:

export CC="gcc"
export CXX="g++"
export F77="gfortran"
export CFLAGS="-pipe -march=native -O0 -g"
export CXXFLAGS="-pipe -march=native -O0 -g"
export FFLAGS="-pipe -march=native -O0 -g"

../configure --enable-largefile --enable-year2038 --enable-threads=posix --enable-64 --enable-openmp --enable-readline --disable-java --disable-docs



(file #53974)

Arun Giridhar <arungiridhar>
Group Member
Sun 20 Nov 2022 02:22:07 PM UTC, comment #1: 

Confirmed. I can replicate Crash #2 every time on the dev tree (Octave 8 and Octave 9) on Linux, so setting OS to Any.

The crash also happens when "false" is changed to logical(0) or logical(1).

Building a new debug version. Hope to get a stack trace...

Arun Giridhar <arungiridhar>
Group Member
Sun 20 Nov 2022 01:30:22 PM UTC, original submission:  

I experienced two conditions Octave crashed with uitable.  6.3.0 also crashed with the same commands.  I run windows 10 64x without memory compression.   Please see the attached function m file.

Octave may crash with true/false appearing in the uitable data.   W/o true/false data, there is no issue for me. 

(1) Octave crashed during the 2nd run of the same function in a same Octave session.  Sometime m file works, sometime it does not. So the observation I have here may not be repeated by myself consistently. Use these commands in the command window:

test_crash_submit([],[],1); close figure manually; test_crash_submit([],[],1) % crash here

(2) Octave crashes with uitable true/false data.  100% repeatable in my environment. Please see the m file.  The for-loop is to emulate the mouse clicks. 

Use this command in the command window:

test_crash_submit([],[],2) % crash here

Thanks,


Liang Tang <lt1234>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #54008:  test_crash_submit_1.m added by lt1234 (11KiB - application/octet-stream)
file #53987:  trace.7z added by arungiridhar (7KiB - application/x-7z-compressed)
file #53979:  set_diagnostics.patch added by arungiridhar (4KiB - text/x-patch)
file #53975:  das_bt.txt.gz added by dasergatskov (4KiB - application/gzip)
file #53974:  stacktrace.log added by arungiridhar (32KiB - text/x-log)
file #53973:  test_crash_submit.m added by lt1234 (5KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by dasergatskov (Updated the item)
  • -email is unavailable- added by arungiridhar (Posted a comment)
  • -email is unavailable- added by lt1234 (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 20 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-12-03 arungiridhar StatusReady For Test Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNone 8.1.0
    2022-11-29 mmuetzel StatusPatch Submitted Ready For Test
        Planned ReleaseNone 8.1.0
    2022-11-29 mmuetzel Attached File- Added bug63388-uitable-Boolean.patch, #54036
        StatusConfirmed Patch Submitted
    2022-11-24 lt1234 Attached File- Added test_crash_submit_1.m, #54008
    2022-11-24 arungiridhar Attached File- Added case1_thread_undefined.log, #54001
        Attached File- Added case2_thread_undefined.log, #54002
    2022-11-21 arungiridhar Attached File- Added trace.7z, #53987
    2022-11-21 arungiridhar Attached File- Added set_diagnostics.patch, #53979
    2022-11-20 arungiridhar Attached File- Added stacktrace_case1_ggdb3B.log, #53977
    2022-11-20 arungiridhar Attached File- Added stacktrace_case1.log, #53976
    2022-11-20 dasergatskov Attached File- Added das_bt.txt.gz, #53975
    2022-11-20 arungiridhar Attached File- Added stacktrace.log, #53974
    2022-11-20 arungiridhar StatusNone Confirmed
        Release7.1.0 dev
        Operating SystemMicrosoft Windows Any
    2022-11-20 lt1234 Attached File- Added test_crash_submit.m, #53973

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code