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

[Markus Mützel]

Follow-up Comment #66, bug #58957 (project octave):

I locally removed the change from comment #61 and added the sed command from
comment #64 (see attachment). I also reverted the local change we made to the
build rule for librsb and recompiled Octave 6 for Windows.

With that change, `pkg test sparsersb` no longer crashes Octave.

So I believe, we can use that as a (temporary) fix.

However, there is lots of output in the command window during the test. The
output wasn't captured in the diary (and it is a pain to copy many lines of
text from the command window on Windows). So, to show just a small portion:

  ..s\sparsersb-1.0.8\x86_64-w64-mingw32-api-v55\sparsersb.cc-tst Will
autotune matrix: 100 x 100, type D, 4000 nnz, 40 nnz/r, 21 subms, 16 lsubms,
2.4160 bpnz.
10 iterations (4 th.) took 0.001013s; avg 0.0001013s ( +/-  99.98/900.00 %);
best 1.525e-08s; worst 0.001013s; std dev. 0.0003039 (taking best).
Reference operation time is 1.52477e-08 s (5.247e+05 Mflops) with 4 threads.
Starting merge (same threads) based auto-tuning procedure (transA=N, nrhs=1)
(max 6 steps, inclusive 3 grace steps) on: 100 x 100, type D, 4000 nnz, 40
nnz/r, 21 subms, 16 lsubms, 2.4160 bpnz (tpop: 1.525e-08  Mflops: 0.000)
Merge (16 -> 10 leaves) took w.c.t. of 0.001001s, ~0s of computing time (of
which 0s sorting, 0s analysis)
10 iterations (4 th.) took 0.002015s; avg 0.0002015s ( +/-  99.99/402.72 %);
best 1.524e-08s; worst 0.001013s; std dev. 0.000403 (taking best).
Reference operation time is 1.52431e-08 s (5.248e+05 Mflops) with 4 threads.
After merge step 1: tpop: 1.524e-08 s   ~Mflops: 0.000   nsubm:10 otn:4
Applying merge (16 -> 10 leaves, 4 th.) yielded NEGLIGIBLE change (1th in a
row) (old/new=1.00030x): 1.525e-08s -> 1.524e-08s, so IGNORING this instance.
Merge (10 -> 7 leaves) took w.c.t. of 0s, ~0s of computing time (of which 0s
sorting, 0s analysis)
10 iterations (4 th.) took 0.000999s; avg 9.99e-05s ( +/-  99.98/900.00 %);
best 1.526e-08s; worst 0.000999s; std dev. 0.0002997 (taking best).
Reference operation time is 1.52622e-08 s (5.242e+05 Mflops) with 4 threads.
After merge step 2: tpop: 1.526e-08 s   ~Mflops: 0.000   nsubm:7 otn:4
Applying merge (10 -> 7 leaves, 4 th.) yielded NEGLIGIBLE change (2th in a
row) (old/new=0.99905x): 1.525e-08s -> 1.526e-08s, so IGNORING this instance.
Merge (7 -> 4 leaves) took w.c.t. of 0s, ~0s of computing time (of which 0s
sorting, 0s analysis)
10 iterations (4 th.) took 0.00101s; avg 0.000101s ( +/-  99.98/900.00 %);
best 1.904e-08s; worst 0.00101s; std dev. 0.0003031 (taking best).
Reference operation time is 1.9043e-08 s (4.201e+05 Mflops) with 4 threads.
After merge step 3: tpop: 1.904e-08 s   ~Mflops: 0.000   nsubm:4 otn:4
Applying merge (7 -> 4 leaves, 4 th.) yielded SLOWDOWN (1th of 3 tolerable) of
 1.249x: 1.525e-08s -> 1.904e-08s.
Merge (4 -> 1 leaves) took w.c.t. of 0s, ~0s of computing time (of which 0s
sorting, 0s analysis)
10 iterations (4 th.) took 0s; avg 0s ( +/-   -inf/   nan %); best 1.908e-08s;
worst 0s; std dev. 0 (taking best).
Reference operation time is 1.90848e-08 s (4.192e+05 Mflops) with 4 threads.
After merge step 4: tpop: 1.908e-08 s   ~Mflops: 0.000   nsubm:1 otn:4
Applying merge (4 -> 1 leaves, 4 th.) yielded SLOWDOWN (2th of 3 tolerable) of
 1.252x: 1.525e-08s -> 1.908e-08s.
Merged all the matrix leaves: no reason to continue merging.
A total of 4 merge steps (of max 6) (16 -> 1 subms) took 0.105s (of which
0.017s partitioning, 0s I/O); computing times: 0s in par. loops, 0s sorting,
0s analyzing)
Total merge + benchmarking process took 0.105s, equivalent to
6886154.6/6886154.6 new/old ops (0.001005s for 1 clones -- as 65907.4/65907.4
ops, or 65907.4/65907.4 ops per clone), SPEEDUP of  1.000x (NO SPEEDUP)
Merging based autotuning FAILED (=NO SPEEDUP); let's try splitting then...


Is this to be expected?
If it isn't we should probably follow up on a new bug report.

Additionally, there is one failing BIST:

>>>>> processing
D:\SVN\Octave\test\octave-2020-11-02-10-17-w64_librsb\octave-2020-11-02-10-17-w64\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


To reproduce:

>> length( sparsersbtg () )
error: invalid empty index expression
error: called from
    sparsersbtg at line 96 column 8


Should I open a separate report for this, too?

(file #50189)
    _______________________________________________________

Additional Item Attachment:

File name: bug58957_librsb_double_free.patch Size:2 KB
   
<https://file.savannah.gnu.org/file/bug58957_librsb_double_free.patch?file_id=50189>



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58957>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/