bugGNU Octave - Bugs: bug #57632, Octave 5 file operations crash on...

 
 

bug #57632: Octave 5 file operations crash on cygwin

Submitted by:  marco atzeri <matzeri>
Submitted on:  Sun 19 Jan 2020 11:35:54 AM UTC  
 
Category:  Test Suite Severity:  2 - Minor
Priority:  3 - Low Item Group:  Segfault, Bus Error, etc.
Status:  Invalid Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  5.1.0 Operating System:  Other

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)

Sat 01 Feb 2020 06:35:31 AM UTC, comment #18: 

We found an solved the platform bug causing the Octave segfault
https://cygwin.com/ml/cygwin/2020-01/msg00299.html

after that 5.1.90 works fine as expected:

Summary:

  PASS                            15492
  FAIL                                6
  REGRESSION                          7
  XFAIL (reported bug)               26
  SKIP (missing feature)             63
  SKIP (run-time condition)          25

marco atzeri <matzeri>
Mon 27 Jan 2020 02:02:25 AM UTC, comment #17: 

Thank you for reporting back and your analysis.

I hope the error can get fixed in cygwin.  It was sad to loose an option for running Octave.

Kai Torben Ohlhus <siko1056>
Project Member
Sun 26 Jan 2020 08:45:15 AM UTC, comment #16: 

Hi Kai,
after long cross and double checking I arrive at a conclusion
that unlikely is Octave problem but likely some issue in the
Windows/Cygwin enviroment recently changed, may be
also some recent MS update in W10 Home itself.

https://cygwin.com/ml/cygwin/2020-01/msg00229.html

I tried to replicate my build of 5.1.0 on my system and
also that is currently failing while one month ago was fine.
Of the double check on other computers one is failing and one is passing.

You can close this bug as not confirmed as a proper Octave bug.

marco atzeri <matzeri>
Wed 22 Jan 2020 09:44:59 AM UTC, comment #15: 

Now I do not get it right.

Which combinations are working, which are failing?

Octave 5.1.0 + Cygwin 3.1.2 works

Octave 5.1.0 + Cygwin ??? fails (comment #11)

Octave 5.1.90 + Cygwin ??? fails (OP)

Then I rename the report accordingly.

I am not familiar with Cygwin development, is there some repository for the Cygwin build receipts or do you just upload the binaries somewhere for distribution?

Kai Torben Ohlhus <siko1056>
Project Member
Wed 22 Jan 2020 09:16:31 AM UTC, comment #14: 

The problem seems restriceted to the Octave 5.1.x built on
latest Cygwin snapshot.
Running 5.1.0 built on released Cygwin also in the snapshot seems
not effected. So the build is corrupted in some way.

I was using the snapshot because it has an effective improvment
on select that is notable on on X graphic performace.
I recently released 5.1.0 for Cygwin, and I had
no isse at all with Cygwin 3.1.2 of 2019-12-21 and
the only snapshot is one of 2020-01-14

If you are interested I can upload on my personal Web space
the scripts and build logs, but I do not remember any problem
in that notable.

https://cygwin.com/ml/cygwin-announce/2020-01/msg00010.html
https://cygwin.com/ml/cygwin-announce/2020-01/msg00011.html

marco atzeri <matzeri>
Wed 22 Jan 2020 07:04:32 AM UTC, comment #13: 

Do you have some cygwin repository to take a look about how it is built?  Are there any public build logs for the package?

Kai Torben Ohlhus <siko1056>
Project Member
Wed 22 Jan 2020 07:01:35 AM UTC, comment #12: 

That I am sorry to hear about.

To rebuild 5.1.0 was also one of my next (running out) ideas to see what is the difference...

It must have something to do with fseek() file position manipulation followed by some file I/O, closing operations...

Lowering priority, but leave this one open.

Kai Torben Ohlhus <siko1056>
Project Member
Wed 22 Jan 2020 05:00:32 AM UTC, comment #11: 

F**K

I re-built 5.1.0 on same machine and now I see the problem also there. Before it was a clean run.

So it is a recent Cygwin Bug, not Octave one.

marco atzeri <matzeri>
Tue 21 Jan 2020 05:58:59 PM UTC, comment #10: 

No failures again.
I am not aware on any problem specific problem in Cygwin relative to fseek, and I never had such problem in any previous version including 5.1.

I run also one of the failing test under GDB but nothing useful
is coming out:

octave:1> f = tempname ()
f = /tmp/oct-1TDWkD
octave:2> fid = fopen (f, "w+")
fid =  3
octave:3> fprintf (fid, "1\n2\n3\n4\n5\n6")
octave:4> fclose [Thread 6232.0x29ac exited with code 0]
[Thread 6232.0x436c exited with code 0]
[Thread 6232.0x28a8 exited with code 0]

ans = 0
octave:5> fid = fopen (f, "r+")
fid =  3
octave:6> c = textscan (fid, "%f %f", 2)

Thread 1 "octave-cli-5.1.90" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) trace
Tracepoint 1 at 0x0
(gdb) bt
#0  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info frame
Stack level 0, frame at 0x0:
 rip = 0x0; saved rip = <not saved>
 Outermost frame: previous frame identical to this frame (corrupt stack?)
 Arglist at 0xffffb460, args:
 Locals at 0xffffb460, Previous frame's sp is 0x0
