zn_poly segfaults during tuning and tests on OS X and Cygwin when built on a busy system

[jpflori]

See #13137 for more info.
This is true with different versions of MPIR so seems to be because of zn_poly and not of MPIR.
No problems where spotted on Linuces.

---

New spkg: http://boxen.math.washington.edu/home/leif/Sage/spkgs/zn_poly-0.9.p11.spkg

md5sum: 012e63d181151c19ddc71bdfaeb14e03 zn_poly-0.9.p11.spkg

zn_poly-0.9.p11 (Leif Leonhardy, May 24th, 2013)

• zn_poly segfaults during tuning and tests on OS X and Cygwin when built on a busy system #13947: Fix nuss_mul() test failing especially if tuning happened
  under "heavy" load (at least on MacOS X and Cygwin)
  Add fix_fudge_factor_in_nuss-test.c.patch; fix suggested by David
  Harvey.

CC: @nexttime @jhpalmieri @jdemeyer @kcrisman @kwankyu

Component: packages: standard

Keywords: zn_poly spkg cygwin osx nuss_mul fail

Author: Leif Leonhardy

Reviewer: Jeroen Demeyer

Merged: sage-5.10.beta5

Issue created by migration from https://trac.sagemath.org/ticket/13947

[nexttime]

comment:1

Does it really segfault, and especially does the tuning segfault?

I thought zn_poly would just occasionally generate "unexpected^TM" values during tuning on MacOS X and Cygwin (presumably only under heavy system load), such that afterwards some tests (with zn_poly rebuilt, or more precisely, relinked with these paramaters) would deterministically fail.

(This might still depend on the compiler as well, at least the way it fails.)

[nexttime]

comment:2

P.S.: I was actually going to create a zn_poly spkg which simply saves the tuning parameters in case the tests fail, asking the user for submitting them to sage-devel or sage-release... (and probably doing a few more attempts to get working tuning parameters, and/or inform the user that he/she should reinstall the spkg when the sysload is lower). :-)

[nexttime]

comment:3

P.P.S.: John, is it always (just) nuss_mul() that fails the test?

[jdemeyer]

comment:4

I also reproduced it on bsd.math.

[jdemeyer]

comment:5

Also reproduced on hawk (OpenSolaris i386).

[nexttime]

comment:6

Replying to @jdemeyer:

I also reproduced it on bsd.math.

How? I tried hard yesterday, but didn't manage.

Even with John's tuning parameters that made the test(s) fail for him, still all tests (quick as well as extensive) pass for me on bsd.math (with Sage 5.6.beta3 [with GCC 4.6.3 built], and the included MPIR 2.4.0, FWIW).

I was actually hoping we could reproduce the test failures on e.g. Linux as well with such "failing" parameters, although probably depending on the GCC version, too.

[nexttime]

comment:7

Replying to @nexttime:

Replying to @jdemeyer:

I also reproduced it on bsd.math.

How? I tried hard yesterday, but didn't manage.

Hmmm, I probably forgot to run make test (which rebuilds test/test with a debug version of src/tuning.c) in addition to make (which apparently just rebuilds the static library, not used by test; IMHO a flaw in the Makefiles).

But still, I cannot reproduce the failure with John's parameters.

[nexttime]

comment:8

Replying to @nexttime:

Replying to @nexttime:

Replying to @jdemeyer:

I also reproduced it on bsd.math.

How? I tried hard yesterday, but didn't manage.

Hmmm, I probably forgot to run make test (which rebuilds test/test with a debug version of src/tuning.c) in addition to make (which apparently just rebuilds the static library, not used by test; IMHO a flaw in the Makefiles).

But still, I cannot reproduce the failure with John's parameters.

Ooops, not true. In the last attempt, I missed that nuss_mul() failed, but only when tested "extensively":

