Opened 12 years ago

Closed 10 years ago

#9273 closed defect (invalid)

doctest elliptic_curves/BSD.py reports "file not found"

Reported by: David Kirkby Owned by: John Cremona
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: elliptic curves Keywords: ecc2011
Cc: Robert Bradshaw, Robert Miller, William Stein, John Palmieri Merged in:
Authors: Reviewers: Jeroen Demeyer
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by David Kirkby)

#9127 was supposed to fix this, but it seems the fix is not complete.

Hardware & associated software

  • Sun Blade 1000
  • 2 x 900 MHz UltraSPARC III+ CPUs
  • 2 GB RAM
  • Solaris 10 03/2005 (first release of Solaris 10)
  • gcc 4.4.3 (uses Sun linker and assembler)
  • SEAGATE-ST3146807FC 2 Gbit/s 15,000 rpm fiber channel disk (FCAL)
  • UFS (not ZFS) local file system.

Sage version

  • 4.4.4.alpha1

The error

sage -t  -long devel/sage/sage/calculus/riemann.pyx
         [712.7 s]

-------------------------------------------------------------

The following tests failed:

        sage -t  -long devel/sage/sage/schemes/elliptic_curves/BSD.py # File not found
-------------------------------------------------------------
Total time for all tests: 33947.4 seconds

Change History (13)

comment:1 Changed 12 years ago by David Kirkby

Cc: Robert Bradshaw Robert Miller William Stein John Palmieri added

comment:2 Changed 12 years ago by Robert Miller

This has nothing to do with the file BSD.py. It is a bug in the doctesting code, which is triggered (as William tells me) by lag times on file systems and the like. It starts testing before the doctesting file is created.

Did you try running the tests again?

comment:3 in reply to:  2 Changed 12 years ago by David Kirkby

Replying to rlm:

This has nothing to do with the file BSD.py. It is a bug in the doctesting code, which is triggered (as William tells me) by lag times on file systems and the like. It starts testing before the doctesting file is created.

Did you try running the tests again?

I run that test more than once and it failed more than once.

Note although the machine is rather old (900 MHz CPUs), the disks are local, with a 2 Gbit/s fibre channel interface and 15,000 rpm, so the disk performance is probably better than most modern PCs. If the disks were on a NFS file system, I could perhaps understand that, but it seems unlikely with local disks like this.

I managed to mess up my build (started a 64-bit build in the same directory as the 32-bit one!), so are rebuilding now. I'll try again once complete.

Dave

comment:4 Changed 12 years ago by David Kirkby

Description: modified (diff)

comment:5 Changed 12 years ago by David Kirkby

Description: modified (diff)

comment:6 Changed 12 years ago by David Kirkby

I just updated the technical details of the hardware in the description. I usually put the details, but not normally the disks. But in this case I thought it prudent to add it.

comment:7 Changed 12 years ago by David Kirkby

I've rebuilt this and tried BSD.py and it passes each time. I've no idea what the underlying problem may be, but the doc test has passed several times now.

Dave

comment:8 Changed 12 years ago by Robert Miller

Then I suggest we close this ticket.

Is there a ticket for the "file not found" issue in general? It would be nice if there were a way to reproduce the issue...

comment:9 Changed 12 years ago by David Kirkby

There is a ticket for "file not found" - see #9316.

The assumption being made on that ticket is that the real cause of the "file not found" message is a timeout. John Cremona says

The reason for the timeout was simply that I suspended my laptop for a couple of hours and then woke it up.

I'm personally not convinced that is the reason this test has failed for me. When BSD.py passes, it does so in around 205 seconds. SAGE_TIMEOUT is set to 1000 seconds and SAGE_TIMEOUT_LONG is set to 10000 seconds. Since the BSD.py test is marked as long, it would need to slow down by a factor of 48 (10000/205) before causing a timeout. My SPARC is quite and old machine and does not go to sleep in the same way some computers do.

There appears to be another test which is randomly failing in a different way - see #9310.

I don't know what the cause(s) are but I'm less than convinced this is due to delays on file systems or processors going to sleep.

I think the ticket should remain open until such time as it gets resolved. Being random in nature, it might not be easy to resolve.

comment:10 Changed 11 years ago by Paul Zimmermann

Keywords: ecc2011 added
Status: newneeds_info

David, does this problem still happen?

Paul

comment:11 Changed 10 years ago by Jeroen Demeyer

Milestone: sage-5.8sage-duplicate/invalid/wontfix
Reviewers: Jeroen Demeyer
Status: needs_infoneeds_review

I have never seen this problem and in any case, the doctesting framework will be rewritten completely: #12415.

comment:12 Changed 10 years ago by Jeroen Demeyer

Status: needs_reviewpositive_review

comment:13 Changed 10 years ago by Jeroen Demeyer

Resolution: invalid
Status: positive_reviewclosed
Note: See TracTickets for help on using tickets.