bugGNU Octave - Bugs: bug #58957, [octave forge] (sparsersb) Failure...

 
 

bug #58957: [octave forge] (sparsersb) Failure to install and crash in function

Submitted by:  John Donoghue <lostbard>
Submitted on:  Fri 14 Aug 2020 06:32:59 PM UTC  
 
Category:  Octave Forge Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  None Assigned to:  None
Originator Name:  JohnD Open/Closed:  Open
Release:  dev Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Wed 23 Sep 2020 06:10:55 PM UTC, comment #48: 

yes - just calling it once

John Donoghue <lostbard>
Project Member
Wed 23 Sep 2020 03:58:22 PM UTC, comment #47: 

Please don't use that line, but repeat the test with:

> for i=1:1000; sparsersb(sparsersb([1]),"render", "crash.eps" ,1024); endfor


that is more deterministic than using sprand (let's put that aside). Does it crash now ?

dezperado <dezperado>
Wed 23 Sep 2020 03:34:09 PM UTC, comment #46: 

After adding in the pkg load:

> pkg load sparsersb

SPARSERSB.INIT

>> rrm=sparsersb(sprand(1000,1000,0.001));


>> sparsersb(rrm,"render", "sparsersb_temporary_render.eps" ,1024);


    • crash ***

(gdb) where
#0  0x00007ff92fa591b3 in ntdll!RtlIsNonEmptyDirectoryReparsePointAllowed ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ff92fa615e2 in ntdll!RtlpNtMakeTemporaryKey ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x00007ff92fa618ea in ntdll!RtlpNtMakeTemporaryKey ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#3  0x00007ff92fa6a8a9 in ntdll!RtlpNtMakeTemporaryKey ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x00007ff92f9a080d in ntdll!RtlGetCurrentServiceSessionId ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x00007ff92f99fb91 in ntdll!RtlFreeHeap ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x00007ff92efd9cfc in msvcrt!free () from C:\WINDOWS\System32\msvcrt.dll
#7  0x00007ff92f01a0f8 in ungetwc () from C:\WINDOWS\System32\msvcrt.dll
#8  0x00007ff92f00cb19 in msvcrt!clearerr_s ()
   from C:\WINDOWS\System32\msvcrt.dll
#9  0x00007ff92f00cbc0 in msvcrt!fclose () from C:\WINDOWS\System32\msvcrt.dll
#10 0x0000000032e07b58 in rsb__do_mtx_render (
    filename=0x2e3c3550 "sparsersb_temporary_render.eps", mtxAp=0x2f521070,
    pmWidth=pmWidth@entry=1024, pmHeight=pmHeight@entry=512, rflags=48)
    at rsb_eps.c:1111
#11 0x0000000032b1b4c5 in rsb_mtx_rndr (filename=<optimized out>,
    mtxAp=<optimized out>, pmWidth=pmWidth@entry=1024,
    pmHeight=pmHeight@entry=512, rflags=rflags@entry=48) at rsb_rsb.c:1317

John Donoghue <lostbard>
Project Member
Wed 23 Sep 2020 12:41:47 PM UTC, comment #45: 

Thanks John. Can you please try it out under Windows using file #49851 as a basis, to check if this solves the crash ?

dezperado <dezperado>
Wed 23 Sep 2020 12:23:07 PM UTC, comment #44: 

You need something thatwill call the init function, for init fltk its handled by the graphics toolkit manager.

You can do a similar load on pkg load by placing PKG_ADD statements in the sources.

In addition since there are now multiple octave callable functions in the .oct file, you will need to add autlod statements for each in the source.

// PKG_ADD: autoload ("__init_sparsersb__", "sparsersb.oct");
// PKG_ADD: autoload ("sparsersb", "sparsersb.oct");
// PKG_ADD: _init_sparsersb_();

That will create a PKG_ADD file when the package gets installed that will be run when the pkg is loaded.

John Donoghue <lostbard>
Project Member
Wed 23 Sep 2020 09:13:23 AM UTC, comment #43: 

I attach a sparsersb.cc with added mlock init as:

2701 static octave_value_list
2702 F__librsb_check__ (octave::interpreter& interp, const octave_value_list&, int)
2703 {
2704   // empty for now.
2705   return octave_value_list ();
2706 }
2707
2708 DEFMETHOD_DLD (__init_sparsersb__ , interp, , ,
2709                " -*- texinfo -*-\n\
2710 @deftypefn {} {} __init_sparsersb__ ()\n\
2711 Undocumented internal function.\n\
2712 @end deftypefn ")
2713 {
2714   if (! rsboi_sparse_rsb_loaded )
2715     {
2716       interp.mlock ();
2717
2718       install_sparse_rsb();
2719       std::cout << "SPARSERSB.INIT\n";
2720     }
2721
2722   return octave_value_list ();
2723 }

On my Linux box, I must say _init_sparsersb_ seems not to trigger.
Please let me know if it makes sense on the Window build at least.

