That's a great point, thanks for the catch, Joris! Should have been obvious to me. I don't know the requirements of cgroups but running it on a VM isn't ideal, especially for heavily instrumented tests.
I'm on the road right now and don't have access to extra hardware. Is it reasonable to develop on a VM at all? I'm using Parallels but could rebuild on VirtualBox if that's more desirable. best, Brian > On May 5, 2015, at 6:44 AM, Joris Van Remoortere <jo...@mesosphere.io > <mailto:jo...@mesosphere.io>> wrote: > > If you do have perf installed, are you running on a VM that is not exposing > the `cycles` and `task-clock` events? > > On Thu, Apr 30, 2015 at 2:11 PM, Benjamin Mahler <benjamin.mah...@gmail.com > <mailto:benjamin.mah...@gmail.com>> wrote: > This message can be a bit misleading, do you have perf installed? > > On Thu, Apr 30, 2015 at 11:18 AM, Brian Topping <brian.topp...@gmail.com > <mailto:brian.topp...@gmail.com>> wrote: > Getting closer. After finding > http://garyzhu.net/notes/CentOS7-Systemd-Mesos-Marathon.html > <http://garyzhu.net/notes/CentOS7-Systemd-Mesos-Marathon.html>, I set up > another new CentOS 7 machine, got a lot further on the compile this time, > symbols too! This is with 0.22.1-RC6, CentOS Linux release 7.1.1503, kernel > 3.10.0-229.1.2.el7.x86_64. > > Output from the last test during a "make check". > >> [----------] 1 test from PerfEventIsolatorTest >> [ RUN ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample >> F0430 14:03:34.169455 13504 isolator_tests.cpp:710] CHECK_SOME(isolator): >> Failed to create PerfEvent isolator, invalid events: { cycles, task-clock } >> *** Check failure stack trace: *** >> @ 0x7f4c7ecea4ca google::LogMessage::Fail() >> @ 0x7f4c7ecea429 google::LogMessage::SendToLog() >> @ 0x7f4c7ece9e3a google::LogMessage::Flush() >> @ 0x7f4c7ececb6e google::LogMessageFatal::~LogMessageFatal() >> @ 0xa265b2 _CheckFatal::~_CheckFatal() >> @ 0xc93e88 >> mesos::internal::tests::PerfEventIsolatorTest_ROOT_CGROUPS_Sample_Test::TestBody() >> @ 0x1135c4f >> testing::internal::HandleSehExceptionsInMethodIfSupported<>() >> @ 0x1130e0a >> testing::internal::HandleExceptionsInMethodIfSupported<>() >> @ 0x1119233 testing::Test::Run() >> @ 0x1119956 testing::TestInfo::Run() >> @ 0x1119ede testing::TestCase::Run() >> @ 0x111ec5a testing::internal::UnitTestImpl::RunAllTests() >> @ 0x1136ac1 >> testing::internal::HandleSehExceptionsInMethodIfSupported<>() >> @ 0x1131afb >> testing::internal::HandleExceptionsInMethodIfSupported<>() >> @ 0x111db0a testing::UnitTest::Run() >> @ 0xd28155 main >> @ 0x7f4c7a741af5 __libc_start_main >> @ 0x8fae89 (unknown) > > Full results and machine configuration at > https://gist.github.com/briantopping/ac4f320bcc24e14328cd > <https://gist.github.com/briantopping/ac4f320bcc24e14328cd>. > > Not sure where to go with this, any insight appreciated! > > >> On Apr 30, 2015, at 11:33 PM, Brian Topping <brian.topp...@gmail.com >> <mailto:brian.topp...@gmail.com>> wrote: >> >> Also, I just checked this in the 0.22.1-RC6 and had the same problem. >> >>> On Apr 30, 2015, at 9:27 PM, Brian Topping <brian.topp...@gmail.com >>> <mailto:brian.topp...@gmail.com>> wrote: >>> >>> Greetings all, I'm having a problem with my first attempts building Mesos. >>> I started the other day with CentOS 7 and quickly realized it was far >>> better to be using 6.6. I've created a machine, but it's crashing in 'make >>> check'. >>> >>> Till Toenshoff was kind enough to give me some leads in JIRA on what to do >>> next, but it didn't change stack trace to include symbols. >>> >>> https://gist.github.com/briantopping/51197bad452dd3b3277c >>> <https://gist.github.com/briantopping/51197bad452dd3b3277c> has the dump of >>> what I've done, the first file shows everything done in an empty build >>> directory and the crash at the end. The second file there is a dump of the >>> machine configuration -- the uname output, /proc/cpuinfo and all the >>> installed RPM packages. >>> >>> I guess the first question is why didn't the "../configure --enable-debug" >>> work to generate the proper symbolics on the stack trace generated? Anyone >>> have suggestions on what I can try? >>> >>> Cheers, Brian >> > > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
