This looks new. Is it reproducible? Could you please file a JIRA for it to track properly?
On Tue, Jan 26, 2016 at 6:26 PM, tommy xiao <[email protected]> wrote: > try master branch, make check on macos 10.11.2 > > [ RUN ] SubcommandTest.Dispatch > > Subcommand 'subcommand' is not available > > Usage: command <subcommand> [OPTIONS] > > > Available subcommands: > > help > > subcommand2 > > > Multiple subcommands have name 'subcommand' > > [ OK ] SubcommandTest.Dispatch (0 ms) > > [----------] 2 tests from SubcommandTest (1 ms total) > > > [----------] 2 tests from SVNTest > > [ RUN ] SVNTest.DiffPatch > > *** Aborted at 1453828980 (unix time) try "date -d @1453828980" if you are > using GNU date *** > > PC: @ 0x10838b219 apr_pool_create_ex > > *** SIGSEGV (@0x30) received by PID 734 (TID 0x7fff79de2000) stack trace: > *** > > @ 0x7fff897afeaa _sigtramp > > @ 0x7fff650d7492 (unknown) > > @ 0x10820f22d svn_pool_create_ex > > @ 0x107910bde svn::diff() > > @ 0x10790f4a9 SVNTest_DiffPatch_Test::TestBody() > > @ 0x107988223 > testing::internal::HandleSehExceptionsInMethodIfSupported<>() > > @ 0x10796c377 > testing::internal::HandleExceptionsInMethodIfSupported<>() > > @ 0x10792c2e5 testing::Test::Run() > > @ 0x10792d82b testing::TestInfo::Run() > > @ 0x10792e4c7 testing::TestCase::Run() > > @ 0x10793cca3 testing::internal::UnitTestImpl::RunAllTests() > > @ 0x10798b2c3 > testing::internal::HandleSehExceptionsInMethodIfSupported<>() > > @ 0x10796e9b7 > testing::internal::HandleExceptionsInMethodIfSupported<>() > > @ 0x10793c8a0 testing::UnitTest::Run() > > @ 0x107789da1 RUN_ALL_TESTS() > > @ 0x107789d80 main > > @ 0x7fff9c14c5ad start > > @ 0x1 (unknown) > > make[7]: *** [check-local] Segmentation fault: 11 > > make[6]: *** [check-am] Error 2 > > make[5]: *** [check-recursive] Error 1 > > make[4]: *** [check] Error 2 > > make[3]: *** [check-recursive] Error 1 > > make[2]: *** [check-recursive] Error 1 > > make[1]: *** [check] Error 2 > > make: *** [check-recursive] Error 1 > > > > 2016-01-26 7:38 GMT+08:00 Timothy Chen <[email protected]>: > > > We're creating a release from latest master this as soon as the > > remaining two blockers are resolved, current estimate should be > > tomorrow. > > > > Please go ahead and try out the latest master if you can. > > > > Thanks! > > > > Tim > > > > On Mon, Jan 25, 2016 at 11:53 AM, Sarjeet Singh > > <[email protected]> wrote: > > > Thanks Bernd for confirming. This should fix this issue in Mesos 0.27. > > > > > > Any update on when this is planned to be released? > > > > > > -Sarjeet > > > > > > On Mon, Jan 25, 2016 at 10:40 AM, Bernd Mathiske <[email protected]> > > > wrote: > > > > > >> Hi Sarjeet, > > >> > > >> I hope we fixed this in upcoming 0.27: > > >> > > >> https://issues.apache.org/jira/browse/MESOS-4304 > > >> > > >> Bernd > > >> > > >> On Jan 25, 2016, at 7:30 PM, Sarjeet Singh <[email protected] > > > > >> wrote: > > >> > > >> I ran into an issue when tried Mesos 0.26 version and started a > marathon > > >> app using URI (with maprfs path) on a mesos cluster. > > >> > > >> The issue seems to be caused by Mesos-3602 fix, and is causing issue > for > > >> maprfs (mapr filesystem) when specified maprfs path as URI on > marathon. > > >> > > >> The issue is that, It is appending '/' to the URI maprfs path > > specified, in > > >> the beginning, and is not executed as expected. e.g. > > >> > > >> ===== > > >> * hadoop fs -copyToLocal '/ > > >> maprfs:///dist/hadoop-2.7.0.myriad1.tar.gz' > > >> > > >> > > > '/opt/mapr/slaves/67d1f64c-449b-4609-82f3-5da309f3c5c5-S9/frameworks/67d1f64c-449b-4609-82f3-5da309f3c5c5-0000/executors/myriad1.63bbb98c-c072-11e5-b686-0cc47a587d20/runs/427fe309-82c5-4f8b-9fa3-6dd39a4a5ef4/hadoop-2.7.0.myriad1.tar.gz* > > >> > > >> > > >> -copyToLocal: java.net.URISyntaxException: Expected scheme-specific > > part at > > >> index 7: maprfs: > > >> ===== > > >> > > >> The fix for Mesos-3602 only assumes hdfs path, and doesn't consider > > other > > >> cases, such as maprfs or other dfs paths. I haven't filed a JIRA yet > on > > >> this issue, but would like to get some feedback on this, and expect > > this to > > >> be fixed for next Mesos release. > > >> > > >> Let me know if there is anything else I could provide related to the > > issue. > > >> > > >> -Sarjeet > > >> > > >> On Sat, Jan 23, 2016 at 12:41 AM, Timothy Chen <[email protected]> > > wrote: > > >> > > >> Hi all, > > >> > > >> (Kapil, MPark and I) We're still having 3 blocker issues outstanding > > >> at this moment: > > >> > > >> MESOS-4449: SegFault on agent during executor startup (shepherd: > Joris) > > >> MESOS-4441: Do not allocate non-revocable resources beyond quota > > >> guarantee. (shepherd: Joris) > > >> MESOS-4410: Introduce protobuf for quota set request. (shepherd: > Joris) > > >> > > >> The remaining major tickets are ContainerLogger related and should be > > >> committed today according to Ben. > > >> > > >> We've started to test latest master and will be looking at the test > > >> failures to see what needs to be addressed. > > >> > > >> I encourage everyone to test the latest master on your platform if > > >> possible to catch issues early, and once the Blocker issues are > > >> resolved we'll be sending a RC to test and vote. > > >> > > >> Thanks, > > >> > > >> Tim > > >> > > >> > > >> > > > > > > -- > Deshi Xiao > Twitter: xds2000 > E-mail: xiaods(AT)gmail.com >
