Opened 9 years ago

Closed 7 years ago

#9273 closed defect (invalid)

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

Reported by: drkirkby Owned by: cremona
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: elliptic curves Keywords: ecc2011
Cc: robertwb, rlm, was, jhpalmieri Merged in:
Authors: Reviewers: Jeroen Demeyer
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by drkirkby)

#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 9 years ago by drkirkby

  • Cc robertwb rlm was jhpalmieri added

comment:2 follow-up: Changed 9 years ago by 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?

comment:3 in reply to: ↑ 2 Changed 9 years ago by drkirkby

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 9 years ago by drkirkby

  • Description modified (diff)

comment:5 Changed 9 years ago by drkirkby

  • Description modified (diff)

comment:6 Changed 9 years ago by drkirkby

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 9 years ago by drkirkby

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 9 years ago by rlm

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 9 years ago by drkirkby

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 8 years ago by zimmerma

  • Keywords ecc2011 added
  • Status changed from new to needs_info

David, does this problem still happen?

Paul

comment:11 Changed 7 years ago by jdemeyer

  • Milestone changed from sage-5.8 to sage-duplicate/invalid/wontfix
  • Reviewers set to Jeroen Demeyer
  • Status changed from needs_info to needs_review

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

comment:12 Changed 7 years ago by jdemeyer

  • Status changed from needs_review to positive_review

comment:13 Changed 7 years ago by jdemeyer

  • Resolution set to invalid
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.