(file #49851)

dezperado <dezperado>
Wed 23 Sep 2020 07:13:41 AM UTC, comment #42: 

sparsersb by itself will initialize librsb once, and the install_sparse_rsb invocation at each sparsersb() invocation is no performance cost.

But if on Windows Octave might sweep sparsersb status out of memory in between sparsersb calls, this is surely a problem.

You are suggesting mimicking _init_fltk_ . So I looked at it, and I'm trying creating a _init_sparsersb_, but I find a difficulty with 'doc:' and I'm not enough into Octave internals to figure it out quickly -- do you have a suggestion ? Please see

+verbatim
2718 DEFMETHOD_DLD (_init_sparsersb_ , interp, , ,                                                                                                                                                                                         
2719                doc: /* -*- texinfo -*-
2720 @deftypefn {} {} _init_sparsersb_ ()
2721 Undocumented internal function.
2722 @end deftypefn */)
-verbatim
in the attached sources.

(file #49848)

dezperado <dezperado>
Wed 23 Sep 2020 06:32:14 AM UTC, comment #41: 

Not sure if I got this right. But instead of repeatedly initializing and freeing rsb, it might be easier (and more performant) to lock the necessary function(s) in memory.
See e.g. here for how it is done in `__init_fltk__` for the `fltk_graphics_toolkit`:
https://hg.savannah.gnu.org/hgweb/octave/file/39997caa42f6/libinterp/dldfcn/__init_fltk__.cc#l2511

Markus Mützel <mmuetzel>
Project Member
Wed 23 Sep 2020 06:20:44 AM UTC, comment #40: 

Yes: calling `rsb_mtx_rndr` without prior `rsb_lib_init` is a consistent recipe for crash!

sparsersb.oct expects one initialization only via rsb_lib_init.
Or at least, no re-calling of rsb_lib_init unless memory is being freed (e.g. matrices destroyed) and rsb_lib_exit called before.

Depending on the librsb configure options (memory debugging ones), it might be easier to spot that (at a cost, though).

dezperado <dezperado>
Wed 23 Sep 2020 06:08:44 AM UTC, comment #39: 

Since you mentioned "rsb_lib_init": IIRC, there was an issue with one of the .oct files in Octave core that lead to similar crashes on Windows because the module stack was lost between calls (or something like that...).
That was solved by `mlock`ing that file.

Could that be causing the issues here, too? I.e., could (effectively) calling `rsb_mtx_rndr` without prior `rsb_lib_init` cause such a crash?

Markus Mützel <mmuetzel>
Project Member
Tue 22 Sep 2020 10:55:02 PM UTC, comment #38: 

Hi Markus.

Well, you did the test I asked you: compiling and running that program; thanks.

For coherence with what you observed, most of that program's main() block (all except for the rsb_lib_init() line) shall be substitutible to the rsb_mtx_rndr() call in sparsersb.cc, and you should expect the same crash. And if not, that may hint to a possible innocence of rsb_mtx_rndr ..

dezperado <dezperado>
Tue 22 Sep 2020 04:59:38 PM UTC, comment #37: 

Sorry, I'm not sure I understand what I am supposed to do.
I cross-built Octave with all its dependencies (including librsb) for Windows on Linux with MXE Octave.
MXE Octave cleans up the build directories of each package it has built. I no longer have a librsb build directory.
Instead, I have an msys2 environment with installed gcc and librsb. That is the same librsb that Octave is using.
So, I ran the following at the msys2 shell:

$ gcc rsb_mtx_rndr.c -otest.exe -lrsb -fopenmp
$ gdb test.exe
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test.exe...
(gdb) r
Starting program: D:\SVN\Octave\bug58957\test.exe
[New Thread 23092.0x2fe4]
[New Thread 23092.0x590]
[New Thread 23092.0x4d50]
[New Thread 23092.0x3f74]
[New Thread 23092.0x15dc]
[New Thread 23092.0xde4]
OK
[Thread 23092.0xde4 exited with code 0]
[Thread 23092.0x15dc exited with code 0]

Is this a meaningful test? In case it is: The test program didn't crash.
I ran the program about 20-30 times but it never crashed.

I am attaching the "crash.eps" file that was created by that program in case that helps.

One difference is that this test program was built natively on Windows. "sparsersb" was cross-built on Linux for Windows.
To test if that makes a difference, I re-built and re-installed sparsersb on Windows. In Octave:

>> pkg install -forge sparsersb
warning: LFLAGS is deprecated and will be removed in a future version of Octave, use LDFLAGS instead
For information about changes from previous versions of the sparsersb package, run 'news sparsersb'.
>> pkg load sparsersb
>> pkg list
[...]
          sparsersb *|   1.0.8 | C:\Users\Markus\octave\sparsersb-1.0.8
[...]
>> sparsersb(sparsersb([1]),"render", "crash.eps" ,1024);

But Octave crashed on the last command.

(file #49838)

Markus Mützel <mmuetzel>
Project Member
Mon 21 Sep 2020 07:14:56 PM UTC, comment #36: 

Hi Markus,

Ok, let's continue investigating with the 64-bit build.

I am attaching a program mimicking the
 sparsersb(sparsersb([1]),"render", "crash.eps" ,1024);
crashing sequence.

Could you please substitute it to that of examples/transpose.c in a configured librsb build directory, then  re-run 'make', and then run ./transpose to check if it crashes ?

(file #49834)

dezperado <dezperado>
Mon 21 Sep 2020 03:46:09 PM UTC, comment #35: 

With a 32bit build, the loop completed once without issues. Running it multiple times crashed Octave (alongside the attached gdb). No backtrace for that unfortunately.
But I'm starting to get the impression that something unrelated is off with the 32bit Windows build anyway.

So maybe we should focus on the 64bit build first.
With it, Octave crashes on the first run of the loop.
Backtrace from gdb:

warning: Critical error detected c0000374

Thread 26 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 6520.0x4d34]
0x00007ffb33b2ed03 in ntdll!RtlIsZeroMemory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb) bt
#0  0x00007ffb33b2ed03 in ntdll!RtlIsZeroMemory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ffb33b37ae2 in ntdll!RtlpNtSetValueKey ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x00007ffb33b37dca in ntdll!RtlpNtSetValueKey ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#3  0x00007ffb33b3d7f1 in ntdll!RtlpNtSetValueKey ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x00007ffb33a49640 in ntdll!RtlAllocateHeap ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x00007ffb33a45d21 in ntdll!RtlFreeHeap ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x00007ffb31bc9c9c in msvcrt!free () from C:\WINDOWS\System32\msvcrt.dll
#7  0x0000000086d56fae in rsb__free (p=0x5ff76560) at rsb_sys.c:389
#8  0x0000000086a7398b in rsb__destroy_coo_matrix_t (cmp=0x5cd8b1d0)
    at rsb_internals.c:247
#9  0x0000000086d56998 in rsb_dump_postscript_from_mtx_t (br=1, bc=1,
    all_nnz=1, height=512, width=1024, mtxAp=0x5f8569c0,
    fd=0x7ffb31c3fb20 <msvcrt!_iob+288>) at rsb_eps.c:959
#10 rsb__do_mtx_render (filename=0x5cd8b3f0 "crash.eps", mtxAp=0x5f8569c0,
    pmWidth=1024, pmHeight=512, rflags=48) at rsb_eps.c:1101