(sage-sh) leif@bsd:src$ test/test -quick all
mpn_smp_basecase()... ok
mpn_smp_kara()... ok
mpn_smp()... ok
mpn_mulmid()... ok
zn_array_recover_reduce()... ok
zn_array_pack()... ok
zn_array_unpack()... ok
zn_array_mul_KS1()... ok
zn_array_mul_KS2()... ok
zn_array_mul_KS3()... ok
zn_array_mul_KS4()... ok
zn_array_sqr_KS1()... ok
zn_array_sqr_KS2()... ok
zn_array_sqr_KS3()... ok
zn_array_sqr_KS4()... ok
zn_array_mulmid_KS1()... ok
zn_array_mulmid_KS2()... ok
zn_array_mulmid_KS3()... ok
zn_array_mulmid_KS4()... ok
nuss_mul()... ok
pmfvec_fft_dc()... ok
pmfvec_fft_huge()... ok
pmfvec_ifft_dc()... ok
pmfvec_ifft_huge()... ok
pmfvec_tpfft_dc()... ok
pmfvec_tpfft_huge()... ok
pmfvec_tpifft_dc()... ok
pmfvec_tpifft_huge()... ok
zn_array_mul_fft()... ok
zn_array_sqr_fft()... ok
zn_array_mulmid_fft()... ok
zn_array_mul_fft_dft()... ok
zn_array_invert()... ok

All tests passed.
(sage-sh) leif@bsd:src$ time test/test all
mpn_smp_basecase()... ok
mpn_smp_kara()... ok
mpn_smp()... ok
mpn_mulmid()... ok
zn_array_recover_reduce()... ok
zn_array_pack()... ok
zn_array_unpack()... ok
zn_array_mul_KS1()... ok
zn_array_mul_KS2()... ok
zn_array_mul_KS3()... ok
zn_array_mul_KS4()... ok
zn_array_sqr_KS1()... ok
zn_array_sqr_KS2()... ok
zn_array_sqr_KS3()... ok
zn_array_sqr_KS4()... ok
zn_array_mulmid_KS1()... ok
zn_array_mulmid_KS2()... ok
zn_array_mulmid_KS3()... ok
zn_array_mulmid_KS4()... ok
nuss_mul()... FAIL!

At least one test FAILED!

Presumably because those tests take a pretty long time... ;-)

[nexttime]

comment:9

The (extensive) tests that didn't get run because test exits upon the first failure (nuss_mul()) all pass for me:

(sage-sh) leif@bsd:src$ time test/test pmfvec_fft_dc pmfvec_fft_huge pmfvec_ifft_dc pmfvec_ifft_huge pmfvec_tpfft_dc pmfvec_tpfft_huge pmfvec_tpifft_dc pmfvec_tpifft_huge zn_array_mul_fft zn_array_sqr_fft zn_array_mulmid_fft zn_array_mul_fft_dft zn_array_invert && echo OK
pmfvec_fft_dc()... ok
pmfvec_fft_huge()... ok
pmfvec_ifft_dc()... ok
pmfvec_ifft_huge()... ok
pmfvec_tpfft_dc()... ok
pmfvec_tpfft_huge()... ok
pmfvec_tpifft_dc()... ok
pmfvec_tpifft_huge()... ok
zn_array_mul_fft()... ok
zn_array_sqr_fft()... ok
zn_array_mulmid_fft()... ok
zn_array_mul_fft_dft()... ok
zn_array_invert()... ok

All tests passed.

real	1m15.127s
user	1m15.054s
sys	0m0.027s
OK

(This is with John's "failing" tuning parameters, bsd.math.)

[jhpalmieri]

comment:10

Replying to @nexttime:

P.P.S.: John, is it always (just) nuss_mul() that fails the test?

That's my recollection. In my experiment yesterday, I only ran that test (using ./test nuss_mull).

[nexttime]

comment:11

Replying to @jhpalmieri:

Replying to @nexttime:

P.P.S.: John, is it always (just) nuss_mul() that fails the test?

That's my recollection. In my experiment yesterday, I only ran that test (using ./test nuss_mull).

With your tuning parameters, I also only get the extensive test of nuss_mul() failing. Reproducible on Linux, with GCC 4.7.0. (Haven't tried other versions yet, but this shows at least it's not limited to GCC 4.6.3.)

[jpflori]

comment:12

IIRC (and I'm quite sure I am) I got segfault as well during the tuning itself on Cygwin (64bits Windows 7), mostly when issuing make with MAKE="make -j4" so the system must have been busy as well, but IIRC (less sure) it also happened when building zn_poly alone.

The segfaults happened while tuning KS/FFT things, mostly the last one which is mulmid, but I seem to tremember it also happened during the previous KS/FFT things sometimes.

Of course I tried to reproduce that this morning and could not (I let ATLAS build in parallel to keep the system busy but that did not seem to do the trick).

I'll give it another shot in the next couple of days.

[jpflori]

comment:13

Replying to @nexttime:

Replying to @jhpalmieri:

Replying to @nexttime:

P.P.S.: John, is it always (just) nuss_mul() that fails the test?

That's my recollection. In my experiment yesterday, I only ran that test (using ./test nuss_mull).

With your tuning parameters, I also only get the extensive test of nuss_mul() failing. Reproducible on Linux, with GCC 4.7.0. (Haven't tried other versions yet, but this shows at least it's not limited to GCC 4.6.3.)

Could you give it a shot by only testing the MPIR part and disabling the comparison in the test code?
And do the same with zn_poly code only?
So if it's really a bug in MPIR, or calling a function on invalid (let's say really too small) parameters we'll be settled.

[nexttime]

comment:14

Replying to @jpflori:

Could you give it a shot by only testing the MPIR part and disabling the comparison in the test code?
And do the same with zn_poly code only?

???

It's just the comparison that fails (or, more precisely, the tests make the "success" depend on the comparison only); no segfaults, no failed assertions.

I removed the "exit on first failure" and got 5 failures (from the "extensive" nuss_mul() test; all other tests passed, as mentioned).

So if it's really a bug in MPIR, or calling a function on invalid (let's say really too small) parameters we'll be settled.

