bugGNU Octave - Bugs: bug #63415, Error in fwrite() or rand() or...

 
 

bug #63415: Error in fwrite() or rand() or randn(), I'm not sure

Submitter:  José Luis García Pallero <jgpallero>
Submitted:  Fri 25 Nov 2022 09:18:24 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  José Luis García Pallero Open/Closed:  * Closed
Release:  * stable Operating System:  * Any
Fixed Release:  8.2.0 Planned Release:  8.2.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 31 Mar 2023 10:14:21 AM UTC, comment #37: 

No complaints in a week. Closing as fixed. This will show up in 8.2.0 when it's released soon.

Arun Giridhar <arungiridhar>
Group Member
Fri 24 Mar 2023 08:11:54 PM UTC, comment #36: 

I pushed this change to https://hg.savannah.gnu.org/hgweb/octave/rev/fcd97a68e5f7.

Marking as ready for test. Please stress-test this fix.

Arun Giridhar <arungiridhar>
Group Member
Fri 24 Mar 2023 01:55:51 PM UTC, comment #35: 

I have a patch for this. Please test this:

diff -r c735cce18c7a libinterp/corefcn/oct-stream.h
--- a/libinterp/corefcn/oct-stream.h    Thu Mar 23 16:22:59 2023 -0400
+++ b/libinterp/corefcn/oct-stream.h    Fri Mar 24 09:34:34 2023 -0400
@@ -119,7 +119,7 @@ public:

   std::ostream * preferred_output_stream ()
   {
-    if (! m_encoding.compare ("utf-8"))
+    if (! m_encoding.compare ("utf-8") || (m_mode & std::ios::binary))
       return output_stream ();

     if (m_conv_ostream)


Explanation: The previous code was skipping conversion to/from UTF-8 when the encoding was already UTF-8. The patched code adds another criterion to skip conversion: the stream was opened in binary mode.

Unpatched:

octave:1> cd /tmp/
octave:2> __mfile_encoding__ ("latin1")
octave:3> __mfile_encoding__
ans = latin1
octave:4> fwritetest

error: assert (stat ("m_rand.bin").size == numel (matB) * sizeof (double (1))) failed
error: called from
    assert at line 107 column 11
    fwritetest at line 21 column 1
octave:5> ver
----------------------------------------------------------------------
GNU Octave Version: 9.0.0 (hg id: c735cce18c7a)


Patched:

octave:1> cd /tmp/
octave:2> __mfile_encoding__ ("latin1")
octave:3> __mfile_encoding__
ans = latin1
octave:4> fwritetest

Variables visible from the current scope:

variables in scope: top scope

  Attr   Name        Size                     Bytes  Class
  ====   ====        ====                     =====  =====
         matA      100x150                   120000  double
         matB      100x150                   120000  double
         matC    15000x1                     120000  double
         matD    15000x1                     120000  double
         n           1x1                          8  double

Total is 60001 elements using 480008 bytes

Elapsed time is 0.00793386 seconds.
octave:5> ver
----------------------------------------------------------------------
GNU Octave Version: 9.0.0 (hg id: c735cce18c7a+)


Arun Giridhar <arungiridhar>
Group Member
Mon 20 Mar 2023 09:58:15 PM UTC, comment #34: 

So a workaround is to set your encoding to "utf-8", convert all your m-files to "utf-8" as well. On linux one can do e.g.:



iconv -f iso-8859-1 -t utf-8 inputfile.m -o outputf.m


I think "iconv" is included in Windows installation, but there are should be other options. Replace "iso-8859-1" with whatever encoding you were using.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 20 Mar 2023 09:49:38 PM UTC, comment #33: 

This bug report is spread over 3 different bugs. Most of the discussion is there:
https://savannah.gnu.org/bugs/?63931

Short summary:

Some time during 7.1 -> 8.0 transition m-file encoding in octave was changed. One of the changes was that changing encoding in
gui editor would also change encoding in the gui command window.
You can reproduce the bug in cli version if you run manually

__mfile_encoding__("latin1")


(you can replace "latin1 with pretty much anything else except "utf-8")
Also, if you set in gui encoding to "utf-8" the bug will disappear.

Dmitri.
--







Dmitri A. Sergatskov <dasergatskov>
Mon 20 Mar 2023 09:34:24 PM UTC, comment #32: 

Why in Octave versions previous to 8 the error is not present? And why it only is present in GUI version?

José Luis García Pallero <jgpallero>
Mon 20 Mar 2023 09:24:49 PM UTC, comment #31: 


> checking on octave 8.1.0, though, i get the same result. no filesize difference.


Now do:


 __mfile_encoding__("latin1")


Essentially when octave is forced to do conversion, it does it wrong. Char < 128 are written correctly, after that they become
char(63). And once they become > 193 (so that 193+63 > 255)
they become null and breaks writing.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 20 Mar 2023 09:17:37 PM UTC, comment #30: 

adding a pause after each fwrite command, with matlab filesize on m_eye.bin and m_rand.bin are 120,000 bytes each time. checking on octave 8.1.0, though, i get the same result. no filesize difference.

Nicholas Jankowski <nrjank>
Group Member
Mon 20 Mar 2023 08:38:36 PM UTC, comment #29: 

@nrjank: That's OK, the two bug reports are caused by the same problem as Dmitri found out a couple days ago. That one is fwrite writes the wrong value. This one is fwrite writes the wrong number of values. Almost certainly that's because some characters are being converted into invalid utf-8 entries and then not written. I'm tracking both.

What happens in Matlab if you remove the lines with stat, like this?

clear all

fid = fopen ("m_eye.bin", "wb", "ieee-le");
matA = eye (100,150);
n = fwrite (fid, matA, "double");
fclose(fid);

fid = fopen ("m_rand.bin", "wb", "ieee-le");
matB = rand (100,150);
n = fwrite (fid, matB, "double");
fclose(fid);

fid = fopen ("m_eye.bin", "rb");
matC = fread (fid, inf, "double");
fclose(fid);

fid = fopen ("m_rand.bin", "rb");
matD = fread (fid, inf, "double");
fclose(fid);

assert (all (matC == matA(:)))
assert (all (matD == matB(:)))

clear ans fid
whos


Can you see the file sizes being different in Windows explorer or the cmd.exe shell?

Arun Giridhar <arungiridhar>
Group Member
Mon 20 Mar 2023 07:29:05 PM UTC, comment #28: 

(sorry ignore comment #27. wrong bug report)

Nicholas Jankowski <nrjank>
Group Member
Mon 20 Mar 2023 07:28:12 PM UTC, comment #27: 

Unrecognized function or variable 'stat'

Nicholas Jankowski <nrjank>
Group Member
Thu 16 Mar 2023 05:38:39 PM UTC, comment #26: 

I've realized also that sometimes, when I start the GUI it does not open the program, but if I inspect the running programs via ps -U user there are both instances to octave and octave-gui processes and I need to kill octave-gui manually. The problem is that this occurs randomly... (I'm running Debian and Octave compiled from myself, in this case using the tar.gz for 8.1.0)

José Luis García Pallero <jgpallero>
Thu 16 Mar 2023 12:37:14 AM UTC, comment #25: 

Changing status to confirmed.

Can you find a way to trigger the assert failure without calling rand? It would be nice if we can localize it to 100% deterministic code.

Arun Giridhar <arungiridhar>
Group Member
Thu 16 Mar 2023 12:30:26 AM UTC, comment #24: 

It looks like it has nothing to do with thread sanitizer, besides the fact it makes it run slow. I see the problem on debug compile as well ("-O0 -ggdb3"):


error: assert (stat ("m_rand.bin").size == numel (matB) * 8) failed
error: called from
    assert at line 107 column 11
error: assert (all (matC == matA (:))) failed
error: called from
    assert at line 107 column 11
error: mx_el_eq: nonconformant arguments (op1 is 14400x1, op2 is 15000x1)
Variables visible from the current scope:

variables in scope: top scope

  Attr   Name        Size                     Bytes  Class
  ====   ====        ====                     =====  =====
         matA      100x150                      800  double
         matB      100x150                   120000  double
         matC    15000x1                     120000  double
         matD    14400x1                     115200  double
         n           1x1                          8  double

Total is 59401 elements using 356008 bytes


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 16 Mar 2023 12:22:02 AM UTC, comment #23: 

I see the test failing on octave 9.0.0 (hg id: 16b233ccaeab)
when compiled with

../configure --disable-docs --disable-java CFLAGS="-ggdb3 -O0 -fsanitize=thread" CXXFLAGS="-ggdb3 -O0 -fsanitize=thread" FFLAGS="-ggdb3 -O0 -fsanitize=thread"


Start octave as:


TSAN_OPTIONS="ignore_noninstrumented_modules=1" ./run-octave --gui



GNU Octave, version 9.0.0
Copyright (C) 1993-2023 The Octave Project Developers.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-pc-linux-gnu".

Home page:            https://octave.org
Support resources:    https://octave.org/support
Improve Octave:       https://octave.org/get-involved

For changes from previous versions, type 'news'.

==================
WARNING: ThreadSanitizer: data race (pid=222630)
  Write of size 8 at 0x7fd05a031598 by thread T7:
    #0 SelfListener::recvData(char const*, int) libgui/qterminal/libqterminal/unix/moc-SelfListener.cc:137 (liboctgui.so.9+0x14661e)
    #1 SelfListener::run() ../libgui/qterminal/libqterminal/unix/SelfListener.cpp:32 (liboctgui.so.9+0x121193)
    #2 QThreadPrivate::start(void*) <null> (libQt5Core.so.5+0xe9bf8)

  Previous read of size 8 at 0x7fd05a031598 by main thread:
    [failed to restore the stack]

  As if synchronized via sleep:
    #0 nanosleep <null> (libtsan.so.0+0x67afc)
    #1 qt_nanosleep(timespec) <null> (libQt5Core.so.5+0x2f8334)
    #2 QThreadPrivate::start(void*) <null> (libQt5Core.so.5+0xe9bf8)

  Location is stack of thread T7.

  Thread T7 'SelfListener' (tid=222653, running) created by main thread at:
    #0 pthread_create <null> (libtsan.so.0+0x61748)
    #1 QThread::start(QThread::Priority) <null> (libQt5Core.so.5+0xe969e)
    #2 QUnixTerminalImpl::initialize() ../libgui/qterminal/libqterminal/unix/QUnixTerminalImpl.cpp:80 (liboctgui.so.9+0x105c3b)
    #3 QUnixTerminalImpl::QUnixTerminalImpl(QWidget*) ../libgui/qterminal/libqterminal/unix/QUnixTerminalImpl.cpp:30 (liboctgui.so.9+0x1055fb)
    #4 QTerminal::create(QWidget*) ../libgui/qterminal/libqterminal/QTerminal.cc:59 (liboctgui.so.9+0x1388c4)
    #5 octave::terminal_dock_widget::terminal_dock_widget(QWidget*, bool) ../libgui/src/terminal-dock-widget.cc:85 (liboctgui.so.9+0x347a20)
    #6 octave::base_qobject::terminal_widget(octave::main_window*) ../libgui/src/octave-qobject.cc:459 (liboctgui.so.9+0x2df5a8)
    #7 octave::main_window::adopt_terminal_widget() ../libgui/src/main-window.cc:218 (liboctgui.so.9+0x2a5e07)
    #8 octave::main_window::adopt_dock_widgets() ../libgui/src/main-window.cc:205 (liboctgui.so.9+0x2a5d10)
    #9 octave::main_window::main_window(octave::base_qobject&) ../libgui/src/main-window.cc:159(liboctgui.so.9+0x2a557c)
    #10 octave::base_qobject::base_qobject(octave::qt_application&, bool) ../libgui/src/octave-qobject.cc:285 (liboctgui.so.9+0x2de3b3)
    #11 octave::qt_application::execute() ../libgui/src/qt-application.cc:100 (liboctgui.so.9+0x2fbd2b)
    #12 main ../src/main-gui.cc:150 (lt-octave-gui+0x403815)

SUMMARY: ThreadSanitizer: data race libgui/qterminal/libqterminal/unix/moc-SelfListener.cc:137 in SelfListener::recvData(char const*, int)
==================
>> clear all

fid = fopen ("m_eye.bin", "wb", "ieee-le");
matA = eye (100,150);
n = fwrite (fid, matA, "double");
fclose(fid);

assert (stat ("m_eye.bin").size == numel(matA) * 8)

fid = fopen ("m_rand.bin", "wb", "ieee-le");
matB = rand (100,150);
n = fwrite (fid, matB, "double");
fclose(fid);

assert (stat ("m_rand.bin").size == numel(matB) * 8)

fid = fopen ("m_eye.bin", "rb");
matC = fread (fid, inf, "double");
fclose(fid);

fid = fopen ("m_rand.bin", "rb");
matD = fread (fid, inf, "double");
fclose(fid);

assert (all (matC == matA(:)))
assert (all (matD == matB(:)))

clear ans fid
whos
error: assert (stat ("m_rand.bin").size == numel (matB) * 8) failed
error: called from
    assert at line 107 column 11
error: assert (all (matC == matA (:))) failed
error: called from
    assert at line 107 column 11
error: mx_el_eq: nonconformant arguments (op1 is 14404x1, op2 is 15000x1)
Variables visible from the current scope:

variables in scope: top scope

  Attr   Name        Size                     Bytes  Class
  ====   ====        ====                     =====  =====
         matA      100x150                      800  double
         matB      100x150                   120000  double
         matC    15000x1                     120000  double
         matD    14404x1                     115232  double
         n           1x1                          8  double

Total is 59405 elements using 356040 bytes

>>


I tried a fe times and 100% failure in GUI mode and 100% OK in cli mode.

gcc version 11.3.1 20221121 (Red Hat 11.3.1-4) (GCC)

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 16 Mar 2023 12:02:43 AM UTC, comment #22: 


> 8.1.0 CLI seems to works also.


This suggests it might be a threading issue.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 15 Mar 2023 11:47:17 PM UTC, comment #21: 
Arun Giridhar <arungiridhar>
Group Member
Wed 15 Mar 2023 04:31:49 AM UTC, comment #20: 

I can confirm the asserts for octave-8.1.0-w64.zip using the GUI.
For the example below, fwrite leads always to an m_eye.bin with 119950 Bytes instead of 120000.

7.2.0 works and 8.1.0 CLI seems to works also.

Michael Reiter <mreiter82__>
Sat 10 Dec 2022 09:00:54 PM UTC, comment #19: 

Thanks for the test, Sébastien. I've compiled again the stable branch and I have the error again only in GUI mode (CLI mode works OK). I can't understand where the problem is in my installation, and why Octave 7.3.0 works, but not stable nor 9.0.0. Attached I send my ./configure output

(file #54080)

José Luis García Pallero <jgpallero>
Sat 10 Dec 2022 03:00:19 PM UTC, comment #18: 


commentaire #9 :

> I'm also copying Sébastien Villemot, the Octave maintainer on Debian. @svillemot: could you run the test from comment #2 on Debian Sid and see if the assertions pass please?


I compiled Octave 8.0.1 (hg id: ccbf38427774) by hand on Debian unstable/sid, on an amd64 machine, and ran the test from comment #2. All the assertions pass.

Also note that I plan to upload Octave 8 to Debian experimental as soon as there is a release candidate available.

Sébastien Villemot <svillemot>
Sun 27 Nov 2022 02:00:13 PM UTC, comment #17: 

Yes, if this bug is to be reproduced, doing so on Debian Sid would be the most promising route. Once the release candidate is made for Octave 8.1, it will be tested in various distros including Debian and that should hopefully trap the error, whether it's in Octave or an external library.

The "official" Octave on the Debian Sid is still 7.3 as of now. https://packages.debian.org/sid/octave

Arun Giridhar <arungiridhar>
Group Member
Sun 27 Nov 2022 12:37:31 PM UTC, comment #16: 

I have tried on 2 computers (Ryzen 3950 and i-9880h) with Fedora 37
(gcc version 12.2.1 20221121 (Red Hat 12.2.1-4)) and on 2
computers (CoreDuo T9900 and RaspberryPI4 (aarm64))
with Ubuntu 22.10 (gcc 12.2.0-3). I cannot reproduce neither
fwrite() nor gui-not-starting problem. Tried both 8.0.1 and 9.

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Sun 27 Nov 2022 10:43:15 AM UTC, comment #15: 

New compilation test:


All configured as ./configure --prefix=/opt/octave/ CFLAGS=-O3 FFLAGS=-O3 CXXFLAGS=-O3. The only difference between the configure results are:

  • In Octave 7.3.0 the PCRE libraries value is -lpcre, while in stable and default PCRE libraries value is -lpcre2-8. Inspecting my Debian installation I can see that libpcre.so is part of libpcre3-dev package, but libpcre2-8.so is part of libpcre2-dev. libpcre3 is a dependency for LibreOffice, Okular and other related libraries. libpcre2 is a dependency for lots of packeges
  • In Octave 7.3.0 there is the configuration TERM libraries: -lncurses, but this not appears in stable nor default


Attached I send the three configuration results

The results related with the use of fwrite are the same as I posted in past messages:

  • Using Octave in CLI mode all works fine with 7.3.0, stable and default
  • Using Octave in GUI mode only 7.3.0 version works


I've reconfigured the stable branch with --without-pcre2 in order to force the use of -lpcre, and then recompiled the 8.0.1, but the error with fwrite is still present.

My GCC version in Debian Sid is 4:12.2.0-1 (Debian repository nomenclature)


(file #54026, file #54027, file #54028)

José Luis García Pallero <jgpallero>
Sat 26 Nov 2022 06:44:16 PM UTC, comment #14: 

I confirm that the error is also present compiling the 8.0.1 sources with -O2. Also the call with the argument --gui produces sometimes, not always, a stand by and no launching

José Luis García Pallero <jgpallero>
Sat 26 Nov 2022 04:45:58 PM UTC, comment #13: 


comentario nº11:

> Recompile with "-O2". "-O3" will not give you anything but trouble.
>


But up to now -O3 always worked fine. Compilation of Octave 7.3.0 does not show the problem. Anyway, I'll compile 8.0.1 with -O2

José Luis García Pallero <jgpallero>
Sat 26 Nov 2022 04:42:34 PM UTC, comment #12: 

@jgpallero: Never mind then. Since I am not on Debian myself, I'm trying to see if anyone on Debian Unstable (Sid) can replicate it. If so, then the Debian CI and packaging process will be able to give more clarity.

Arun Giridhar <arungiridhar>
Group Member
Sat 26 Nov 2022 04:38:02 PM UTC, comment #11: 

Recompile with "-O2". "-O3" will not give you anything but trouble.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 26 Nov 2022 03:20:22 PM UTC, comment #10: 


comentario nº9:

> @jgpallero: Is it feasible for you to test on a different Debian machine, one running Testing or Stable but not Sid?
>


No, it's impossible for me. Other alternative could be I upload my compilation to some place as google Drive or Dropbox and then you can run it on your machine. The folder has a size of 275 MB compressed in tar.gz. But I'm not sure if you could run it due to dynamic linking and possible differente libarry names in Debian and other Linux distros. Is it possible to compile Octave as static linking? In this case I could upload the final binary in order you can check it

José Luis García Pallero <jgpallero>
Sat 26 Nov 2022 02:14:39 PM UTC, comment #9: 

@jgpallero: Is it feasible for you to test on a different Debian machine, one running Testing or Stable but not Sid?

I'm also copying Sébastien Villemot, the Octave maintainer on Debian. @svillemot: could you run the test from comment #2 on Debian Sid and see if the assertions pass please?

Arun Giridhar <arungiridhar>
Group Member
Fri 25 Nov 2022 06:27:00 PM UTC, comment #8: 


comentario nº7:

> Your hg id has a + at the end indicating that you made local changes to it after downloading. Yes, I agree with testing with a fresh install.


Yes, it corresponds to my changes in the es_ES ts file for localization.

I've compiled the changeset

>> ver
GNU Octave Version: 8.0.1 (hg id: fd8c0df759bb)

but the problem is still present. I can't understand it. Attached I send the final output of my ./configure. I'm running Debian Sid with GCC 12.2.0-9 from the official repositories

(file #54018)

José Luis García Pallero <jgpallero>
Fri 25 Nov 2022 04:02:03 PM UTC, comment #7: 

Your hg id has a + at the end indicating that you made local changes to it after downloading. Yes, I agree with testing with a fresh install.

Arun Giridhar <arungiridhar>
Group Member
Fri 25 Nov 2022 03:51:22 PM UTC, comment #6: 

In my case, ver command output is

GNU Octave Version: 8.0.1 (hg id: 76140113e6cc+)


About your suggestion on writing first the random numbers and then the eye matrix, but the result is the same:

error: assert (stat ("m_rand.bin").size == numel (matB) * 8) failed
error: called from
    assert at line 107 column 11
    prueba_fwrite at line 8 column 1

Using fflush() before fclose() does not solve the problem.

I've cloned again, hg clone https://hg.octave.org/octave -r stable, run ./bootstrap, and ./configure --prefix=/opt/octave/ CFLAGS=-O3 FFLAGS=-O3 CXXFLAGS=-O3. I'll write the new results

José Luis García Pallero <jgpallero>
Fri 25 Nov 2022 02:15:01 PM UTC, comment #5: 

@jgpallero: If you write the random numbers first and the eye() matrix later, do you see the same problem with rand, or does it go to the second file now? Also, does calling fflush() before closing the file make any difference?

Arun Giridhar <arungiridhar>
Group Member
Fri 25 Nov 2022 01:54:23 PM UTC, comment #4: 

Sorry, I am still unable to replicate the file mismatch.

If you type "ver" in Octave it should give you the hg id next to the Octave version:

>> ver
----------------------------------------------------------------------
GNU Octave Version: 8.0.1 (hg id: fa254b08f949)


I am now using your compilation settings, except for the installation prefix. My gcc version is 12.2.0.

Octave is now configured for x86_64-pc-linux-gnu

  Source directory:              ..
  Installation prefix:           /usr/local
  C compiler:                    gcc  -pthread -fopenmp  -Wall -W -Wshadow -Wformat -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wcast-align -Wcast-qual -O3
  C++ compiler:                  g++  -pthread -fopenmp  -Wall -W -Wshadow -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -O3
  Fortran compiler:              gfortran -O3 -std=legacy
  CPPFLAGS:
  Fortran libraries:             -L/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0 -L/usr/lib -L/lib -lgfortran -lm -lquadmath
  Lex libraries:
  LIBS:                          -lpthread -lm
  LDFLAGS:
  Extra LDFLAGS:


Running "./run-octave --gui" does not cause the problem for me. Installing it and running plain "octave" does not do it either.

Does anyone have an idea what might cause binary mode file writing to stop part-way through?

Regarding the not-starting part: it's only affected some users on Windows before, but does it make a difference if you delete your GUI ini file so that Octave can recreate it? On my system it is located at

$HOME/.config/octave/octave-gui.ini


Arun Giridhar <arungiridhar>
Group Member
Fri 25 Nov 2022 01:17:41 PM UTC, comment #3: 

I'm running Debian Sid and I always configure Octave in the compilation as ./configure --prefix=/opt/octave/ CFLAGS=-O3 FFLAGS=-O3 CXXFLAGS=-O3

I ran your test and it works with version 8.0.1, BUT only in CLI mode:

Variables visible from the current scope:

variables in scope: top scope

  Attr   Name        Size                     Bytes  Class
  ====   ====        ====                     =====  =====
         matA      100x150                      800  double
         matB      100x150                   120000  double
         matC    15000x1                     120000  double
         matD    15000x1                     120000  double
         n           1x1                          8  double

Total is 60001 elements using 360808 bytes


If I execute the script from the GUI I obtain

error: assert (stat ("m_rand.bin").size == numel (matB) * 8) failed
error: called from
    assert at line 107 column 11
    prueba_fwrite at line 15 column 1

Also, I'm having problems starting octave --gui with 8.0.1. Sometimes the program does not launch, but no error is emitted in the command line, it only maintains waiting. If I execute ps -U user I obtain, related with Octave,

107657 pts/10   00:00:00 octave
107658 ?        00:00:04 octave-gui


I don't know which hg id I cloned exactly (I deleted the folder after compilation), but I did it after the call for translators message were posted.

With Octave 7.3.0 all works fine in both CLI and GUI modes

José Luis García Pallero <jgpallero>
Fri 25 Nov 2022 12:24:07 PM UTC, comment #2: 

Works for me with both default and stable:

GNU Octave Version: 8.0.1 (hg id: fa254b08f949)
GNU Octave Version: 9.0.0 (hg id: ce5b4a00b022)


I expanded your test like this.

clear all

fid = fopen ("m_eye.bin", "wb", "ieee-le");
matA = eye (100,150);
n = fwrite (fid, matA, "double");
fclose(fid);

assert (stat ("m_eye.bin").size == numel(matA) * 8)

fid = fopen ("m_rand.bin", "wb", "ieee-le");
matB = rand (100,150);
n = fwrite (fid, matB, "double");
fclose(fid);

assert (stat ("m_rand.bin").size == numel(matB) * 8)

fid = fopen ("m_eye.bin", "rb");
matC = fread (fid, inf, "double");
fclose(fid);

fid = fopen ("m_rand.bin", "rb");
matD = fread (fid, inf, "double");
fclose(fid);

assert (all (matC == matA(:)))
assert (all (matD == matB(:)))

clear ans fid
whos


It passes all assertions for me and the file sizes are 120000 bytes each.

What OS are you running on? Is it on a local disk or a network drive? (Not sure if it would make a difference, but it's good to rule out disk caching interference.)

Arun Giridhar <arungiridhar>
Group Member
Fri 25 Nov 2022 09:21:50 AM UTC, comment #1: 

The error is also present using 'float' as data type

José Luis García Pallero <jgpallero>
Fri 25 Nov 2022 09:18:24 AM UTC, original submission:  

Hello:

Yesterday (November, 24th) I cloned the stable branch of Octave (hg clone https://hg.octave.org/octave -r stable) and I compiled it (version command output is 8.1.0)

When I try to print a matrix generated by rand function to a binary file I obtain an incorrect size. See this code:

idf = fopen('m_eye.bin','wb','ieee-le');
mat = eye(100,150);
n = fwrite(idf,mat,'double')
fclose(idf);

idf = fopen('m_rand.bin','wb','ieee-le');
mat = rand(100,150);
n = fwrite(idf,mat,'double')
fclose(idf);


The first file contains a matrix generated by eye and written as 'double' format. As its dimensions are 100x150 the final file size if 100*150*8=120000 bytes. But in the second case the matrix is generated by rand function and the size of the file created is  114971 bytes (the size varies between different executions), so I think there is an error in fwrite() function or maybe in rand() or even in randn(), which produces also wrong size in the file.

But all works well with Octave 7.3.0, the file sizes are correct

José Luis García Pallero <jgpallero>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #54080:  configure-octave-stable added by jgpallero (7KiB - application/octet-stream)
file #54026:  configure-7.3.0 added by jgpallero (7KiB - application/octet-stream)
file #54027:  configure-default added by jgpallero (7KiB - application/octet-stream)
file #54028:  configure-stable added by jgpallero (7KiB - application/octet-stream)
file #54018:  configure added by jgpallero (7KiB - 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 nrjank (Posted a comment)
  • -email is unavailable- added by mreiter82__ (Posted a comment)
  • -email is unavailable- added by svillemot (Posted a comment)
  • -email is unavailable- added by arungiridhar (Octave file creation problem reported for Debian Sid)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by arungiridhar (Octave file creation problem reported for Debian Sid)
  • -email is unavailable- added by arungiridhar (Posted a comment)
  • -email is unavailable- added by jgpallero (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 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-03-31 arungiridhar StatusReady For Test Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNone 8.2.0
    2023-03-24 arungiridhar StatusConfirmed Ready For Test
        Planned ReleaseNone 8.2.0
    2023-03-16 arungiridhar StatusWorks For Me Confirmed
    2022-12-10 jgpallero Attached File- Added configure-octave-stable, #54080
    2022-11-27 arungiridhar Carbon-Copy- Added rlaboiss
    2022-11-27 jgpallero Attached File- Added configure-7.3.0, #54026
        Attached File- Added configure-default, #54027
        Attached File- Added configure-stable, #54028
    2022-11-26 arungiridhar Carbon-Copy- Added svillemot
    2022-11-25 jgpallero Attached File- Added configure, #54018
    2022-11-25 arungiridhar Release8.0.90 stable
    2022-11-25 arungiridhar StatusNone Works For Me

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code