[jira] [Commented] (PROTON-2122) Hardcoded limit of 16 sasl mechanisms is insufficient on macOS

2019-10-20 Thread Roddie Kieley (Jira)


[ 
https://issues.apache.org/jira/browse/PROTON-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955707#comment-16955707
 ] 

Roddie Kieley commented on PROTON-2122:
---

[~jdanek] Hadn't seen this comment but realized same here in testing. I also 
changed the [magic 
16|https://github.com/apache/qpid-proton/blob/0.29.0/c/src/sasl/sasl.c#L475] to 
be a magic 32 here as on this version of macOS, 10.14, it was listing 24 values 
for 12 in duplicate:
{quote}
SRP SRP GS2-IAKERB GS2-KRB5 SCRAM-SHA-1 SCRAM-SHA-256 SCRAM-SHA-256 SCRAM-SHA-1 
GS2-KRB5 GS2-IAKERB GSS-SPNEGO GSSAPI GSS-SPNEGO GSSAPI DIGEST-MD5 DIGEST-MD5 
OTP OTP NTLM CRAM-MD5 NTLM CRAM-MD5 ANONYMOUS ANONYMOUS
{quote}

With the magic 32 sasl related tests pass and close the gap in earlier reported 
test success rate:
{quote}
62/62 Test #62: system_tests_router_mesh ..   Passed   
37.57 sec

82% tests passed, 11 tests failed out of 62

Total Test time (real) = 945.43 sec

The following tests FAILED:
 26 - system_tests_protocol_settings (Failed)
 27 - system_tests_qdmanage (Failed)
 29 - system_tests_sasl_plain (Failed)
 37 - system_tests_log_message_components (Failed)
 39 - system_tests_auth_service_plugin (Failed)
 40 - system_tests_authz_service_plugin (Failed)
 43 - system_tests_topology_disposition (Failed)
 50 - system_tests_ssl (Failed)
 54 - system_tests_http (Failed)
 57 - system_tests_core_client (Failed)
 60 - system_tests_multicast (Failed)
Errors while running CTest
(p3venv) i7mbp:0 rkieley$
{quote}

As to 1), why there are duplicates, I'm not sure. I don't recall it being this 
way when I did the original OSX work via PROTON-522, although I'd have to look 
at my logs to be sure. At the moment I'm on 10.14 with cyrus-sasl 2.1.27 vs. 
10.11 with cyrus-sasl 2.1.26, so it's possible either of those could make a 
difference. Would need to test to find out. In neither case was there a mixture 
of system sasl and MacPorts sasl as that had caused other subtle issues that 
were resolved by ensuring only one or the other was utilized. Maybe 
[~astitcher] knows off hand.

