Build failed in Jenkins: FreeBSD_HEAD-tests2 #853
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/853/ -- [...truncated 400 lines...] lib/libc/gen/posix_spawn/spawn_test:t_spawn_zero - passed [0.016s] lib/libc/gen/posix_spawn/spawn_test:t_spawnp_ls - passed [0.015s] lib/libc/hash/sha2_test:t_sha256 - passed [0.015s] lib/libc/hash/sha2_test:t_sha384 - passed [0.014s] lib/libc/hash/sha2_test:t_sha512 - passed [0.014s] lib/libc/hash/hash_test:md5 - passed [0.576s] lib/libc/hash/hash_test:sha1 - passed [0.343s] lib/libc/inet/inet_network_test:inet_addr_basic - passed [0.015s] lib/libc/inet/inet_network_test:inet_addr_err - passed [0.015s] lib/libc/inet/inet_network_test:inet_network_basic - passed [0.014s] lib/libc/inet/inet_network_test:inet_network_err - passed [0.015s] lib/libc/net/getprotoent_test:endprotoent_rewind - passed [0.190s] lib/libc/net/getprotoent_test:getprotobyname_basic - passed [0.017s] lib/libc/net/getprotoent_test:getprotobyname_err - passed [0.016s] lib/libc/net/getprotoent_test:getprotobynumber_basic - passed [0.017s] lib/libc/net/getprotoent_test:getprotobynumber_err - passed [0.065s] lib/libc/net/getprotoent_test:getprotoent_next - passed [0.017s] lib/libc/net/getprotoent_test:setprotoent_rewind - passed [0.015s] lib/libc/net/ether_aton_test:tc_ether_aton - passed [0.014s] lib/libc/net/nsdispatch_test:recurse - passed [0.201s] lib/libc/net/protoent_test:protoent - passed [0.079s] lib/libc/net/servent_test:servent - passed [0.513s] lib/libc/regex/exhaust_test:regcomp_too_big - passed [0.629s] lib/libc/regex/regex_att_test:basic - passed [0.028s] lib/libc/regex/regex_att_test:categorization - passed [0.017s] lib/libc/regex/regex_att_test:forcedassoc - passed [0.018s] lib/libc/regex/regex_att_test:leftassoc - expected_failure: The expected and matched groups are mismatched on FreeBSD: 12 checks failed as expected; see output for more details [0.018s] lib/libc/regex/regex_att_test:nullsubexpr - passed [0.018s] lib/libc/regex/regex_att_test:repetition - passed [0.019s] lib/libc/regex/regex_att_test:rightassoc - passed [0.017s] lib/libc/regex/regex_test:anchor - passed [0.319s] lib/libc/regex/regex_test:backref - passed [0.189s] lib/libc/regex/regex_test:basic - passed [0.669s] lib/libc/regex/regex_test:bracket - passed [0.184s] lib/libc/regex/regex_test:c_comments - passed [0.169s] lib/libc/regex/regex_test:complex - passed [0.354s] lib/libc/regex/regex_test:error - passed [0.217s] lib/libc/regex/regex_test:meta - passed [0.148s] lib/libc/regex/regex_test:nospec - passed [0.145s] lib/libc/regex/regex_test:paren - passed [0.117s] lib/libc/regex/regex_test:regress - passed [0.125s] lib/libc/regex/regex_test:repet_bounded - passed [0.153s] lib/libc/regex/regex_test:repet_multi - passed [0.118s] lib/libc/regex/regex_test:repet_ordinary - passed [0.128s] lib/libc/regex/regex_test:startend - passed [0.114s] lib/libc/regex/regex_test:subexp - passed [0.165s] lib/libc/regex/regex_test:subtle - passed [0.138s] lib/libc/regex/regex_test:word_bound - passed [0.118s] lib/libc/regex/regex_test:zero - passed [0.114s] lib/libc/stdio/fmemopen2_test:test_append_binary_pos - passed [0.024s] lib/libc/stdio/fmemopen2_test:test_autoalloc - passed [0.016s] lib/libc/stdio/fmemopen2_test:test_binary - passed [0.014s] lib/libc/stdio/fmemopen2_test:test_data_length - passed [0.014s] lib/libc/stdio/fmemopen2_test:test_preexisting - passed [0.016s] lib/libc/stdio/fmemopen2_test:test_size_0 - passed [0.014s] lib/libc/stdio/clearerr_test:clearerr_basic - passed [0.017s] lib/libc/stdio/clearerr_test:clearerr_err - passed [0.016s] lib/libc/stdio/fflush_test:fflush_err - expected_failure: the EOF invariant fails on FreeBSD; this is new: /builds/FreeBSD_HEAD/contrib/netbsd-tests/lib/libc/stdio/t_fflush.c:70: Expected true value in fflush(f) == EOF [0.058s] lib/libc/stdio/fflush_test:fflush_seek - passed [0.018s] lib/libc/stdio/fflush_test:fpurge_err - passed [0.016s] lib/libc/stdio/fmemopen_test:test00 - passed [0.013s] lib/libc/stdio/fmemopen_test:test01 - passed [0.013s] lib/libc/stdio/fmemopen_test:test02 - passed [0.013s] lib/libc/stdio/fmemopen_test:test03 - passed [0.013s] lib/libc/stdio/fmemopen_test:test04 - passed [0.013s] lib/libc/stdio/fmemopen_test:test05 - passed [0.013s] lib/libc/stdio/fmemopen_test:test06 - passed [0.013s] lib/libc/stdio/fmemopen_test:test07 - passed [0.013s] lib/libc/stdio/fmemopen_test:test08 - passed [0.013s] lib/libc/stdio/fmemopen_test:test09 - passed [0.090s] lib/libc/stdio/fmemopen_test:test10 - passed [0.018s] lib/libc/stdio/fmemopen_test:test11 - passed [0.017s] lib/libc/stdio/fmemopen_test:test13 - passed [0.015s] lib/libc/stdio/fmemopen_test:test14 - passed [0.014s] lib/libc/stdio/fopen_test:fdopen_close - passed [0.019s]
Re: [PATCH] Convert the VFS cache lock to an rmlock
On Fri, Mar 13, 2015 at 11:23:06AM -0400, Ryan Stone wrote: On Thu, Mar 12, 2015 at 1:36 PM, Mateusz Guzik mjgu...@gmail.com wrote: Workloads like buildworld and the like (i.e. a lot of forks + execs) run into very severe contention in vm, which is orders of magnitude bigger than anything else. As such your result seems quite suspicious. You're right, I did mess up the testing somewhere (I have no idea how). As you suggested, I switched to using a separate partition for the objdir, and ran each build with a freshly newfsed filesystem. I scripted it to be sure that I was following the same procedure with each run: [..] The difference is due to a significant increase in system time. Write locks on an rmlock are extremely expensive (they involve an smp_rendezvous), and the cost likely scales with the number of cores: x 32core/orig.log + 32core/rmlock.log +--+ |xxx x + +++ +| ||_MA__| |MA__|| +--+ N Min MaxMedian AvgStddev x 5 5616.635715.75641.5 5661.72 48.511545 + 5 6502.51 6781.846596.5 6612.39 103.06568 Difference at 95.0% confidence 950.67 +/- 117.474 16.7912% +/- 2.07489% (Student's t, pooled s = 80.5478) At this point I'm pretty much at an impasse. The real-time behaviour is critical to me, but a 5% performance degradation isn't likely to be acceptable to many people. I'll see what I can do with this. Well, you can see that the entire cache is protected by one lock. It also has other shortcomings which basically ask for a complete rewrite, so I would say spending significant amount of time on it is not worth discouraged. Brief look suggests that while just protecting each hash bucket by a separate lock may require a lot of work, it should be quite doable to do it with an additional lock which makes deletions exclusive, while insertions and lookups take the same lock shared and then lock specific buckets. Also cache_purge could be micro-optimized to not take the lock if we did not have any entries for given vnode (and we don't in a lot of cases). With this in place I would not be surprised if the thing was faster even with rmlock, which would justify it until the cache is rewritten. -- Mateusz Guzik mjguzik gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sbuf-related panic
On Tue, 2015-03-17 at 12:14 -0700, Craig Rodrigues wrote: On Tue, Mar 17, 2015 at 11:57 AM, Ian Lepore i...@freebsd.org wrote: There is still a panic, one that I can't yet figure out why it wasn't panicking before my changes, but I'm working on it. Can you run the kyua tests on your system? https://wiki.freebsd.org/201411DevAndVendorSummit?action=AttachFiledo=viewtarget=kyua_jenkins.pdf Those tests seem to be reproducibly triggering the problem. Triggering it wasn't the problem, understanding why it didn't used to fail and now it does was the tricky bit. :) It turns out it never failed before because nobody had tried to use default allocations (pointer and size zero) with sbuf_new_for_sysctl() before, and it didn't fail for me while I was testing my changes because I had commented-out INVARIANTS in my kernel config and forgotten that (doh!) so none of the assertions were actually being tested. So I fixed my test environment, then I fixed the code. Hopefully it's all better now. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sbuf-related panic
On Tue, Mar 17, 2015 at 5:08 PM, Ian Lepore i...@freebsd.org wrote: I had commented-out INVARIANTS in my kernel config and forgotten that (doh!) so none of the assertions were actually being tested. FYI: there is now a GENERIC-NODEBUG kernel config checked into head so you can just buildkernel/installkernel with KERNCONF=GENERIC-NODEBUG when you want to run without invariants/witness/etc. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sbuf-related panic
On Tue, Mar 17, 2015 at 11:49 AM, Mark Felder f...@freebsd.org wrote: On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: On amd64, doing a Poudriere run. On r280133: I appeared to be hitting this on 280130, the most recent CURRENT snapshot. I'm going to build the latest since some sbuf fixes have landed and see if I can finish a poudriere build run. The Jenkins build which boots a VM and runs the kyua tests is kernel panicking in sbuf as well: https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/853/console You might want to see if that build passes before updating. -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sbuf-related panic
On Tue, 2015-03-17 at 13:49 -0500, Mark Felder wrote: On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: On amd64, doing a Poudriere run. On r280133: I appeared to be hitting this on 280130, the most recent CURRENT snapshot. I'm going to build the latest since some sbuf fixes have landed and see if I can finish a poudriere build run. There is still a panic, one that I can't yet figure out why it wasn't panicking before my changes, but I'm working on it. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Build failed in Jenkins: FreeBSD_HEAD-tests2 #853
On Mar 17, 2015, at 1:46, jenkins-ad...@freebsd.org wrote: See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/853/ … lib/libc/sys/clock_gettime_test:clock_gettime_real - panic: wrote past end of sbuf (0 = 0) cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe009748b760 vpanic() at vpanic+0x189/frame 0xfe009748b7e0 kassert_panic() at kassert_panic+0x132/frame 0xfe009748b850 sbuf_set_drain() at sbuf_set_drain+0x28/frame 0xfe009748b880 sbuf_new_for_sysctl() at sbuf_new_for_sysctl+0x29/frame 0xfe009748b8a0 sysctl_kern_timecounter_choice() at sysctl_kern_timecounter_choice+0x18/frame 0xfe009748b900 sysctl_root_handler_locked() at sysctl_root_handler_locked+0x94/frame 0xfe009748b940 sysctl_root() at sysctl_root+0x188/frame 0xfe009748b990 userland_sysctl() at userland_sysctl+0x192/frame 0xfe009748ba30 sys___sysctl() at sys___sysctl+0x74/frame 0xfe009748bae0 amd64_syscall() at amd64_syscall+0x27f/frame 0xfe009748bbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe009748bbf0 --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x800b77b0a, rsp = 0x7fffa938, rbp = 0x7fffa970 --- KDB: enter: panic [ thread pid 4557 tid 100062 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why db Slave went offline during the build ERROR: Connection was broken: java.io.IOException: Unexpected reader termination at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:76) Caused by: java.lang.OutOfMemoryError: PermGen space at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2585) at java.lang.Class.getConstructor0(Class.java:2885) at java.lang.Class.newInstance(Class.java:350) at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:399) at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:396) at java.security.AccessController.doPrivileged(Native Method) at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:395) at sun.reflect.MethodAccessorGenerator.generateSerializationConstructor(MethodAccessorGenerator.java:113) at sun.reflect.ReflectionFactory.newConstructorForSerialization(ReflectionFactory.java:331) at java.io.ObjectStreamClass.getSerializableConstructor(ObjectStreamClass.java:1376) at java.io.ObjectStreamClass.access$1500(ObjectStreamClass.java:72) at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:493) at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:468) at java.security.AccessController.doPrivileged(Native Method) at java.io.ObjectStreamClass.init(ObjectStreamClass.java:468) at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:365) at java.io.ObjectStreamClass.initProxy(ObjectStreamClass.java:562) at java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1575) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1514) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) at hudson.remoting.Command.readFrom(Command.java:92) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) Build step 'Execute shell' marked build as failure ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: no workspace for FreeBSD_HEAD-tests2 #853 at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:72) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:761) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:721) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:670) at hudson.model.Run.execute(Run.java:1742) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at
Re: sbuf-related panic
On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: On amd64, doing a Poudriere run. On r280133: I appeared to be hitting this on 280130, the most recent CURRENT snapshot. I'm going to build the latest since some sbuf fixes have landed and see if I can finish a poudriere build run. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sbuf-related panic
On Tue, Mar 17, 2015 at 11:57 AM, Ian Lepore i...@freebsd.org wrote: There is still a panic, one that I can't yet figure out why it wasn't panicking before my changes, but I'm working on it. Can you run the kyua tests on your system? https://wiki.freebsd.org/201411DevAndVendorSummit?action=AttachFiledo=viewtarget=kyua_jenkins.pdf Those tests seem to be reproducibly triggering the problem. -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sbuf-related panic
On Tue, 2015-03-17 at 14:14 -0500, Mark Felder wrote: On Tue, Mar 17, 2015, at 13:57, Ian Lepore wrote: On Tue, 2015-03-17 at 13:49 -0500, Mark Felder wrote: On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: On amd64, doing a Poudriere run. On r280133: I appeared to be hitting this on 280130, the most recent CURRENT snapshot. I'm going to build the latest since some sbuf fixes have landed and see if I can finish a poudriere build run. There is still a panic, one that I can't yet figure out why it wasn't panicking before my changes, but I'm working on it. Is the previous snapshot -- r279813 -- old enough to have missed the related changes? I'm just trying to get a machine up from 10.1-RELEASE to relatively CURRENT quickly. That should be safe, my series of sbuf changes that broke things started at r279992. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Adding the -O option to pax(1)
Hi folks, Can I get some feedback on Bug 198481 which adds the -O option to pax(1). https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198481 Regards Sevan / Venture37 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sbuf-related panic
On Tue, Mar 17, 2015, at 13:57, Ian Lepore wrote: On Tue, 2015-03-17 at 13:49 -0500, Mark Felder wrote: On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: On amd64, doing a Poudriere run. On r280133: I appeared to be hitting this on 280130, the most recent CURRENT snapshot. I'm going to build the latest since some sbuf fixes have landed and see if I can finish a poudriere build run. There is still a panic, one that I can't yet figure out why it wasn't panicking before my changes, but I'm working on it. Is the previous snapshot -- r279813 -- old enough to have missed the related changes? I'm just trying to get a machine up from 10.1-RELEASE to relatively CURRENT quickly. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