#11 0x0000000086a67578 in Fsparsersb (args=..., nargout=0)
    at sparsersb.cc:2926
#12 0x000000000127aa77 in octave_builtin::execute (this=0x5e4a4e70, tw=...,
--Type <RET> for more, q to quit, c to continue without paging--c
    nargout=0, args=...) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov-builtin.cc:59
#13 0x00000000012bb9c4 in octave_function::call (this=0x5e4a4e70, tw=..., nargout=0, args=...) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov-fcn.cc:57
#14 0x00000000013b7af1 in octave::tree_index_expression::evaluate_n (this=0x840626f0, tw=..., nargout=0) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-idx.cc:526
#15 0x0000000001d5ffdf in octave::tree_index_expression::evaluate (this=<optimized out>, tw=..., nargout=<optimized out>) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-idx.h:109
#16 0x00000000013ac760 in octave::tree_evaluator::visit_statement (this=0x5f4850c0, stmt=...) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-eval.cc:3239
#17 0x000000000139af2c in octave::tree_statement::accept (tw=..., this=0x5c129fd0) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-stmt.h:124
#18 octave::tree_evaluator::visit_statement_list (this=0x5f4850c0, lst=...) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-eval.cc:3298
#19 0x00000000013abcca in octave::tree_statement_list::accept (tw=..., this=0x82011ad0) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-stmt.h:201
#20 octave::tree_evaluator::execute_range_loop<double> (loop_body=0x82011ad0, ult=..., line=1, rng=..., this=0x5f4850c0) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-eval.cc:2516
#21 octave::tree_evaluator::visit_simple_for_command (this=0x5f4850c0, cmd=...) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-eval.cc:2566
#22 0x00000000013ac6b0 in octave::tree_evaluator::visit_statement (this=0x5f4850c0, stmt=...) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-eval.cc:3216
#23 0x000000000139af2c in octave::tree_statement::accept (tw=..., this=0x5c12a090) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-stmt.h:124
#24 octave::tree_evaluator::visit_statement_list (this=0x5f4850c0, lst=...) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-eval.cc:3298
#25 0x000000000139b49a in octave::tree_statement_list::accept (tw=..., this=<optimized out>) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-stmt.h:201
#26 octave::tree_evaluator::eval (this=0x5f4850c0, stmt_list=..., interactive=<optimized out>) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-eval.cc:403
#27 0x00000000016d24f0 in octave::interpreter::main_loop (this=this@entry=0x5f484360) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/corefcn/interpreter.cc:1278
#28 0x00000000016d6baa in octave::interpreter::execute (this=this@entry=0x5f484360) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/corefcn/interpreter.cc:806
#29 0x000000003a402c78 in octave::interpreter_qobject::execute (this=0x59064af0) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libgui/src/interpreter-qobject.cc:87
#30 0x000000003a4aaf5d in octave::interpreter_qobject::qt_static_metacall (_o=0x137156804d730000, _id=<optimized out>, _a=0x5f8569c0, _c=<optimized out>) at libgui/src/moc-interpreter-qobject.cc:96
#31 0x0000000066945c16 in QObject::event(QEvent*) () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Core.dll
#32 0x00000000578b7953 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Widgets.dll
#33 0x00000000578c058e in QApplication::notify(QObject*, QEvent*) () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Widgets.dll
#34 0x000000003a450d66 in octave::octave_qapplication::notify (this=0x59079ca0, receiver=<optimized out>, ev=<optimized out>) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libgui/src/octave-qobject.cc:132
#35 0x000000006691ac8a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Core.dll
#36 0x0000000066921561 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Core.dll
#37 0x0000000066974d5f in QEventDispatcherWin32::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Core.dll
#38 0x0000000066919963 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Core.dll
#39 0x0000000066758ef0 in QThread::run() () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Core.dll
#40 0x0000000066759ae3 in QThread::setTerminationEnabled(bool) () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Core.dll
#41 0x00007ffb33116fd4 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
#42 0x00007ffb33a7cec1 in ntdll!RtlUserThreadStart () from C:\WINDOWS\SYSTEM32\ntdll.dll
#43 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

librsb-1.2.0.9 was configured with:

autoreconf -fi && ./configure --host='x86_64-w64-mingw32' --build='x86_64-pc-linux-gnu' --prefix='/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/x86_64-w64-mingw32' --enable-shared --disable-static CPPFLAGS='-I/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/x86_64-w64-mingw32/include' LDFLAGS='-L/home/osboxes/Documents/Repositories/Octave/mxe-octave/usr/x86_64-w64-mingw32/lib' --disable-c-examples --disable-fortran-examples --disable-sparse-blas-interface --disable-octave-testing

The full configure and build log of librsb is attached in case that helps.

