[jira] [Assigned] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam B reassigned MESOS-2050:
-
Assignee: Adam B (was: Till Toenshoff)
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Assignee: Adam B
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104 03:37:55.532572 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 293974ns
I1104 03:37:55.532594 28381 replica.cpp:320] Persisted replica status to
VOTING
I1104 03:37:55.532790 28390 recover.cpp:568] Successfully joined the Paxos
group
I1104 03:37:55.533107 28390 recover.cpp:452] Recover process terminated
I1104 03:37:55.533604 28382 log.cpp:656] Attempting to start the writer
I1104 03:37:55.534840 28381 replica.cpp:474] Replica received implicit
promise request with proposal 1
I1104 03:37:55.535188 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 321021ns
I1104 03:37:55.535212 28381 replica.cpp:342] Persisted promised to 1
I1104 03:37:55.535893 28378 coordinator.cpp:230] Coordinator attemping to
fill missing position
I1104 03:37:55.537318 28392 replica.cpp:375] Replica received explicit
promise request for position 0 with proposal 2
I1104 03:37:55.537719 28392 leveldb.cpp:343] Persisting action (8 bytes) to
leveldb took 366858ns
I1104 03:37:55.537746
[jira] [Assigned] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff reassigned MESOS-2050:
-
Assignee: Till Toenshoff
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Assignee: Till Toenshoff
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104 03:37:55.532572 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 293974ns
I1104 03:37:55.532594 28381 replica.cpp:320] Persisted replica status to
VOTING
I1104 03:37:55.532790 28390 recover.cpp:568] Successfully joined the Paxos
group
I1104 03:37:55.533107 28390 recover.cpp:452] Recover process terminated
I1104 03:37:55.533604 28382 log.cpp:656] Attempting to start the writer
I1104 03:37:55.534840 28381 replica.cpp:474] Replica received implicit
promise request with proposal 1
I1104 03:37:55.535188 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 321021ns
I1104 03:37:55.535212 28381 replica.cpp:342] Persisted promised to 1
I1104 03:37:55.535893 28378 coordinator.cpp:230] Coordinator attemping to
fill missing position
I1104 03:37:55.537318 28392 replica.cpp:375] Replica received explicit
promise request for position 0 with proposal 2
I1104 03:37:55.537719 28392 leveldb.cpp:343] Persisting action (8 bytes) to
leveldb took 366858ns
I1104
