On Sat, Apr 17, 2010 at 18:02, B Smith-Mannschott <bsmith.o...@gmail.com> wrote:
> On Sat, Apr 17, 2010 at 15:45, B Smith-Mannschott <bsmith.o...@gmail.com>
> wrote:
>> More oddness:
>>
>> If I remove all unit tests *except* test-compex-numbers, all is well:
>>
>> [INFO] [clojure:test {execution: test-clojure}]
>>
>> Testing clojure.contrib.test-complex-numbers
>>
>> Ran 8 tests containing 268 assertions.
>> 0 failures, 0 errors.
>
> Actually, that's not true. The unit tests *usually* run
> without error, but sometimes crash with a NPE in LazySeq.sval.
>
> Here's a script I'm using:
>
> [[file: .git/this-build-fails]]
> #!/bin/bash
> log=".git/$(date +%F%H%M%S)-$(git log --oneline|head -n 1|cut -d' ' -f1).log"
> (
> mvn clean
> mvn test
> ) > $log 2>&1
> if grep -q ERROR < $log
> then
> echo "build had ERROR: $log"
> exit 0
> else
> echo "build was OK"
> rm "$log"
> exit 1
> fi
>
> Here's what I told my shell to do, and the resulting output
>
> smit...@pepper:~/w/clojure-contrib$ while true ; do .git/this-build-fails ;
> done
> build was OK
> build had ERROR: .git/2010-04-17172643-2bc0dcc.log
> build had ERROR: .git/2010-04-17172745-2bc0dcc.log
> build was OK
> build was OK
> build was OK
> build was OK
> build had ERROR: .git/2010-04-17173302-2bc0dcc.log
> build was OK
> build had ERROR: .git/2010-04-17173510-2bc0dcc.log
> build was OK
> build was OK
> build was OK
> build was OK
> build had ERROR: .git/2010-04-17174026-2bc0dcc.log
> build was OK
> build was OK
> build was OK
> build was OK
> build was OK
> build was OK
> build was OK
> build was OK
> build was OK
>
> The referenced commit 2bc0dcc is one where I've removed all unit
> tests, save for test_complex_numbers.clj
>
> smit...@pepper:~/w/clojure-contrib$ tree src/test/
> src/test/
> `-- clojure
> `-- clojure
> `-- contrib
> `-- test_complex_numbers.clj
>
> The interesting part of the five log files written above always looks
> this same: a NullPointerException in LazySeq.sval
I'm now seeing unreliable builds of this configuration even on my
MacBook (configuration "M"eheadable in the first mail on this thread)
which leads me to believe that whatever problem I'm seeing here, it's
more widespread than just my two netbooks.
10 of 28 builds failed on the MacBook. All failures produced the same
stack trace (though this one is somewhat different than what I saw on
my netbook, described in the previous mail.)
Testing clojure.contrib.test-complex-numbers
Exception in thread "main" java.lang.RuntimeException:
java.lang.NullPointerException (run-test1151698185522980091.clj:0)
at clojure.lang.Compiler.eval(Compiler.java:5389)
at clojure.lang.Compiler.load(Compiler.java:5784)
at clojure.lang.Compiler.loadFile(Compiler.java:5747)
at clojure.main$load_script__6226.invoke(main.clj:213)
at clojure.main$script_opt__6255.invoke(main.clj:265)
at clojure.main$main__6273.doInvoke(main.clj:346)
at clojure.lang.RestFn.invoke(RestFn.java:409)
at clojure.lang.Var.invoke(Var.java:365)
at clojure.lang.AFn.applyToHelper(AFn.java:165)
at clojure.lang.Var.applyTo(Var.java:482)
at clojure.main.main(main.java:37)
Caused by: java.lang.RuntimeException: java.lang.NullPointerException
at clojure.lang.LazySeq.sval(LazySeq.java:47)
at clojure.lang.LazySeq.seq(LazySeq.java:56)
at clojure.lang.Cons.next(Cons.java:37)
at clojure.lang.RT.boundedLength(RT.java:1162)
at clojure.lang.RestFn.applyTo(RestFn.java:131)
at clojure.core$apply__3643.invoke(core.clj:480)
at clojure.test$run_tests__6820.doInvoke(test.clj:691)
at clojure.lang.RestFn.invoke(RestFn.java:409)
at user$eval__1507$fn__1510.invoke(run-test1151698185522980091.clj:9)
at user$eval__1507.invoke(run-test1151698185522980091.clj:7)
at clojure.lang.Compiler.eval(Compiler.java:5373)
... 10 more
Caused by: java.lang.NullPointerException
at
clojure.core.protocols$fn__6000$G__5996__6004.invoke(protocols.clj:11)
at clojure.core$reduce__6111.invoke(core.clj:4719)
at clojure.test$join_fixtures__6796.invoke(test.clj:629)
at clojure.test$test_all_vars__6803.invoke(test.clj:653)
at clojure.test$test_ns__6817.invoke(test.clj:677)
at clojure.core$map__4086$fn__4087.invoke(core.clj:1870)
at clojure.lang.LazySeq.sval(LazySeq.java:42)
... 20 more
I notice that clojure.core.protocols makes a showing here, which is
consistent with the first message in this thread. I also know that
protocols are still under development. Judging from the randomness of
the observed brokenness I'd wager that there's a race condition of
some sort buried in protocols or in the abstractions it builds upon.
any better guesses?
// Ben
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