(file #49830)

Markus Mützel <mmuetzel>
Project Member
Mon 21 Sep 2020 02:10:52 PM UTC, comment #34: 

Thanks Markus.

What about

for i=1:1000; sparsersb(sparsersb([1]),"render", "crash.eps" ,1024); endfor

 -- does it crash on any of the 32 or 64 bit builds you used in comment #33 ?

BTW, if bug #58790 is triggered by memory allocation failures, then I find it difficult to occur in the cases here, which use minimal amounts of memory...

p.s. I'm back at a keyboard after a few weeks off.

dezperado <dezperado>
Sun 13 Sep 2020 12:33:51 PM UTC, comment #33: 

Thanks.

Tried with a Windows 32bit build with the new versions changes (Octave hg id 08049eff8733 and MXE Octave hg id b982f2df58cf).
That means the tests are done with of-sparsersb-1.0.8 and librsb-1.2.0.9:

The code from comment #0 doesn't crash Octave. Not even if I call it 1000 times in a loop.

"pkg test sparsersb" crashes Octave without gdb being able to catch anything. That might be bug #58790 striking again.

So I tried again with the same sources but a Windows 64bit build.
Running "pkg test sparsersb" still crashes Octave. But ´gdb´ is able to catch the error.
Part of the gdb session with top of the backtrace:

warning: Critical error detected c0000374

Thread 25 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 17608.0xcb4]
0x00007ff806cced03 in ntdll!RtlIsZeroMemory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb) bt
#0  0x00007ff806cced03 in ntdll!RtlIsZeroMemory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ff806cd7ae2 in ntdll!RtlpNtSetValueKey ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x00007ff806cd7dca in ntdll!RtlpNtSetValueKey ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#3  0x00007ff806cdd7f1 in ntdll!RtlpNtSetValueKey ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x00007ff806be9640 in ntdll!RtlAllocateHeap ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x00007ff806be5d21 in ntdll!RtlFreeHeap ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x00007ff806b09c9c in msvcrt!free () from C:\WINDOWS\System32\msvcrt.dll
#7  0x0000000086516fae in rsb__free (p=0x593a2de0) at rsb_sys.c:389
#8  0x000000008623398b in rsb__destroy_coo_matrix_t (cmp=0x5ac56540)
    at rsb_internals.c:247
#9  0x0000000086516998 in rsb_dump_postscript_from_mtx_t (br=1, bc=1,
    all_nnz=1, height=512, width=1024, mtxAp=0x604027d0,
    fd=0x7ff806b7fb50 <msvcrt!_iob+336>) at rsb_eps.c:959
#10 rsb__do_mtx_render (filename=0x84a1e0a0 "sparsersb_temporary_render.eps",
    mtxAp=0x604027d0, pmWidth=1024, pmHeight=512, rflags=48) at rsb_eps.c:1101
#11 0x0000000086227578 in Fsparsersb (args=..., nargout=0)
    at sparsersb.cc:2926
#12 0x000000000126aa77 in octave_builtin::execute (this=0x5770e010, tw=...,
--Type <RET> for more, q to quit, c to continue without paging--c
    nargout=0, args=...) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov-builtin.cc:59
#13 0x00000000012ab9c4 in octave_function::call (this=0x5770e010, tw=..., nargout=0, args=...) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov-fcn.cc:57

Same again for the example in comment #0:

warning: Critical error detected c0000374

Thread 25 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 16084.0x3ecc]
0x00007ff806cced03 in ntdll!RtlIsZeroMemory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb) bt
#0  0x00007ff806cced03 in ntdll!RtlIsZeroMemory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x00007ff806cd7ae2 in ntdll!RtlpNtSetValueKey ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x00007ff806cd7dca in ntdll!RtlpNtSetValueKey ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#3  0x00007ff806cdd7f1 in ntdll!RtlpNtSetValueKey ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x00007ff806be9640 in ntdll!RtlAllocateHeap ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x00007ff806be5d21 in ntdll!RtlFreeHeap ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x00007ff806b09c9c in msvcrt!free () from C:\WINDOWS\System32\msvcrt.dll
#7  0x00007ff806b49ef0 in ungetwc () from C:\WINDOWS\System32\msvcrt.dll
#8  0x00007ff806b3c9c9 in msvcrt!clearerr_s ()
   from C:\WINDOWS\System32\msvcrt.dll
#9  0x00007ff806b3ca70 in msvcrt!fclose () from C:\WINDOWS\System32\msvcrt.dll
#10 0x0000000086516898 in rsb__do_mtx_render (
    filename=0x82240f90 "sparsersb_temporary_render.eps", mtxAp=0x60a7b010,
    pmWidth=1024, pmHeight=512, rflags=48) at rsb_eps.c:1111
#11 0x0000000086227578 in Fsparsersb (args=..., nargout=0)
    at sparsersb.cc:2926
#12 0x000000000119aa77 in octave_builtin::execute (this=0x57772a00, tw=...,
    nargout=0, args=...)
--Type <RET> for more, q to quit, c to continue without paging--c
    at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov-builtin.cc:59
#13 0x00000000011db9c4 in octave_function::call (this=0x57772a00, tw=..., nargout=0, args=...) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/octave-value/ov-fcn.cc:57
#14 0x00000000012d7af1 in octave::tree_index_expression::evaluate_n (this=0x5fb30550, tw=..., nargout=0) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-idx.cc:526
#15 0x0000000001c7ffdf in octave::tree_index_expression::evaluate (this=<optimized out>, tw=..., nargout=<optimized out>) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-idx.h:109
#16 0x00000000012cc760 in octave::tree_evaluator::visit_statement (this=0x5a7dc570, stmt=...) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-eval.cc:3239
#17 0x00000000012baf2c in octave::tree_statement::accept (tw=..., this=0x822ef630) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-stmt.h:124
#18 octave::tree_evaluator::visit_statement_list (this=0x5a7dc570, lst=...) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-eval.cc:3298
#19 0x00000000012bb49a in octave::tree_statement_list::accept (tw=..., this=<optimized out>) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-stmt.h:201
#20 octave::tree_evaluator::eval (this=0x5a7dc570, stmt_list=..., interactive=<optimized out>) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/parse-tree/pt-eval.cc:403
#21 0x00000000015f24f0 in octave::interpreter::main_loop (this=this@entry=0x5a7db810) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/corefcn/interpreter.cc:1278
#22 0x00000000015f6baa in octave::interpreter::execute (this=this@entry=0x5a7db810) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libinterp/corefcn/interpreter.cc:806
#23 0x000000003bc82c78 in octave::interpreter_qobject::execute (this=0x575f9b00) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libgui/src/interpreter-qobject.cc:87
#24 0x000000003bd2af5d in octave::interpreter_qobject::qt_static_metacall (_o=0xb5869fedff1e0000, _id=<optimized out>, _a=0x8652860a <__mingw_vfprintf+58>, _c=<optimized out>) at libgui/src/moc-interpreter-qobject.cc:96
#25 0x0000000066945c16 in QObject::event(QEvent*) () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Core.dll
#26 0x000000005d4e7953 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Widgets.dll
#27 0x000000005d4f058e in QApplication::notify(QObject*, QEvent*) () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Widgets.dll
#28 0x000000003bcd0d66 in octave::octave_qapplication::notify (this=0x5760d370, receiver=<optimized out>, ev=<optimized out>) at /home/osboxes/Documents/Repositories/Octave/mxe-octave/tmp-default-octave/octave-7.0.0/libgui/src/octave-qobject.cc:132
#29 0x000000006691ac8a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Core.dll
#30 0x0000000066921561 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Core.dll
#31 0x0000000066974d5f in QEventDispatcherWin32::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Core.dll
#32 0x0000000066919963 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Core.dll
#33 0x0000000066758ef0 in QThread::run() () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Core.dll
#34 0x0000000066759ae3 in QThread::setTerminationEnabled(bool) () from D:\SVN\Octave\test\OC67B0~1\OCTAVE~1\mingw64\bin\Qt5Core.dll
#35 0x00007ff804d36fd4 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
#36 0x00007ff806c1cec1 in ntdll!RtlUserThreadStart () from C:\WINDOWS\SYSTEM32\ntdll.dll
#37 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

