You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Till Toenshoff (JIRA)" <ji...@apache.org> on 2015/04/03 13:49:52 UTC
[jira] [Comment Edited] (MESOS-2584)
AuthenticationTest.RetryFrameworkAuthentication breaks with clang-3.4.2
[ https://issues.apache.org/jira/browse/MESOS-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14392893#comment-14392893 ]
Till Toenshoff edited comment on MESOS-2584 at 4/3/15 11:49 AM:
----------------------------------------------------------------
This is where it fails:
{noformat}
frame #4: 0x00000001002e9178 mesos-tests`operator(this=0x0000000108e05118, process=0x0000000108f0a5a8) + 264 at dispatch.hpp:77
74 [=] (ProcessBase* process) {
75 assert(process != NULL);
76 T* t = dynamic_cast<T*>(process);
-> 77 assert(t != NULL);
78 (t->*method)();
79 }));
(const process::(anonymous class) *) this = 0x0000000108e05118
(mesos::internal::cram_md5::CRAMMD5AuthenticateeProcess *) process = 0x0000000108f0a450
(mesos::internal::cram_md5::CRAMMD5AuthenticateeProcess *) t = 0x0000000000000000
{noformat}
So apparently the process is not NULL but also not dynamic-castable towards T.
After excluding all AuthenticationTests in another run, I noticed that also other tests are failing; e.g. MesosContainerizerIsolatorPreparation*, CpuIsolatorTest/0.UserCpuUsage, a.s.o... The latter are also not in any way using authentication, hence I am convinced that we hit a libprocess clang 3.4 regression issue here. When going back in the commit history it shows that this problem already existed in our codebase in October 2014. I am still bisecting, trying to find a commit that does actually not show this bug.
was (Author: tillt):
This is where it fails:
{noformat}
frame #4: 0x00000001002fe6c8 mesos-tests`operator(this=0x00000001093485c8, process=0x00000001093591a8) + 264 at dispatch.hpp:77
74 [=] (ProcessBase* process) {
75 assert(process != NULL);
76 T* t = dynamic_cast<T*>(process);
-> 77 assert(t != NULL);
78 (t->*method)();
79 }));
{noformat}
So apparently the process is not NULL but also not dynamic-castable towards T.
After excluding all AuthenticationTests in another run, I noticed that also other tests are failing; e.g. MesosContainerizerIsolatorPreparation*, CpuIsolatorTest/0.UserCpuUsage, a.s.o... The latter are also not in any way using authentication, hence I am convinced that we hit a libprocess clang 3.4 regression issue here. When going back in the commit history it shows that this problem already existed in our codebase in October 2014. I am still bisecting, trying to find a commit that does actually not show this bug.
> AuthenticationTest.RetryFrameworkAuthentication breaks with clang-3.4.2
> -----------------------------------------------------------------------
>
> Key: MESOS-2584
> URL: https://issues.apache.org/jira/browse/MESOS-2584
> Project: Mesos
> Issue Type: Bug
> Components: test
> Affects Versions: 0.22.0
> Environment: OS X 10.10.2 with clang-3.4.2
> Reporter: Michael Park
> Assignee: Till Toenshoff
>
> When built with {{clang-3.4.2}}, {{make check}} dies with the following error message.
> {code}
> [ RUN ] AuthenticationTest.RetryFrameworkAuthentication
> Assertion failed: (t != NULL), function operator(), file ../../../3rdparty/libprocess/include/process/c++11/dispatch.hpp, line 77.
> *** Aborted at 1427879902 (unix time) try "date -d @1427879902" if you are using GNU date ***
> PC: @ 0x7fff92600286 __pthread_kill
> *** SIGABRT (@0x7fff92600286) received by PID 5475 (TID 0x10d329000) stack trace: ***
> @ 0x7fff8d56ff1a _sigtramp
> @ 0x10d328020 (unknown)
> @ 0x7fff8e7acb53 abort
> @ 0x7fff8e774c39 __assert_rtn
> @ 0x103d941c8 _ZZN7process8dispatchIN5mesos8internal8cram_md527CRAMMD5AuthenticateeProcessEEEvRKNS_3PIDIT_EEMS6_FvvEENKUlPNS_11ProcessBaseEE_clESD_
> @ 0x103d9401f _ZNSt3__110__function6__funcIZN7process8dispatchIN5mesos8internal8cram_md527CRAMMD5AuthenticateeProcessEEEvRKNS2_3PIDIT_EEMS9_FvvEEUlPNS2_11ProcessBaseEE_NS_9allocatorISH_EEFvSG_EEclEOSG_
> @ 0x10817856b std::__1::function<>::operator()()
> @ 0x10815fd7f process::ProcessBase::visit()
> @ 0x1081ea0ae process::DispatchEvent::visit()
> @ 0x1067f7051 process::ProcessBase::serve()
> @ 0x1081495be process::ProcessManager::resume()
> @ 0x108148cee process::schedule()
> @ 0x7fff9951b268 _pthread_body
> @ 0x7fff9951b1e5 _pthread_start
> @ 0x7fff9951941d thread_start
> make[3]: *** [check-local] Abort trap: 6
> make[2]: *** [check-am] Error 2
> make[1]: *** [check] Error 2
> make: *** [check-recursive] Error 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)