For 2), I always got a message here, 'Abort Trap: 6'. Stepping through with the 
debugger would always yield a SIGABRT. Taking a look at what abort trap 6 
indicates, it says that you've done some bad memory stuff and if you step 
through with the debugger the failure occurs 
[here|https://github.com/apache/qpid-proton/blob/0.29.0/c/src/sasl/sasl.c#L484] 
calling {code}
free(mechlist)
{code}

Ultimately the solution here is to not have a magic number and be a little more 
sophisticated in handling the memory. However I think the can could be kicked 
down the road a little further by going with the magic 32 for the moment, and 
updating the TODO to say something like
{quote}
// TODO: PROTON-2122: Replace magic number with dynamically sized memory
{quote}
which would at least eliminate the failures for the moment and allow the test 
failures to be cleaned up to 100% hopefully.


> Hardcoded limit of 16 sasl mechanisms is insufficient on macOS
> --
>
> Key: PROTON-2122
> URL: https://issues.apache.org/jira/browse/PROTON-2122
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.29.0
> Environment: macOS 10.14
>Reporter: Jiri Daněk
>Priority: Major
>
> On macOS, any time a SASL exchange happens in tests, e.g. 
> {{cpp-example-container}} or qpid dispatch tests, or when 
> {{cpp/examples/simple_send}} connects to {{cpp/examples/broker}}, the broker 
> crashes with the following stack trace
> {noformat}
> Thread 1 Crashed:
> 0   libsystem_kernel.dylib  0x7fff697c62c6 __pthread_kill + 10
> 1   libsystem_pthread.dylib 0x7fff69881bf1 pthread_kill + 284
> 2   libsystem_c.dylib   0x7fff69730745 __abort + 144
> 3   libsystem_c.dylib   0x7fff69730ff3 __stack_chk_fail + 
> 205
> 4   libqpid-proton-core.10.dylib0x000106d81f89 
> pni_post_sasl_frame + 1321
> 5   ??? 0x7fd57acb59bb 0 + 140554864908731
> {noformat}
> AddressSanitizer (Valgrind does not run on most recent macOS releases) points 
> out the reason.
> {noformat}
> $ ../cmake-build-debug/cpp/examples/broker 
> broker listening on 5672
> =
> ==42793==ERROR: AddressSanitizer: stack-buffer-overflow on address 
> 0x7c4bcbe0 at pc 0x0001013663e1 bp 0x7c4bc830 sp 0x7c4bc828
> WRITE of size 8 at 0x7c4bcbe0 thread T3
> #0 0x1013663e0 in pni_split_mechs sasl.c:443
> #1 0x1013646ea in pni_post_sasl_frame sasl.c:480
> #2 0x101357fad in pn_output_write_sasl 

[jira] [Created] (DISPATCH-1455) Two system tests failing after optparse to argparse migration

2019-10-20 Thread Ganesh Murthy (Jira)
Ganesh Murthy created DISPATCH-1455:
---

 Summary: Two system tests failing after optparse to argparse 
migration
 Key: DISPATCH-1455
 URL: https://issues.apache.org/jira/browse/DISPATCH-1455
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Tests
Reporter: Ganesh Murthy
 Fix For: 1.10.0


{noformat}
test_69_interior_qdstat_all_routers (system_tests_edge_router.RouterTest) ... 
FAIL==
FAIL: test_69_interior_qdstat_all_routers (system_tests_edge_router.RouterTest)
--
Traceback (most recent call last):
  File "/foo/qpid-dispatch/tests/system_tests_edge_router.py", line 1319, in 
test_69_interior_qdstat_all_routers
self.assertTrue(has_error)
AssertionError: False is not true {noformat}
 

Another test failure
{noformat}
test_parse_args_qdstat_print_help (test_command.TestParseArgsQdstat) ... 
ok==
ERROR: test_parse_args_qdstat_mutually_exclusive 
(test_command.TestParseArgsQdstat)
--
Traceback (most recent call last):
  File "/foo/qpid-dispatch/tests/test_command.py", line 70, in 
test_parse_args_qdstat_mutually_exclusive
_call_pairs(options1)
  File "/foo/qpid-dispatch/tests/test_command.py", line 67, in _call_pairs
with self.assertRaises(ValueError):
TypeError: failUnlessRaises() takes at least 3 arguments (2 given) {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[GitHub] [qpid-dispatch] ganeshmurthy commented on issue #596: WIP: assertRaises and mutually_exclusive groups not working as expected in rhel6

2019-10-20 Thread GitBox
ganeshmurthy commented on issue #596: WIP: assertRaises and mutually_exclusive 
groups not working as expected in rhel6
URL: https://github.com/apache/qpid-dispatch/pull/596#issuecomment-544300552
 
 
   I have opened a JIRA to address this - 
https://issues.apache.org/jira/browse/DISPATCH-1455


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (PROTON-2122) Hardcoded limit of 16 sasl mechanisms is insufficient on macOS

2019-10-20 Thread Jira


[ 
https://issues.apache.org/jira/browse/PROTON-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955512#comment-16955512
 ] 

Jiri Daněk commented on PROTON-2122:


To summarize the issues

1) why is every mechanism twice on the list? Is it because I have cyrus-sasl2 
from macports as well as some macOS system sasl lib?
2) proton should not crash without any explanatory failure message whatsoever
3) there's the hardcoded limit itself, but that is not too bothersome to me, if 
1 and 2 can be addressed.