So, it looks like the 32bit version might be ok. But the 64bit version crashes.

Markus Mützel <mmuetzel>
Project Member
Sun 13 Sep 2020 12:14:03 AM UTC, comment #32: 

Pushed the new versions

John Donoghue <lostbard>
Project Member
Fri 11 Sep 2020 09:18:06 PM UTC, comment #31: 

I can push the update for sparser/libsrb
Although it appeared to be crashing in the way

John Donoghue <lostbard>
Project Member
Fri 11 Sep 2020 06:24:06 PM UTC, comment #30: 

I rebuilt Octave and dependencies without stripping symbols and got the backtraces for the crashes with "pkg test" and the "render" command from comment #0. They now include line numbers to the sources.
I hope these are more helpful.

This is still with librsb 1.2.0.8 and sparsersb 1.0.7.
Does it even make sense to test with these versions? Or should I better wait for a patch that updates MXE Octave to build newer versions?

(file #49787, file #49788)

Markus Mützel <mmuetzel>
Project Member
Fri 11 Sep 2020 06:20:51 AM UTC, comment #29: 

The configure script of of-sparsersb seems to execute ´sizemax() > intmax ("int32")´ in Octave to check if octave_idx_type is 64bit:
https://sourceforge.net/p/octave/sparsersb/ci/default/tree/src/configure.ac (currently in line 129)

This is unreliable when cross-building for an incompatible platform (e.g. mingw binaries on a linux build system) because the native Octave might have been configured differently from the target.

Would it be possible to remove that test? Or at least to not set RSBOI_DETECTED_LONG_IDX when cross-compiling?

Markus Mützel <mmuetzel>
Project Member
Thu 03 Sep 2020 06:28:56 AM UTC, comment #28: 

The backtrace was captured with an installation from the current release candidate of Octave 6.0.90 as available on alpha.gnu.org.
That is not a debug build. So the symbols have been stripped and compiler optimizations are active. (Please, correct me if that is wrong.)
The former means that there are no line numbers to the source files and that function names are mangled.
The latter means that the compiler might have optimized out some variables and might have inlined some functions.

Maybe the compiler inlined a function call in "rsb.do_mtx_render" which might explain a "missing" layer in the stack.

Markus Mützel <mmuetzel>
Project Member
Wed 02 Sep 2020 10:38:45 PM UTC, comment #27: 

The without symbolds is just that they get stripped in the mxe octave version so are not available.

John Donoghue <lostbard>
Project Member
Wed 02 Sep 2020 10:38:02 PM UTC, comment #26: 

To be clear, the bug report was opened originally for the new version of sparser and librsb which I was in the process of verifying before setting in mxe.

In comment #22, i tried the old mxe-octave 5.2 that had the older version and it was crashing the same as it does in the 6.0.90 older version.

John Donoghue <lostbard>
Project Member
Wed 02 Sep 2020 10:35:16 PM UTC, comment #25: 

comment #23:

>
> comment #21:
> > This also seems to happen with the sparsersb included in Octave 6.0.90a.
> ...
>    why 1.0.7 ? Are you using 1.0.8 version of sparsersb?
> Version 1.0.7 is not meant to work with librsb-1.2.0.9.
> ...

Uh, I now understand you're using "the version that is there".

And you write "without the symbols" .. in the sense that the ones you provided in the stack trace are not to be trusted ?

dezperado <dezperado>
Wed 02 Sep 2020 10:34:00 PM UTC, comment #24: 

The sparser version in mxe is still the previous version (1.0.7), as is the  librsb (1.2.0.8)

But has the same error with the render

John Donoghue <lostbard>
Project Member
Wed 02 Sep 2020 10:24:40 PM UTC, comment #23: 

comment #21:

> This also seems to happen with the sparsersb included in Octave 6.0.90a.
>
> I'm attaching a backtrace from a crash that happened while running "pkg test sparsersb" and another one from the command in point 2) in comment #10.
> They are without symbols. But I hope, they are helpful anyway.
>
> (file #49730, file #49731)


Thanks Markus.
your stack trace is useful! But a bit strange:

1) In both logs the sparsersb's path seems to be
   "C:\Program Files\GNU Octave\Octave-6.0.90\mingw64\lib\octave\packages\sparsersb-1.0.7\x86_64-w64-mingw32-api-v55\sparsersb.oct"
   why 1.0.7 ? Are you using 1.0.8 version of sparsersb?
Version 1.0.7 is not meant to work with librsb-1.2.0.9.

2) In sparsersb_bt_pkg_test.log
 I see stack in the trace:
 sparsersb!rsb.do_util_merge_sorted_subarrays_in_place ()
 sparsersb!rsb__do_get_pixmap_RGB_from_matrix ()
 sparsersb!rsb__do_get_pixmap_RGB_from_matrix ()
 sparsersb!rsb.do_mtx_render ()