Well, since the failure depends on zn_poly's thresholds (for zn_poly's functions), it's IMHO clearly in zn_poly, not MPIR. (Unless zn_poly was right only with the "failing" tuning parameters, and incidentally MPIR [2.4.0 and 2.6.0] and zn_poly would give the same wrong results otherwise. Or am I missing something?)

There are still random numbers involved though, so the tests may pass or fail under different circumstances.

[nexttime]

comment:15

The offending parameter in John's tuning.c seems to be tuning_info[62].mul_fft_thresh (=90, which is extraordinarily low), i.e., that's the one that (for me) causes the nuss_mul() test failures here.

(There are others, but those aren't relevant for the tests, apparently.)

[nexttime]

comment:16

Replying to @nexttime:

The offending parameter in John's tuning.c seems to be tuning_info[62].mul_fft_thresh (=90, which is extraordinarily low), i.e., that's the one that (for me) causes the nuss_mul() test failures here.

When I set all mul_fft_threshs to 1, I get a lot more failures (although not all tests/comparisons fail).

More interestingly, the failures only happen when squaring. If I use separate "buffers" for both operands (in test/nuss-test.c), all failures vanish, so this seems to be an aliasing problem. (Still strange the error doesn't happen for all inputs; someone^TM should investigate further... ;-) )

[nexttime]

comment:17

Replying to @nexttime:

Replying to @nexttime:

The offending parameter in John's tuning.c seems to be tuning_info[62].mul_fft_thresh (=90, which is extraordinarily low), i.e., that's the one that (for me) causes the nuss_mul() test failures here.

When I set all mul_fft_threshs to 1, I get a lot more failures (although not all tests/comparisons fail).

More interestingly, the failures only happen when squaring.

I also get the quick test to fail with all (2...64 bits) mul_fft_thresh entries set to 1.

And I meanwhile managed to get "invalid" tuning parameters on Linux x86_64, too (although just once, but unintentionally).

I don't think the bug (or test failure) is in any way related to the compiler / GCC version or compilation options, as I've so far been able to force it with every GCC version I tried (4.4.3, 4.6.3, 4.7.0, 4.7.2), regardless of whether I used e.g. -O0 or -O3, or -fno-strict-aliasing.

Still don't know whether (just) testcase_nuss_mul() is broken (in violating preconditions by using the same array for both [identical] operands when squaring [sqr==1], although assertion checking is enabled when compiling for the test program), or whether it actually triggers a real bug by doing so. Someone more knowledgable than me should probably check this.

[As mentioned, all failures vanish when buf1 != buf2, i.e., when they don't alias even if sqr==1.]

[kiwifb]

comment:19

Ok, leif, can you put your recipe to trigger the failure in the summary?

[nexttime]

comment:20

Replying to @kiwifb:

Ok, leif, can you put your recipe to trigger the failure in the summary?

Oh, I don't recall right now (searching logs ...), but I think I just faked the values in tuning.c (generated by tune/tune[.c]) by modifying test/test.c (i.e., added something like { int i; for (i=2;i<=64;i++) tuning_info[i].mul_fft_thresh=1; } to the beginning of test/test.c(?)'s main()).

After running sage -f -s zn_poly, start a Sage subshell and enter the build directory.

Then you can play with it, i.e., modify the code (or tuning values), and run make test && test/test [-quick] [tests_to_run]* (in $SAGE_ROOT/spkg/build/zn_poly-0.9.p{9,10}/src/) IIRC.

(More to come if I find the logs, otherwise also see the comments above for more info.)

[nexttime]

comment:21

Replying to @nexttime:

(More to come if I find the logs, otherwise also see the comments above for more info.)

Hmmm, sorry, cannot find any. I vaguely remember I had a power outage before I saved anything... 8-/

[nexttime]

comment:22

Replying to @nexttime:

Replying to @kiwifb:

Ok, leif, can you put your recipe to trigger the failure in the summary?

Oh, I don't recall right now (searching logs ...), but I think I just faked the values in tuning.c (generated by tune/tune[.c]) by modifying test/test.c (i.e., added something like { int i; for (i=2;i<=64;i++) tuning_info[i].mul_fft_thresh=1; } to the beginning of test/test.c(?)'s main()).

Yep:

--- zn_poly-0.9.p5/src/test/test.c.orig	2008-09-19 17:37:47.000000000 +0200
+++ zn_poly-0.9.p5/src/test/test.c	2013-01-13 20:33:11.919633442 +0100
@@ -209,6 +209,11 @@
    
    int all_success = 1, any_targets = 0, quick = 0, success, i, j;
 
+#if 1 || defined(FAKE_THRESHOLDS)
+   for(i=2;i<=64;i++)
+     tuning_info[i].mul_fft_thresh=1; // always (I think)
+#endif
+
    for (j = 1; j < argc; j++)
    {
       if (!strcmp (argv[j], "-quick"))

I've also found

--- zn_poly-0.9.p5/src/test/nuss-test.c.orig	2008-09-19 17:37:47.000000000 +0200
+++ zn_poly-0.9.p5/src/test/nuss-test.c	2013-01-13 20:25:40.629633300 +0100
@@ -59,6 +59,16 @@
    ref_zn_array_scalar_mul (res, res, n, x, mod);
    int success = !zn_array_cmp (ref, res, n);
    
+#if 1 || defined(TEST_VERBOSE)
+   if(!success)
+   {
+     fprintf(stderr,
+       "testcase_nuss_mul(): comparison FAILED: lgL=%u (n=%lu) sqr=%d mod.m=%lu mod.bits=%d\n",
+       lgL, n, sqr,
+       mod->m, mod->bits);
+   }
+#endif
+   
    pmfvec_clear (vec2);
    pmfvec_clear (vec1);
    
@@ -67,7 +77,7 @@
    if (!sqr)
       free (buf2);
    free (buf1);
-   
+
    return success;
 }
 
@@ -84,6 +94,7 @@
    zn_mod_t mod;
 
    for (i = 0; i < num_test_bitsizes; i++)
+#if 0
    for (lgL = 2; lgL <= (quick ? 11 : 13) && success; lgL++)
    for (trial = 0; trial < (quick ? 1 : 5) && success; trial++)
    {
@@ -92,6 +103,16 @@
       success = success && testcase_nuss_mul (lgL, 1, mod);
       zn_mod_clear (mod);
    }
+#else	/* don't stop upon first failure: */
+   for (lgL = 2; lgL <= (quick ? 11 : 13) /* && success */; lgL++)
+   for (trial = 0; trial < (quick ? 1 : 5) /* && success */; trial++)
+   {
+      zn_mod_init (mod, random_modulus (test_bitsizes[i], 1));
+      success &= testcase_nuss_mul (lgL, 0, mod);
+      success &= testcase_nuss_mul (lgL, 1, mod);
+      zn_mod_clear (mod);
+   }
+#endif
    
    return success;
 }