(gdb)

marco atzeri <matzeri>
Tue 21 Jan 2020 06:57:09 AM UTC, comment #9: 

comment #8 is great news.

Alright, then I think we have the guilty one.  Reduced version of comment #5 program 2:

f = tempname ();
fid = fopen (f, "w");
fprintf (fid, "1\n2\n3\n4\n5\n6");
fseek (fid, 0, "bof");
fclose (fid);
unlink (f);

and

f = tempname ();
fid = fopen (f, "w");
fseek (fid, 0, "bof");
fclose (fid);
unlink (f);

I think any file position manipulation is a serious problem.  This happens also when calling textscan

https://hg.savannah.gnu.org/hgweb/octave/file/6628a284d56d/libinterp/corefcn/oct-stream.cc#l2543

Are there any known bugs in cygwin about using fseek, seekg, seekp?

https://en.cppreference.com/w/c/io/fseek

Kai Torben Ohlhus <siko1056>
Project Member
Tue 21 Jan 2020 06:20:37 AM UTC, comment #8: 

None of the 4 fail

marco atzeri <matzeri>
Tue 21 Jan 2020 06:08:36 AM UTC, comment #7: 

Thank you again for testing.  Now it comes to the very basics:

Program 1 (too simple to fail):

fid = fopen ("blub.txt", "w");
fputs (fid, "GNU Octave 1");
fclose (fid);
fid = fopen ("blub.txt", "r");
str = fgets (fid);
fclose (fid);
unlink ("blub.txt");
disp (str);

Program 2 (+ modes):

fid = fopen ("blub.txt", "w+");
fputs (fid, "GNU Octave 2");
fclose (fid);
fid = fopen ("blub.txt", "r+");
str = fgets (fid);
fclose (fid);
unlink ("blub.txt");
disp (str);

Program 3 (tempfile):

f = tempname ()
fid = fopen (f, "w");
fputs (fid, "GNU Octave 3");
fclose (fid);
fid = fopen (f, "r");
str = fgets (fid);
fclose (fid);
unlink (f);
disp (str);

Program 4 (tempfile, + modes):

f = tempname ()
fid = fopen (f, "w+");
fputs (fid, "GNU Octave 4");
fclose (fid);
fid = fopen (f, "r+");
str = fgets (fid);
fclose (fid);
unlink (f);
disp (str);

If those fail, I think there is a serious problem with Octave using cygwins file I/O capabilities.

Kai Torben Ohlhus <siko1056>
Project Member
Tue 21 Jan 2020 05:40:10 AM UTC, comment #6: 

test 1

octave:1> f = tempname ()
f = /tmp/oct-dVhjXf
octave:2> fid = fopen (f, "w+")
fid =  3
octave:3> fprintf (fid, "1\n2\n3\n4\n5\n6")
octave:4> fclose (fid)
ans = 0
octave:5> fid = fopen (f, "r+")
fid =  3
octave:6> c = textscan (fid, "%f %f", 2)
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault (core dumped)

test 2

octave:1> f = tempname ()
f = /tmp/oct-hcAGTu
octave:2> fid = fopen (f, "w+")
fid =  3
octave:3> fprintf (fid, "1\n2\n3\n4\n5\n6")
octave:4> fseek (fid, 0, "bof")
ans = 0
octave:5> str = fgets (fid)
str = 1

octave:6> disp (str)
1

octave:7> fclose (fid)

here octave crash with no output at all

marco atzeri <matzeri>
Tue 21 Jan 2020 05:20:23 AM UTC, comment #5: 

Then next I think about the file position manipulation to fail.  How about this programs?

Program 1 (File write and read in separate operations):

f = tempname ();
fid = fopen (f, "w+");
fprintf (fid, "1\n2\n3\n4\n5\n6");
fclose (fid);
fid = fopen (f, "r+");
c = textscan (fid, "%f %f", 2);
E = feof (fid);
fclose (fid);
unlink (f);
assert (! E);

Program 2 (fgets instead of textscan):

f = tempname ();
fid = fopen (f, "w+");
fprintf (fid, "1\n2\n3\n4\n5\n6");
fseek (fid, 0, "bof");
str = fgets (fid);
disp (str);
fclose (fid);
unlink (f);

Kai Torben Ohlhus <siko1056>
Project Member
Mon 20 Jan 2020 06:45:33 PM UTC, comment #4: 

both versions of the original test are failing (see attachments),
so it is not "\r"

%!test
%! f = tempname ();
%! fid = fopen (f, "w+");
%! fprintf (fid, "1\n2\n3\n4\n5\n6");
%! fseek (fid, 0, "bof");
%! c = textscan (fid, "%f %f", 2);
%! E = feof (fid);
%! fclose (fid);
%! unlink (f);
%! assert (c, {1, 2});
%! assert (! E);
%!test
%! f = tempname ();
%! fid = fopen (f, "w+");
%! fprintf (fid, "1\r\n2\r3\n4\r\n5\n6");
%! fseek (fid, 0, "bof");
%! c = textscan (fid, "%f %f", 4);
%! fclose (fid);
%! unlink (f);
%! assert (c, {[1;3], [2;4]});