and that is very strange:rsb__do_get_pixmap_RGB_from_matrix shall not be there.
Indeed, sparsersb.cc calls rsb_mtx_rndr, which in turn calls  rsb__do_mtx_render.
But from there I've no idea why rsb__do_get_pixmap_RGB_from_matrix is there.. that function is being invoked by rsb_file_mtx_rndr, which sparsersb.cc does not invoke in any way.
Corrupt stack trace ?

3) In sparsersb_bt_render.log
 rsb.do_mtx_render seems to invoke rsb.destroy_coo_matrix_t
 This seems fine, in that rsb__do_mtx_render calls a static function which calls rsb__destroy_coo_matrix_t.

dezperado <dezperado>
Tue 01 Sep 2020 03:35:14 PM UTC, comment #22: 

I believe previous version of the packages didn't include the tests from the .cc files, which we now do which is where I saw it.

It happens in octave 5.2 as well - I hadnt checked versions before that.

John Donoghue <lostbard>
Project Member
Tue 01 Sep 2020 01:20:25 PM UTC, comment #21: 

This also seems to happen with the sparsersb included in Octave 6.0.90a.

I'm attaching a backtrace from a crash that happened while running "pkg test sparsersb" and another one from the command in point 2) in comment #10.
They are without symbols. But I hope, they are helpful anyway.

(file #49730, file #49731)

Markus Mützel <mmuetzel>
Project Member
Thu 27 Aug 2020 05:45:22 PM UTC, comment #20: 

To test I compiled with #warnings added to the if and else to see which was displayed.

So I guess its it using 64bit indexes because of the  OCTAVE_ENABLE_64 event if it didnt set the RSBOI_DETECTED_LONG_IDX

John Donoghue <lostbard>
Project Member
Thu 27 Aug 2020 04:18:41 PM UTC, comment #19: 

It appears to be using #define RSBOI_O64_R32 1

John Donoghue <lostbard>
Project Member
Thu 27 Aug 2020 03:45:29 PM UTC, comment #18: 

Ok so you definitely need 64 bit indices in octave.

One more check you can do now is to locate in sparsersb.cc the lines:

#if defined(USE_64_BIT_IDX_T) || defined(OCTAVE_ENABLE_64) || defined(RSBOI_DETECTED_LONG_IDX) /* 4.1.0+ / 4.0.3 / any */
#define RSBOI_O64_R32 1                                                                                                      
#else /* USE_64_BIT_IDX_T */
#define RSBOI_O64_R32 0
#endif /* USE_64_BIT_IDX_T */

and discover which branch of the two is being compiled (first one is right, second wrong).

dezperado <dezperado>
Thu 27 Aug 2020 03:30:29 PM UTC, comment #17: 

#  define OCTAVE_ENABLE_64 1
#  define OCTAVE_SIZEOF_IDX_TYPE 8

John Donoghue <lostbard>
Project Member
Thu 27 Aug 2020 03:13:42 PM UTC, comment #16: 

Yes; and what are their values in your case ?

dezperado <dezperado>
Thu 27 Aug 2020 03:10:56 PM UTC, comment #15: 

looking at octave includes, octave has the following defines

OCTAVE_SIZEOF_IDX_TYPE

and

OCTAVE_ENABLE_64

John Donoghue <lostbard>
Project Member
Thu 27 Aug 2020 02:29:41 PM UTC, comment #14: 

Ok it would normally be calling the native linux octave at that point that may or may not be compiled with the same settings as the cross compiled octave.

I'll try a couple of things

John Donoghue <lostbard>
Project Member
Thu 27 Aug 2020 12:53:49 PM UTC, comment #13: 

Thanks John.

  • It seems you are compiling without -DRSBOI_DETECTED_LONG_IDX=1. So sparsersb believes Octave is using 32 bit indices. Is this really the case ? If not, can you somehow force it (even changing sparsersb.cc ) ?
  • Please forget 'test sparsersbtg' --- that's not really meant for users; I was asking for 'test sparsersb' -- that what matters.
dezperado <dezperado>
Thu 27 Aug 2020 12:08:54 PM UTC, comment #12: 

In win64, after commenting out the 2 render tests:

  PASS                              998
  FAIL                                1

The fail was

>>>>> processing AppData\Local\Programs\GNU Octave\Octave-6.0.1_1\mingw64\share\octave\packages\sparsersb-1.0.8\sparsersbtg.m
***** test
assert( length( sparsersbtg () ) >= 57846 )
assert( length( sparsersbtg ([1,1,1,1,1,1]) ) >= 11218 )
assert( length( sparsersbtg ([1,1,1]) ) >= 11218 )
assert( length( sparsersbtg ([1]) ) == 0 )
!!!!! test failed
invalid empty index expression

The cross compiled package flags:

octave sparsersb package is configured with:
  SPARSERSB_LDFLAGS:     -L/home/jade/mxe-octave/build-64/usr/x86_64-w64-mingw32/lib -lrsb
  SPARSERSB_CXXFLAGS:    -I/home/jade/mxe-octave/build-64/usr/x86_64-w64-mingw32/include/
  SPARSERSB_CXX11:       -std=gnu++11
  OCTAVE:                echo
  MKOCTFILE:             /home/jade/mxe-octave/build-64/usr/bin/x86_64-w64-mingw32-mkoctfile --verbose -g

The compile command:

x86_64-w64-mingw32-g++ -c -I/home/jade/mxe-octave/build-64/usr/x86_64-w64-mingw32/include  -I/home/jade/mxe-octave/build-64/usr/x86_64-w64-mingw32/include/octave-6.0.1/octave/.. -I/home/jade/mxe-octave/build-64/usr/x86_64-w64-mingw32/include/octave-6.0.1/octave -I/home/jade/mxe-octave/build-64/usr/x86_64-w64-mingw32/include   -fopenmp -I/home/jade/mxe-octave/build-64/usr/x86_64-w64-mingw32/include/ -DHAVE_OCTAVE_VALUE_ISCOMPLEX -std=gnu++11 -g    -DRSB_SPARSERSB_LABEL=sparsersb sparsersb.cc -o /tmp/oct-hVqkQj.o

librsb cross compiled flags:

configure: =============== Build Programs and Flags ===============================
(you can override these at build time; e.g.: 'make CC=cc')
        CC                     : x86_64-w64-mingw32-gcc
        CFLAGS                 : -g -O2 -D__USE_MINGW_ANSI_STDIO=1 -fopenmp -std=c99
        NOUNROLLCFLAGS         : -fno-unroll-loops
        FC (to disable, FC='') : x86_64-w64-mingw32-gfortran
        FCFLAGS                : -g -O2 -fopenmp
        LD                     : /home/jade/mxe-octave/build-64/usr/bin/x86_64-w64-mingw32-ld
        LDFLAGS                : -L/home/jade/mxe-octave/build-64/usr/x86_64-w64-mingw32/lib
        LIBS                   :  -lm -lgfortran
        AR                     : x86_64-w64-mingw32-ar
        ARFLAGS                : cru
        M4                     : m4
        OCTAVE                 : octave
        DOXYGEN                : false
        HELP2MAN               : false
=== Additional flags affecting only the benchmark program (rsbench): ===
        RSB_RSBENCH_LIBS             :
        RSB_RSBENCH_CFLAGS           :
========= Main code generator values, this build vs defaults ===========
(if these differ from the defaults, you need to have M4 and run 'make cleanall' and 'make')
        All Numerical types          : "int,double,float,float complex,double complex"
        Numerical types              : "double,float,float complex,double complex" vs "double,float,float complex,double complex"
        Build Sparse BLAS Interface  : "no" vs "yes"
        Util. Kernels Unroll         : "16" vs "16"
        Triangular solve zero check  : "yes" vs "yes"
============== Build Configuration, this build vs defaults =============
(if you reconfigure and change these, you need to run 'make clean' and 'make')
        Supported I/O functionality level   : "7" vs "0"
        Interface Error Verbosity           : "0" vs "0"
        Internals Error Verbosity           : "0" vs "0"
        Memory hierarchy info, detected     : "L3:16/64/8192K,L2:8/64/256K,L1:8/64/32K"
        Memory hierarchy info, selected     : ""
        Maximum of Supported threads        : "64"
        Build Fortran examples              : "no"
        Build C examples                    : "no"
        Install Sparse BLAS Fortran modules : "no"
        Install pkg-config "librsb.pc" file : "no"
        Build Octave generated tester       : "no"
        Build Octave generated tester (int) : "no"
        Build HTML and man documentation    : "no"
        gzipped matrices support via zlib   : "no"
        gather elapsed time in librsb       : "no"

John Donoghue <lostbard>
Project Member
Thu 27 Aug 2020 07:52:37 AM UTC, comment #11: 

I've a correction wrt my previous post at point 0; there I meant:

"If you comment out all the 'render' tests from sparsersb.cc, do all the other 900 tests pass ?"

dezperado <dezperado>
Tue 25 Aug 2020 04:31:02 PM UTC, comment #10: 

I have the fix for the crash on [0] or empty matrices.
But not for [1]..

0) I am assuming "test sparsersb" succeeds giving

 PASSES 994 out of 994 tests