to not stop at the first test failure in nuss-test.c. (The patches here are against the .p5, but that shouldn't matter if you just strip the first folder name with patch -p1.)

[wdjoyner]

attached by request (my dual quad-core 10.7.5 mac is having this problem)

[kcrisman]

comment:23

Attachment: tuning.c.gz

Replying to @jpflori:

IIRC (and I'm quite sure I am) I got segfault as well during the tuning itself on Cygwin (64bits Windows 7), mostly when issuing make with MAKE="make -j4" so the system must have been busy as well, but IIRC (less sure) it also happened when building zn_poly alone.

Just as a data point, I can confirm this, even with make -j2, on Cygwin Win 7.

[nexttime]

comment:24

Replying to @kcrisman:

Replying to @jpflori:

IIRC (and I'm quite sure I am) I got segfault as well during the tuning itself on Cygwin (64bits Windows 7), mostly when issuing make with MAKE="make -j4" so the system must have been busy as well, but IIRC (less sure) it also happened when building zn_poly alone.

Just as a data point, I can confirm this, even with make -j2, on Cygwin Win 7.

Confirm what exactly?

Tuning fails if the box is too busy? And if so, how?

Building itself (before and/or after tuning) can also fail?

Or does just the quick test after "successfully" building zn_poly fail (due to failing comparisons, as intended, or with a segfault or whatever)?

[kcrisman]

comment:25

IIRC (and I'm quite sure I am) I got segfault as well during the tuning itself on Cygwin (64bits Windows 7), mostly when issuing make with MAKE="make -j4" so the system must have been busy as well, but IIRC (less sure) it also happened when building zn_poly alone.

Just as a data point, I can confirm this, even with make -j2, on Cygwin Win 7.

Confirm what exactly?
Tuning fails if the box is too busy? And if so, how?

Correct; with one other spkg being built it was too much. Segfault during tuning in KS/FFT mul, repeatable. No problems during short self-test, though of course I couldn't try that without using just one thread in any case.

Building itself (before and/or after tuning) can also fail?

I guess not.

[nexttime]

comment:40

(I could leave it as is and just update SPKG.txt accordingly, of course also committing the changes.)

[jdemeyer]

comment:41

I would just include the patch and see if people still report problems.

[nexttime]

Diff between the .p10 and the .p11. For reference / review only.

[nexttime]

comment:42

Attachment: zn_poly-0.9.p10-p11.diff.gz

[nexttime]

comment:43

Replying to @jdemeyer:

I would just include the patch and see if people still report problems.

Ok, did so, see attached diff.

The -testing spkg is still there, in case anybody wants to play with it.

[nexttime]

comment:44

Somebody should take a look at tuning on MacOS X and Cygwin though, as the failures were apparently triggered by "random" tuning parameters... (which the patch obviously doesn't affect).

[kcrisman]

comment:45

@David - thank you so much for helping track this down in "stable" code! I hope this is the only one...

Somebody should take a look at tuning on MacOS X and Cygwin though

Agreed. I may be able to do this on OS X today, but not Cygwin until later.

[kcrisman]

comment:46

I can't reproduce it on my Mac box, but I don't think I ever did. Maybe John can try it on bsd again...

[jhpalmieri]

comment:47

I agree that tuning on heavily loaded OS X systems has not been addressed.

I also don't know about any segfaults.

Anyway, I tried building the old and new spkgs on a loaded OS X system. I could not reproduce any failures in the quick test suite, but the old spkg reliably failed its full test-suite, while the new spkg reliably passed its full test suite.

klee, can you test it out, too?

[kwankyu]

comment:48

Interim report:

1. Making Sage 5.10.beta2 again, I checked it fails at the same spot, zn_poly's quick test suite, with "null_mul()... FAIL!".

2. I installed the new spkg with the command "./sage -f http://boxen.math.washington.edu/home/leif/Sage/spkgs/zn_poly-0.9.p11.spkg" and succeeded. It passed the zn_poly's quick test suite smoothly!

3. Now my machine is making Sage 5.10.beta2.

4. Then I downloaded Sage 5.10.beta4, the latest, and replaced zn_poly-0.9.p10.spkg with zn_poly-0.9.p11.spkg in the directory spkg/standard. Then I started making Sage 5.10.beta4. So now my machine is making both beta2 and beta4 at the same time. Perhaps this makes sure the machine is quite loaded. Also the machine is running two virtual machines and some usual applications like Chrome browser.

I will report the final result as soon as the machin finishes building!

By the way, thank you all so much.

[kwankyu]

comment:49

Report on making Sage 5.10.beta2:

Built successfully. Tested successfully except one failure, which seems unrelated with the current issue.

sage -t devel/sage/sage/calculus/calculus.py
**********************************************************************
File "devel/sage/sage/calculus/calculus.py", line 1309, in sage.calculus.calculus.laplace
Failed example:
    (p1+p2).save(os.path.join(SAGE_TMP, "de_plot.png"))
Expected nothing
Got:
    dyld: Library not loaded: /usr/X11/lib/libfreetype.6.dylib
      Referenced from: /usr/X11/bin/fc-list
      Reason: Incompatible library version: fc-list requires version 14.0.0 or later, but libfreetype.6.dylib provides version 10.0.0
    dyld: Library not loaded: /usr/X11/lib/libfreetype.6.dylib
      Referenced from: /usr/X11/bin/fc-list
      Reason: Incompatible library version: fc-list requires version 14.0.0 or later, but libfreetype.6.dylib provides version 10.0.0
**********************************************************************

[kcrisman]

comment:50

Yes, this is a very occasional OS X error that I haven't been able to track down, and that has nothing to do with this ticket.

[kwankyu]

comment:51

Report on making Sage 5.10.beta4:

Well... Building failed with "Error installing package sage-5.10.beta4". So I tried "./sage -i spkg/standard/zn_poly-0.9.p11.spkg", and it was installed successfully.

So my overall impression is that the patch corrects the issue, and the issue seems unrelated with the heavy loadedness of my machine (Mac Pro quad-core intel xeon with Mac OS X 10.7.5).

[kcrisman]

comment:52

Report on making Sage 5.10.beta4:
Well... Building failed with "Error installing package sage-5.10.beta4". So I tried "./sage -i spkg/standard/zn_poly-0.9.p11.spkg", and it was installed successfully.

But what was the failure in installing beta4? If it was still zn_poly then just installing this spkg wouldn't address the underlying issue.

To really test this, assuming the failure was zn_poly, can you unpack the beta4 tarball again, but replace spkg/standard/zn_poly<old>.spkg with this spkg before compiling and then compile under heavy load (maybe even just make -j4) and see if the problem persists.

[nexttime]

comment:53

Replying to @kcrisman:

Report on making Sage 5.10.beta4:
Well... Building failed with "Error installing package sage-5.10.beta4". So I tried "./sage -i spkg/standard/zn_poly-0.9.p11.spkg", and it was installed successfully.

But what was the failure in installing beta4? If it was still zn_poly then just installing this spkg wouldn't address the underlying issue.

package sage-5.10.beta4 = the Sage library spkg failed to install, so apparently zn_poly did install successfully, as the former depends on the latter.

On the other hand, (re)installing zn_poly afterwards (with just sage -i ...) should have just told you that it's already installed, which you at least did not explicitly mention.

(But you said you copied the .p11 into spkg/standard/ before building Sage 5.10.beta4.)

[nexttime]

comment:54

... where "you" addresses Kwankyu, in case that wasn't clear.

[kwankyu]

comment:55

Replying to @nexttime:

Replying to @kcrisman:

Report on making Sage 5.10.beta4:
Well... Building failed with "Error installing package sage-5.10.beta4". So I tried "./sage -i spkg/standard/zn_poly-0.9.p11.spkg", and it was installed successfully.

But what was the failure in installing beta4? If it was still zn_poly then just installing this spkg wouldn't address the underlying issue.

package sage-5.10.beta4 = the Sage library spkg failed to install, so apparently zn_poly did install successfully, as the former depends on the latter.

On the other hand, (re)installing zn_poly afterwards (with just sage -i ...) should have just told you that it's already installed, which you at least did not explicitly mention.

(But you said you copied the .p11 into spkg/standard/ before building Sage 5.10.beta4.)

Yes, I copied .p11 into spkg/standard/ and removed .p10 before I started building Sage 5.10.beta4.

Sorry that I don't remember the reason of the failure of beta4. The message was somewhat unclear to me, but seemed unrelated with zn_poly. Now I am building beta4 to reproduce the failure.

I used "sage -i" rather than "sage -f", and remember the installation of the spkg started as if it was not done before. On this point, I am not so confident of my own memory though. Anyway, the installation was successful.

[kwankyu]

comment:56

Rebuilding beta4 now succeeded, but when I started the just-built Sage, I got

Athena:sage-5.10.beta4$ ./sage
----------------------------------------------------------------------
| Sage Version 5.10.beta4, Release Date: 2013-05-20                  |
| Type "notebook()" for the browser-based notebook interface.        |
| Type "help()" for help.                                            |
----------------------------------------------------------------------
**********************************************************************
*                                                                    *
* Warning: this is a prerelease version, and it may be unstable.     *
*                                                                    *
**********************************************************************
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-1-e91e614a7080> in <module>()
      2 sys.path.append(os.environ['HOME'] + '/Workplace/sage')
      3 
----> 4 from lib import *

/Users/Kwankyu/Workplace/sage/lib/__init__.py in <module>()
----> 1 from curve.simple_curve import SimpleCurve

/Users/Kwankyu/Workplace/sage/lib/curve/simple_curve.py in <module>()
     22 from sage.matrix.constructor import matrix, vector
     23 
---> 24 from lib.curve import affine_curve
     25 from affine_curve import AffinePlaneCurve, CoordinateRing
     26 

/Users/Kwankyu/Workplace/sage/lib/curve/affine_curve.py in <module>()
      9 from sage.categories.morphism import Morphism
     10 from sage.categories.finite_fields import FiniteFields
---> 11 from sage.schemes.generic.projective_space import ProjectiveSpace
     12 from sage.rings.fraction_field import FractionField
     13 from sage.rings.infinity import infinity

ImportError: No module named projective_space
sage: 

Still "./sage -f spkg/standard/zn_poly-0.9.p11.spkg" succeeds.

[nexttime]

comment:57

Replying to @kwankyu:

Rebuilding beta4 now succeeded, but when I started the just-built Sage, I got

Athena:sage-5.10.beta4$ ./sage
----------------------------------------------------------------------
| Sage Version 5.10.beta4, Release Date: 2013-05-20                  |
| Type "notebook()" for the browser-based notebook interface.        |
| Type "help()" for help.                                            |
----------------------------------------------------------------------
**********************************************************************
*                                                                    *
* Warning: this is a prerelease version, and it may be unstable.     *
*                                                                    *
**********************************************************************
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-1-e91e614a7080> in <module>()
      2 sys.path.append(os.environ['HOME'] + '/Workplace/sage')
      3 
----> 4 from lib import *

/Users/Kwankyu/Workplace/sage/lib/__init__.py in <module>()
----> 1 from curve.simple_curve import SimpleCurve

/Users/Kwankyu/Workplace/sage/lib/curve/simple_curve.py in <module>()
     22 from sage.matrix.constructor import matrix, vector
     23 
---> 24 from lib.curve import affine_curve
     25 from affine_curve import AffinePlaneCurve, CoordinateRing
     26 

/Users/Kwankyu/Workplace/sage/lib/curve/affine_curve.py in <module>()
      9 from sage.categories.morphism import Morphism
     10 from sage.categories.finite_fields import FiniteFields
---> 11 from sage.schemes.generic.projective_space import ProjectiveSpace
     12 from sage.rings.fraction_field import FractionField
     13 from sage.rings.infinity import infinity

ImportError: No module named projective_space
sage: 

This is both unrelated to zn_poly and hardly related to Sage 5.10.beta4.

Outdated init.sage? Cf. #14217, merged into Sage 5.10.beta3.

[nexttime]

comment:58

Replying to @nexttime:

Replying to @kwankyu:

---> 11 from sage.schemes.generic.projective_space import ProjectiveSpace

ImportError: No module named projective_space

This is both unrelated to zn_poly and hardly related to Sage 5.10.beta4.

Outdated init.sage? Cf. #14217, merged into Sage 5.10.beta3.

P.S.: The relevant "layout" change was announced (or suggested) on sage-devel a while ago.

[jdemeyer]

comment:59

At least this spkg fixes some bug, so it's good to have.

[jdemeyer]

Merged: sage-5.10.beta5

[jdemeyer]

Reviewer: Jeroen Demeyer

[kcrisman]

comment:60

At least this spkg fixes some bug, so it's good to have.

True! But did you open a new ticket for the original bug, which is probably not resolved by this? (JP, I assume that on a loaded Cygwin system we still get the original issue.)

[kwankyu]

comment:61

I successfully installed Sage-5.10.rc0 without the zn_poly failure issue. (the error after starting Sage as reported in a previous comment was just because of my own out-dated scripts, and is irrelevant with this ticket. Sorry for the noise.)

Thanks a lot!