> Hardcoded limit of 16 sasl mechanisms is insufficient on macOS
> --
>
> Key: PROTON-2122
> URL: https://issues.apache.org/jira/browse/PROTON-2122
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.29.0
> Environment: macOS 10.14
>Reporter: Jiri Daněk
>Priority: Major
>
> On macOS, any time a SASL exchange happens in tests, e.g. 
> {{cpp-example-container}} or qpid dispatch tests, or when 
> {{cpp/examples/simple_send}} connects to {{cpp/examples/broker}}, the broker 
> crashes with the following stack trace
> {noformat}
> Thread 1 Crashed:
> 0   libsystem_kernel.dylib  0x7fff697c62c6 __pthread_kill + 10
> 1   libsystem_pthread.dylib 0x7fff69881bf1 pthread_kill + 284
> 2   libsystem_c.dylib   0x7fff69730745 __abort + 144
> 3   libsystem_c.dylib   0x7fff69730ff3 __stack_chk_fail + 
> 205
> 4   libqpid-proton-core.10.dylib0x000106d81f89 
> pni_post_sasl_frame + 1321
> 5   ??? 0x7fd57acb59bb 0 + 140554864908731
> {noformat}
> AddressSanitizer (Valgrind does not run on most recent macOS releases) points 
> out the reason.
> {noformat}
> $ ../cmake-build-debug/cpp/examples/broker 
> broker listening on 5672
> =
> ==42793==ERROR: AddressSanitizer: stack-buffer-overflow on address 
> 0x7c4bcbe0 at pc 0x0001013663e1 bp 0x7c4bc830 sp 0x7c4bc828
> WRITE of size 8 at 0x7c4bcbe0 thread T3
> #0 0x1013663e0 in pni_split_mechs sasl.c:443
> #1 0x1013646ea in pni_post_sasl_frame sasl.c:480
> #2 0x101357fad in pn_output_write_sasl sasl.c:677
> #3 0x101323909 in transport_produce transport.c:2751
> #4 0x10131ffd3 in pn_transport_pending transport.c:3030
> #5 0x1012b8755 in pn_connection_driver_write_buffer 
> connection_driver.c:120
> #6 0x10120240f in leader_process_pconnection libuv.c:909
> #7 0x1011f8b48 in leader_lead_lh libuv.c:1008
> #8 0x1011f94f3 in pn_proactor_wait libuv.c:1062
> #9 0x10188c55d in proton::container::impl::thread() 
> proactor_container_impl.cpp:753
> #10 0x1018bca31 in void* 
> std::__1::__thread_proxy  std::__1::default_delete >, void 
> (proton::container::impl::*)(), proton::container::impl*> >(void*) thread:352
> #11 0x7fff6987f2ea in _pthread_body 
> (libsystem_pthread.dylib:x86_64+0x32ea)
> #12 0x7fff69882248 in _pthread_start 
> (libsystem_pthread.dylib:x86_64+0x6248)
> #13 0x7fff6987e40c in thread_start (libsystem_pthread.dylib:x86_64+0x240c)
> Address 0x7c4bcbe0 is located in stack of thread T3 at offset 192 in frame
> #0 0x101363ccf in pni_post_sasl_frame sasl.c:462
>   This frame has 3 object(s):
> [32, 48) 'out' (line 464)
> [64, 192) 'mechs' (line 475) <== Memory access at offset 192 overflows 
> this variable
> [224, 228) 'count' (line 478)
> HINT: this may be a false positive if your program uses some custom stack 
> unwind mechanism, swapcontext or vfork
>   (longjmp and C++ exceptions *are* supported)
> Thread T3 created by T0 here:
> #0 0x101f5dadd in wrap_pthread_create 
> (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x56add)
> #1 0x1018bc4ab in std::__1::thread::thread (proton::container::impl::*)(), proton::container::impl*, void>(void 
> (proton::container::impl::*&&)(), proton::container::impl*&&) thread:368
> #2 0x10188da97 in proton::container::impl::run(int) 
> proactor_container_impl.cpp:802
> #3 0x100f0223c in main broker.cpp:427
> #4 0x7fff6968b3d4 in start (libdyld.dylib:x86_64+0x163d4)
> SUMMARY: AddressSanitizer: stack-buffer-overflow sasl.c:443 in pni_split_mechs
> Shadow bytes around the buggy address:
>   0x1e0001897920: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1e0001897930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1e0001897940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1e0001897950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1e0001897960: 00 00 00 00 f1 f1 f1 f1 00 00 f2 f2 00 00 00 00
> =>0x1e0001897970: 00 00 00 00 00 00 00 00 00 00 00 00[f2]f2 f2 f2
>   0x1e0001897980: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1e0001897990: 00 00 00 00 00 00