, right ?

1) Can you check whether you compiled sparsersb.cc with

 -DRSBOI_DETECTED_LONG_IDX=1

?

2) Can you obtain a stack trace of

  sparsersb(sparsersb([1]),"render", "crash.eps" ,1024)

crashing ?

dezperado <dezperado>
Tue 25 Aug 2020 03:38:13 PM UTC, comment #9: 

yes

John Donoghue <lostbard>
Project Member
Tue 25 Aug 2020 12:45:19 PM UTC, comment #8: 

I can replicate this crashing:

 sparsersb(sparsersb([0]),"render", "crash.eps" ,1024)

but I cannot replicate this crashing:

 sparsersb(sparsersb([1]),"render", "crash.eps" ,1024)

I guess both of the above lines crash your instance, right ?

dezperado <dezperado>
Tue 25 Aug 2020 12:08:25 PM UTC, comment #7: 

Yes that crashes.

Content of crash.mtx file:

%%MatrixMarket matrix coordinate real general
23 23 1
16        10        0.2840275319617540

John Donoghue <lostbard>
Project Member
Mon 24 Aug 2020 04:13:12 PM UTC, comment #6: 

Strange.. empty matrices are not to be expected here!

Do you experience any crash if you run the following ?

for i=10:1000;
 rrm=sparsersb(sprand(i,i,0.001)); # <- increasing matrix size
 if nnz(rrm) > 0
   sparsersb(rrm,"save","crash.mtx");
   sparsersb(rrm,"render", "sparsersb_temporary_render.eps" ,1024);
 end
end

dezperado <dezperado>
Mon 17 Aug 2020 05:04:22 PM UTC, comment #5: 

Installing 1.0.7 and 1.0.6 in octave 6 and octave 5.2 shows the same issue for me, so i guess it may not be something new in windows.

John Donoghue <lostbard>
Project Member
Mon 17 Aug 2020 12:04:47 PM UTC, comment #4: 

Anything with an I value < 23 produces an invalid crash file, that when loading:

>> rrm=sparsersb("crash.mtx");

Input has missing elements on the diagonal.

file content:

%%MatrixMarket matrix coordinate real symmetric
10 10 0

Starting at I=30 seems to consistently crash.