Textscan alone has no issue:

octave:1> c = textscan ("1\n2\r3\n4\r\n5\n6", "%f %f", 4)
c =
{
  [1,1] =

     1
     3

  [1,2] =

     2
     4

}

octave:2> c = textscan ("1\n2\r3\n4\r\n5\n6", "%f %f", 2)
c =
{
  [1,1] =  1
  [1,2] =  2
}

octave:3> c = textscan ("1\r\n2\r3\n4\r\n5\n6", "%f %f", 2)
c =
{
  [1,1] =  1
  [1,2] =  2
}

octave:4> c = textscan ("1\r\n2\r3\n4\r\n5\n6", "%f %f", 4)
c =
{
  [1,1] =

     1
     3

  [1,2] =

     2
     4

}

}

marco atzeri <matzeri>
Mon 20 Jan 2020 07:59:38 AM UTC, comment #3: 

So either "textscan()" itself, the carriage return "\r" chars, or the file position manipulations (fseek(), ...) are the guilty ones.  First what is about "textscan":

Does this code crash the cygwin build?

c = textscan ("1\r\n2\r3\n4\r\n5\n6", "%f %f", 4)
c =
{
  [1,1] =

     1
     3

  [1,2] =

     2
     4

}

Kai Torben Ohlhus <siko1056>
Project Member
Mon 20 Jan 2020 07:07:26 AM UTC, comment #2: 

thanks for remind me to bisect.
I have found two similar tests that cause it.

I have also verified that 5.1.0 is immune from it.

octave:1> test round6a.m
PASSES 1 out of 1 test
octave:2> test round6b.m
PASSES 1 out of 1 test

Replicating the test step by step I have:

octave:1> f = tempname ();
octave:2> fid = fopen (f, "w+");
octave:3> fprintf (fid, "1\r\n2\r3\n4\r\n5\n6");
octave:4> fseek (fid, 0, "bof");
octave:5> c = textscan (fid, "%f %f", 4);
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault (core dumped)

(file #48256, file #48257)

marco atzeri <matzeri>
Mon 20 Jan 2020 04:46:52 AM UTC, comment #1: 

Thank you for the report Marco.  I think we need to narrow this down and attached file #48254 which is "file-io.cc-tst" of the current stable branch.

Can you put that file in some arbitrary directory and try to figure out the guilty test?

I am sorry, that it is 700 lines of code and 90 tests.  But I found bisecting (erasing half of the file...) goes quite fast to identify a guilty test(s).  After altering the file you can just run

test file-io.cc-tst
PASSES 90 out of 90 tests

And we hopefully find that subset of the 90 tests that trouble cygwin.

Kai Torben Ohlhus <siko1056>
Project Member
Sun 19 Jan 2020 11:35:54 AM UTC, original submission:  

System: 3.1.2(0.340/5/3) x86_64 Cygwin
gcc (GCC) 7.4.0

Build is fine but running the testsuite I catch

  libinterp/corefcn/file-io.cc-tst ...............................fatal: caught signal Segmentation fault -- stopping myself...
/bin/sh: line 1:  3519 Segmentation fault      (core dumped) /bin/sh ../run-octave --norc --silent --no-history -p /cygdrive/d/cyg_pub/devel/octave/octave-5.1.90-1.x86_64/build/test/mex /cygdrive/d/cyg_pub/devel/octave/octave-5.1.90-1.x86_64/src/octave-5.1.90/test/fntests.m /cygdrive/d/cyg_pub/devel/octave/octave-5.1.90-1.x86_64/src/octave-5.1.90/test
make[3]: *** [Makefile:27888: check-local] Error 139

marco atzeri <matzeri>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #48256:  round6a.m added by matzeri (243B - application/octet-stream)
file #48257:  round6b.m added by matzeri (219B - application/octet-stream)
file #48254:  file-io.cc-tst added by siko1056 (22KiB - 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 siko1056 (Updated the item)
  • -email is unavailable- added by matzeri (Submitted the item)
  •  

    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 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-01-27 siko1056 StatusConfirmed => Invalid
        Open/ClosedOpen => Closed
    2020-01-22 siko1056 Releasedev => 5.1.0
    2020-01-22 siko1056 Severity4 - Important => 2 - Minor
        Priority7 - High => 3 - Low
        StatusNeed Info => Confirmed
        Summary5.1.90 crash on cygwin => Octave 5 file operations crash on cygwin
    2020-01-20 matzeri Attached File- => Added round6a.m, #48256
        Attached File- => Added round6b.m, #48257
    2020-01-20 siko1056 Severity3 - Normal => 4 - Important
        Priority5 - Normal => 7 - High
        StatusNone => Need Info
    2020-01-20 siko1056 Attached File- => Added file-io.cc-tst, #48254

    Back to the top


    Powered by Savane 3.5