[
https://issues.apache.org/jira/browse/MESOS-8875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16473962#comment-16473962
]
Benjamin Bannier edited comment on MESOS-8875 at 5/14/18 9:35 AM:
------------------------------------------------------------------
A likely culprit here seems to be {{TestContainerizer}} which mutates the
shared and global process environment, long after e.g., other actors have
spawned.
{code}
// We need to save the original set of environment variables so we
// can reset the environment after calling 'driver->start()' below.
hashmap<string, string> original = os::environment();
foreachpair (const string& name, const string& variable, environment) {
os::setenv(name, variable);
}
// TODO(benh): Can this be removed and done exclusively in the
// 'executorEnvironment()' function? There are other places in the
// code where we do this as well and it's likely we can do this once
// in 'executorEnvironment()'.
foreach (const Environment::Variable& variable,
containerConfig.executor_info()
.command().environment().variables()) {
os::setenv(variable.name(), variable.value());
}
os::setenv("MESOS_LOCAL", "1");
const Owned<ExecutorData>& executorData =
executors.at(containerConfig.executor_info().executor_id());
if (executorData->executor != nullptr) {
executorData->driver = Owned<MesosExecutorDriver>(
new MesosExecutorDriver(executorData->executor));
executorData->driver->start();
} else {
shared_ptr<v1::MockHTTPExecutor> executor =
executorData->v1ExecutorMock;
executorData->v1Library = Owned<v1::executor::TestMesos>(
new v1::executor::TestMesos(ContentType::PROTOBUF, executor));
}
os::unsetenv("MESOS_LOCAL");
// Unset the environment variables we set by resetting them to their
// original values and also removing any that were not part of the
// original environment.
foreachpair (const string& name, const string& value, original) {
os::setenv(name, value);
}
foreachkey (const string& name, environment) {
if (!original.contains(name)) {
os::unsetenv(name);
}
}
{code}
Linking MESOS-3475 which should address this.
was (Author: bbannier):
A likely culprit here seems to be {{TestContainerizer}} which mutates the
shared and global process environment, long after e.g., other actors have
spawned.
{code}
// We need to save the original set of environment variables so we
// can reset the environment after calling 'driver->start()' below.
hashmap<string, string> original = os::environment();
foreachpair (const string& name, const string& variable, environment) {
os::setenv(name, variable);
}
// TODO(benh): Can this be removed and done exclusively in the
// 'executorEnvironment()' function? There are other places in the
// code where we do this as well and it's likely we can do this once
// in 'executorEnvironment()'.
foreach (const Environment::Variable& variable,
containerConfig.executor_info()
.command().environment().variables()) {
os::setenv(variable.name(), variable.value());
}
os::setenv("MESOS_LOCAL", "1");
const Owned<ExecutorData>& executorData =
executors.at(containerConfig.executor_info().executor_id());
if (executorData->executor != nullptr) {
executorData->driver = Owned<MesosExecutorDriver>(
new MesosExecutorDriver(executorData->executor));
executorData->driver->start();
} else {
shared_ptr<v1::MockHTTPExecutor> executor =
executorData->v1ExecutorMock;
executorData->v1Library = Owned<v1::executor::TestMesos>(
new v1::executor::TestMesos(ContentType::PROTOBUF, executor));
}
os::unsetenv("MESOS_LOCAL");
// Unset the environment variables we set by resetting them to their
// original values and also removing any that were not part of the
// original environment.
foreachpair (const string& name, const string& value, original) {
os::setenv(name, value);
}
foreachkey (const string& name, environment) {
if (!original.contains(name)) {
os::unsetenv(name);
}
}
{code}
> `leveldb::PosixEnv::DeleteFile()` can segfault.
> -----------------------------------------------
>
> Key: MESOS-8875
> URL: https://issues.apache.org/jira/browse/MESOS-8875
> Project: Mesos
> Issue Type: Bug
> Affects Versions: 1.6.0
> Reporter: Chun-Hung Hsiao
> Assignee: Benjamin Bannier
> Priority: Major
> Labels: flaky-test, mesosphere, storage
> Attachments: MasterAPITest_Subscribe_SSL_mesos-ec2-centos-7.txt,
> MasterAuthorizerTest_FilterStateEndpoint_CMake_mesos-ec2-centos-7.txt,
> MasterTest_UnacknowledgedTerminalTask_CMake_mesos-ec2-centos-7.txt,
> ReconciliationTest_ImplicitTerminalTask_CMake_mesos-ec2-centos-7.txt
>
>
> Patch https://reviews.apache.org/r/66310/ instantiate a {{LevelDBStorage}}
> for the registrar of the agent-side resource provider manager. This change
> seems to introduce flaky segfaults to various tests, including
> {{MasterAPITest.Subscribe}}, {{MasterTest.UnacknowledgedTerminalTask}},
> {{ReconciliationTest.ImplicitTerminalTask}} and
> {{MasterAuthorizerTest/1.FilterStateEndpoint}}. The segfault usually happens
> after successfully attached the virtual path of a launched default executor:
> {noformat}
> I0502 21:47:31.329772 4511 paths.cpp:745] Creating sandbox
> '/tmp/ContentType_MasterAPITest_Subscribe_1_HzYh4s/slaves/82b400f9-82ed-4fdc-9f34-8c652dc502a8-S0/frameworks/82b400f9-82ed-4fdc-9f34-8c652dc502a8-0000/executors/default/runs/398c5e60-5141-43f0-9856-98c05d501b33'
> for user 'root'
> I0502 21:47:31.330245 4511 slave.cpp:8964] Launching executor 'default' of
> framework 82b400f9-82ed-4fdc-9f34-8c652dc502a8-0000 with resources [] in work
> directory
> '/tmp/ContentType_MasterAPITest_Subscribe_1_HzYh4s/slaves/82b400f9-82ed-4fdc-9f34-8c652dc502a8-S0/frameworks/82b400f9-82ed-4fdc-9f34-8c652dc502a8-0000/executors/default/runs/398c5e60-5141-43f0-9856-98c05d501b33'
> I0502 21:47:31.330423 4511 slave.cpp:3044] Queued task
> '7e968920-a780-4265-9e4b-e56e091ff27e' for executor 'default' of framework
> 82b400f9-82ed-4fdc-9f34-8c652dc502a8-0000
> I0502 21:47:31.330549 4511 slave.cpp:3523] Launching container
> 398c5e60-5141-43f0-9856-98c05d501b33 for executor 'default' of framework
> 82b400f9-82ed-4fdc-9f34-8c652dc502a8-0000
> I0502 21:47:31.330747 4515 slave.cpp:1008] Successfully attached
> '/tmp/ContentType_MasterAPITest_Subscribe_1_HzYh4s/slaves/82b400f9-82ed-4fdc-9f34-8c652dc502a8-S0/frameworks/82b400f9-82ed-4fdc-9f34-8c652dc502a8-0000/executors/default/runs/398c5e60-5141-43f0-9856-98c05d501b33'
> to virtual path
> '/tmp/ContentType_MasterAPITest_Subscribe_1_HzYh4s/slaves/82b400f9-82ed-4fdc-9f34-8c652dc502a8-S0/frameworks/82b400f9-82ed-4fdc-9f34-8c652dc502a8-0000/executors/default/runs/latest'
> I0502 21:47:31.330814 4515 slave.cpp:1008] Successfully attached
> '/tmp/ContentType_MasterAPITest_Subscribe_1_HzYh4s/slaves/82b400f9-82ed-4fdc-9f34-8c652dc502a8-S0/frameworks/82b400f9-82ed-4fdc-9f34-8c652dc502a8-0000/executors/default/runs/398c5e60-5141-43f0-9856-98c05d501b33'
> to virtual path
> '/frameworks/82b400f9-82ed-4fdc-9f34-8c652dc502a8-0000/executors/default/runs/latest'
> I0502 21:47:31.331126 4511 slave.cpp:1008] Successfully attached
> '/tmp/ContentType_MasterAPITest_Subscribe_1_HzYh4s/slaves/82b400f9-82ed-4fdc-9f34-8c652dc502a8-S0/frameworks/82b400f9-82ed-4fdc-9f34-8c652dc502a8-0000/executors/default/runs/398c5e60-5141-43f0-9856-98c05d501b33'
> to virtual path
> '/tmp/ContentType_MasterAPITest_Subscribe_1_HzYh4s/slaves/82b400f9-82ed-4fdc-9f34-8c652dc502a8-S0/frameworks/82b400f9-82ed-4fdc-9f34-8c652dc502a8-0000/executors/default/runs/398c5e60-5141-43f0-9856-98c05d501b33'
> *** Aborted at 1525297651 (unix time) try "date -d @1525297651" if you are
> using GNU date ***
> I0502 21:47:31.331786 4515 executor.cpp:192] Version: 1.6.0
> W0502 21:47:31.331804 4515 process.cpp:2824] Attempted to spawn already
> running process [email protected]:37498
> I0502 21:47:31.332619 4515 executor.cpp:414] Connected with the agent
> I0502 21:47:31.332749 4515 executor.cpp:311] Sending SUBSCRIBE call to
> http://172.16.10.128:37498/slave(945)/api/v1/executor
> PC: @ 0x7f9239ecd0ed __GI_getenv
> *** SIGSEGV (@0x171) received by PID 13317 (TID 0x7f922de28700) from PID 369;
> stack trace: ***
> @ 0x7f922cca2155 (unknown)
> @ 0x7f922cca6e41 (unknown)
> @ 0x7f922cc9a678 (unknown)
> @ 0x7f923ae935e0 (unknown)
> @ 0x7f9239ecd0ed __GI_getenv
> @ 0x7f9239ec4d61 __dcigettext
> @ 0x7f9239f1ba9e __GI___strerror_r
> @ 0x7f9239f1b9df strerror
> @ 0x7f923dde4e23 leveldb::(anonymous namespace)::IOError()
> @ 0x7f923dde5832 leveldb::(anonymous
> namespace)::PosixEnv::DeleteFile()
> @ 0x7f923dde1628 leveldb::BuildTable()
> @ 0x7f923ddbd5b4 leveldb::DBImpl::WriteLevel0Table()
> @ 0x7f923ddbf6c8 leveldb::DBImpl::CompactMemTable()
> @ 0x7f923ddc0756 leveldb::DBImpl::BackgroundCompaction()
> @ 0x7f923ddc1172 leveldb::DBImpl::BackgroundCall()
> @ 0x7f923dde55cb leveldb::(anonymous
> namespace)::PosixEnv::BGThreadWrapper()
> @ 0x7f923ae8be25 start_thread
> @ 0x7f9239f8d34d __clone
> {noformat}
> leveldb maintains a global singleton of {{PosixEnv}}, whose {{DeleteFile()}}
> callback sometimes fails to unlink a {{ldb}} file, and it uses {{strerror()}}
> to report the error, which seems to call {{getenv}}, and this increase the
> likelihood of some setenv-getenv race described in
> https://issues.apache.org/jira/browse/MESOS-2407.
> It is worth investigating why {{DeleteFile()}} fails.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