Using rsbench doesn't seem to ever crash, however the .sps file generated doesn't plot any data, whereas the octave call (when it doesn't crash does)

I attached the eps file generated using a 1000x1000 mtx file in rsbench as well as the crash.mtx file that was used.

(file #49683, file #49684)

John Donoghue <lostbard>
Project Member
Mon 17 Aug 2020 09:08:30 AM UTC, comment #3: 

1)
Sorry I made a typo and pasted wrong code;
what I intended originally in the loop was:

for i=10:1000;
 rrm=sparsersb(sprand(i,i,0.001)); # <- increasing matrix size
 sparsersb(rrm,"save","crash.mtx");
 # if next step crashes, we at least get crash.mtx
 sparsersb(rrm,"render", "sparsersb_temporary_render.eps" ,1024);
end

Running the above shall allow you to obtain the more or less 'smallest' crashing matrix in "crash.mtx".
With that it would be interesting to see if there is a matrix that leads to a 100% of crashes.

2) There is a chance the bug is totally related to librsb.
To debunk that, you may try once or repeated:
 rsbench  --plot -f crash.mtx > crash.eps # does it render or crash ?
You can first use librsb's A.mtx, then the crash.mtx from point 1).

3) Repeat either of 1) and 2) with threading off, by running:
 export OMP_NUM_THREADS=1
before the test.

4) Rebuild sparsersb.oct from sparsersb.cc by commenting the call to rsb_mtx_rndr(); then invoke it with "render" as in 1). If this crashes sparsersb, tne rendering function can be declared innocent.

dezperado <dezperado>
Sun 16 Aug 2020 11:38:49 PM UTC, comment #2: 

It may be a windows only issue?

I ran the loop at it crashed.

On loading the matrix and doing the render worked ok, but repeating it a couple of times with the same file caused it to intermittently crash.

So its possibly something in the render not the matrix itself?

Even doing something to generate the matrix once only but render multiple times with cause the crash:

rrm=sparsersb(sprand(1000,1000,0.001));
for i=10:1000;
sparsersb(rrm,"render", "sparsersb_temporary_render.eps" ,1024); end

When it crashes the rendered .eps file as a size of 0.

John Donoghue <lostbard>
Project Member
Sat 15 Aug 2020 11:18:42 PM UTC, comment #1: 

Thanks for the double problem report!

With respect to the crash, can you please

1) run a loop like:

for i=10:1000;
 rrm=sparsersb(sprand(1000,1000,0.001));
 sparsersb(rrm,"save","crash.mtx");
 sparsersb(rrm,"render", "sparsersb_temporary_render.eps" ,1024); end

so to save the matrix before triggering a crash and

2) after the crash, restart octave and

 rrm=sparsersb("crash.mtx") # load the matrix
 sparsersb(rrm,"render", "sparsersb_temporary_render.eps" ,1024);

to check if with that same matrix it crashes again ?

3) If you are able to find such a "crash-inducing" matrix, can you attach it in this forum ?

dezperado <dezperado>
Fri 14 Aug 2020 06:32:59 PM UTC, original submission:  

Using the latest sparsersb 1.0.8

Attempting to install in Windows 64 when octave was installed to a path that has a space in it fails.

Looking at the error, the Makefile is setting environment varaiable CXXFLAGS to specify the include paths rather than passing directly to mkoctfile and so msys is expanding them to full windows names.

Changing the makefile (diff) make it work for me:

-       LFLAGS="$(LDFLAGS)" LDFLAGS="$(LDFLAGS)" CXXFLAGS="$(CXXFLAGS) $(CXXFLAGS_CXX11)" $(MKOCTFILE) -D'RSB_SPARSERSB_LABEL=sparsersb' -o $@ $<
+       $(MKOCTFILE) $(LDFLAGS) $(CXXFLAGS) $(CXXFLAGS_CXX11) -D'RSB_SPARSERSB_LABEL=sparsersb' -o $@ $<

For the crash, running some of the tested that are embedded in sparsersb.cc will do it:

rrm=sparsersb(sprand(1000,1000,0.001));
sparsersb(rrm,"render", "sparsersb_temporary_render.eps" ,1024);

It doesn't happen 100% of the time - more like 80% ?

Crash seen in both octave 5.2.0 and 6.0.1

John Donoghue <lostbard>
Project Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #49851:  sparsersb.cc added by dezperado (213KiB - text/x-c++src)
file #49848:  sparsersb.cc added by dezperado (214KiB - text/x-c++src)
file #49838:  crash.eps added by mmuetzel (2KiB - application/postscript)
file #49834:  rsb_mtx_rndr.c added by dezperado (2KiB - text/x-csrc)
file #49830:  librsb added by mmuetzel (216KiB - application/octet-stream)
file #49787:  sparsersb_bt_pkg_test_with_symbols.log added by mmuetzel (36KiB - application/octet-stream)
file #49788:  sparsersb_bt_render_with_symbols.log added by mmuetzel (6KiB - application/octet-stream)
file #49730:  sparsersb_bt_pkg_test.log added by mmuetzel (22KiB - application/octet-stream)
file #49731:  sparsersb_bt_render.log added by mmuetzel (5KiB - application/octet-stream)
file #49683:  t.eps added by lostbard (686B - application/postscript)
file #49684:  crash.mtx added by lostbard (28KiB - 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 (Updated the item)
  • -email is unavailable- added by dezperado (Posted a comment)
  • -email is unavailable- added by lostbard (Submitted the item)
  • -email is unavailable- added by lostbard (Adding package maintainer)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-09-23 dezperado Attached File- => Added sparsersb.cc, #49851
    2020-09-23 dezperado Attached File- => Added sparsersb.cc, #49848
    2020-09-22 mmuetzel Attached File- => Added crash.eps, #49838
    2020-09-21 dezperado Attached File- => Added rsb_mtx_rndr.c, #49834
    2020-09-21 mmuetzel Attached File- => Added librsb, #49830
    2020-09-11 mmuetzel Attached File- => Added sparsersb_bt_pkg_test_with_symbols.log, #49787
        Attached File- => Added sparsersb_bt_render_with_symbols.log, #49788
    2020-09-01 mmuetzel Attached File- => Added sparsersb_bt_pkg_test.log, #49730
        Attached File- => Added sparsersb_bt_render.log, #49731
    2020-08-17 lostbard Attached File- => Added t.eps, #49683
        Attached File- => Added crash.mtx, #49684
    2020-08-14 lostbard Carbon-Copy- => Added michelemartone@users.sourceforge.net

    Back to the top


    Powered by Savane 3.5