Re: Valgrind based soak tests fail against earlier versions of valgrind (3.2.1)
Hi Ken
I confirm all now looks good. Thanks for all your help.
cheers, Keith
On 5 April 2013 16:26, Ken Giusti kgiu...@redhat.com wrote:
Hi Keith,
Just FYI - I've got access to a RHEL5.3 box, reproduced what you are seeing
and have submitted a patch on trunk.
You should be good to go now, let me know if you hit any problems.
thanks,
-K
- Original Message -
From: Ken Giusti kgiu...@redhat.com
To: proton@qpid.apache.org, keith wall keith.w...@gmail.com
Sent: Friday, April 5, 2013 9:37:30 AM
Subject: Re: Valgrind based soak tests fail against earlier versions of
valgrind (3.2.1)
Wow, you certainly hit the jackpot there. Unfortunately OpenSSL is not
valgrind clean.
I'll repatch the suppression file and send you a candidate to try since I'm
not able to trigger these.
Once you're fully clear I'll check in the patch.
Just FYI - if you want to skip the valgrind checks, and you're running the
test from the command line (as opposed to via ctest), you can undefine the
environment variable VALGRIND that was set via config.sh.
export -n VALGRIND
that should keep the valgrind-based test cases from running.
There's also an ENABLE_VALGRIND flag you can turn off if you are used ctest
via make edit_cache. Haven't tried that, but I'm assuming it will work.
thanks for your help.
-K
- Original Message -
From: Keith W keith.w...@gmail.com
To: Ken Giusti kgiu...@redhat.com
Cc: proton@qpid.apache.org
Sent: Friday, April 5, 2013 3:55:15 AM
Subject: Re: Valgrind based soak tests fail against earlier versions of
valgrind (3.2.1)
Hi Ken
I confirm that with your patch, the soak test now pass on a RHEL 5.3
with valgrind 3.2.1. As you suspected, there were a couple of
supression reports. I attach them all below.
Thanks again, Keith.
/usr/local/python2.7/bin/python ./tests/python/proton-test
proton_tests.soak.* 21 valgrind_output_with-patch-from-ken
==11569==
==11569== Print suppression ? --- [Return/N/n/Y/y/C/c] y
{
insert a suppression name here
Memcheck:Leak
fun:_vgrZU_libcZdsoZa_realloc
fun:CRYPTO_realloc
fun:lh_insert
obj:/lib64/libcrypto.so.0.9.8e
fun:ERR_load_strings
fun:ERR_load_X509V3_strings
fun:ERR_load_crypto_strings
fun:SSL_load_error_strings
fun:pn_ssl_domain
fun:pn_messenger_tsync
fun:pn_messenger_sync
fun:pn_messenger_recv
}
==11569==
==11569== Print suppression ? --- [Return/N/n/Y/y/C/c] y
{
insert a suppression name here
Memcheck:Leak
fun:_vgrZU_libcZdsoZa_malloc
fun:CRYPTO_malloc
fun:lh_new
fun:OBJ_NAME_init
fun:OBJ_NAME_add
fun:EVP_add_cipher
fun:SSL_library_init
fun:pn_ssl_domain
fun:pn_messenger_tsync
fun:pn_messenger_sync
fun:pn_messenger_recv
fun:main
}
==11626==
==11626== Print suppression ? --- [Return/N/n/Y/y/C/c] y
{
insert a suppression name here
Memcheck:Leak
fun:_vgrZU_libcZdsoZa_realloc
fun:CRYPTO_realloc
fun:lh_insert
obj:/lib64/libcrypto.so.0.9.8e
fun:ERR_load_strings
fun:ERR_load_X509V3_strings
fun:ERR_load_crypto_strings
fun:SSL_load_error_strings
fun:pn_ssl_domain
fun:pn_messenger_tsync
fun:pn_messenger_sync
fun:pn_messenger_recv
}
==11626==
==11626== Print suppression ? --- [Return/N/n/Y/y/C/c] y
{
insert a suppression name here
Memcheck:Leak
fun:_vgrZU_libcZdsoZa_malloc
fun:CRYPTO_malloc
fun:lh_new
fun:OBJ_NAME_init
fun:OBJ_NAME_add
fun:EVP_add_cipher
fun:SSL_library_init
fun:pn_ssl_domain
fun:pn_messenger_tsync
fun:pn_messenger_sync
fun:pn_messenger_recv
fun:main
}
==11659==
==11659== Print suppression ? --- [Return/N/n/Y/y/C/c] y
{
insert a suppression name here
Memcheck:Leak
fun:_vgrZU_libcZdsoZa_realloc
fun:CRYPTO_realloc
fun:lh_insert
obj:/lib64/libcrypto.so.0.9.8e
fun:ERR_load_strings
fun:ERR_load_X509V3_strings
fun:ERR_load_crypto_strings
fun:SSL_load_error_strings
fun:pn_ssl_domain
fun:pn_messenger_tsync
fun:pn_messenger_sync
fun:pn_messenger_recv
}
==11659==
==11659== Print suppression ? --- [Return/N/n/Y/y/C/c] y
{
insert a suppression name here
Memcheck:Leak
fun:_vgrZU_libcZdsoZa_malloc
fun:CRYPTO_malloc
fun:lh_new
fun:OBJ_NAME_init
fun:OBJ_NAME_add
fun:EVP_add_cipher
fun:SSL_library_init
fun:pn_ssl_domain
fun:pn_messenger_tsync
fun:pn_messenger_sync
fun:pn_messenger_recv
fun:main
}
==11767==
==11767== Print suppression ? --- [Return/N/n/Y/y/C/c] y
{
insert a suppression name here
Memcheck:Leak
fun:_vgrZU_libcZdsoZa_realloc
fun:CRYPTO_realloc
fun:lh_insert
obj:/lib64/libcrypto.so.0.9.8e
fun:ERR_load_strings
Cross-MinGW linking problem
Hi, every body. I was just tring to build Proton (svn1465587) with MinGW on Fedora cross-compiling environment[1]. When linking libqpid-proton.dll, I found libqpid-proton.dll.a is missing symbols available in the dll. The linking command: /usr/bin/i686-w64-mingw32-gcc -Wl,--no-undefined -shared -o libqpid-proton.dll -Wl,--out-implib,libqpid-proton.dll.a -Wl,--major-image-version,1,--minor-image-version,0 -Wl,--whole-archive CMakeFiles/qpid-proton.dir/objects.a -Wl,--no-whole-archive -lws2_32 -lrpcrt4 -L. -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 Output of 'i686-w64-mingw32-nm objects.a' in qpid-proton.dir: http://cheeselee.fedorapeople.org/nm-qpid-proton-objects.a.txt Output of 'i686-w64-mingw32-nm libqpid-proton.dll': http://cheeselee.fedorapeople.org/nm-libqpid-proton.dll.txt Output of 'i686-w64-mingw32-nm libqpid-proton.dll.a': http://cheeselee.fedorapeople.org/nm-libqpid-proton.dll.a.txt The successive result is proton.exe failed to link, since libqpid-proton.dll.a is missing symbols. 0.4 stable also suffer this problem. Native Linux Build is smooth. [1] MinGW package list: mingw32-boost-1.50.0-1.fc18.noarch mingw32-filesystem-97-1.fc18.noarch mingw32-gcc-c++-4.7.2-7.fc18.x86_64 mingw32-bzip2-1.0.6-2.fc18.noarch mingw32-zlib-1.2.7-1.fc18.noarch mingw-binutils-generic-2.23.1-2.fc18.x86_64 mingw32-win-iconv-0.0.4-1.fc18.noarch mingw32-boost-static-1.50.0-1.fc18.noarch mingw32-headers-2.0.999-0.15.trunk.20121110.fc18.noarch mingw32-crt-2.0.999-0.16.trunk.20121110.fc18.noarch mingw32-gcc-4.7.2-7.fc18.x86_64 mingw32-pthreads-2.8.0-22.20110511cvs.fc18.noarch mingw32-binutils-2.23.1-2.fc18.x86_64 mingw32-pcre-8.31-1.fc18.noarch mingw-filesystem-base-97-1.fc18.noarch mingw32-pthreads-static-2.8.0-22.20110511cvs.fc18.noarch mingw32-cpp-4.7.2-7.fc18.x86_64
Re: rdma support in python
Hi, There are a few different ways you could integrate RDMA into the proton architecture. For example you could provide a general purpose C driver for RDMA similar to the TCP driver currently included. This would be something you could use from any of the bindings, not just python. The proton roadmap also includes several features geared towards allowing you to supply your own driver with messenger. This would be something you could use to write your own integration glue between python RDMA and proton's python bindings, once available. Can you describe your use case a bit more? Is it explicitly integration with the python RDMA module you mention or are you just generally interested in running AMQP over RDMA and like developing in python? It's also worth nothing that there is no official specification for a binding of AMQP over RDMA. That doesn't of course preclude you from developing one, however depending on your use case it may be more or less important for you to kickstart some kind of activity towards an RDMA binding in the OASIS bindings and mappings TC. --Rafael On Fri, Apr 5, 2013 at 8:27 PM, euroford an.eurof...@gmail.com wrote: Hi all, THere is a project Python-rmda, https://github.com/jgunthorpe/python-rdma, is that possible qpid-python got rmda support with it? Bests, An Yang -- View this message in context: http://qpid.2158936.n2.nabble.com/rdma-support-in-python-tp7591210.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
possible cool change to pn_messenger_route()
While working on docs, I was getting excited about something cool that I could
do with pn_messenger_route()
And then I realized that I couldn't.
What would you think about allowing replacement of an old route by a new route
with the same pattern ?
It seems like this would allow some cool, adaptive behavior in Proton networks.
I just coded and tested a simple case successfully -- sending 2 messages to an
abstract address, and having them go to 2 different receivers because a new
route got set in between.
Would this behavior cause any problems that would outweigh the coolness?
Code seems pretty straightforward - - - -
int pn_messenger_route(pn_messenger_t *messenger, const char *pattern, const
char *address)
{
if (strlen(pattern) PN_MAX_PATTERN || strlen(address) PN_MAX_ROUTE) {
return PN_ERR;
}
pn_route_t *new_route = (pn_route_t *) malloc(sizeof(pn_route_t));
if (!new_route) return PN_ERR;
strcpy(new_route-pattern, pattern);
strcpy(new_route-address, address);
new_route-next = NULL;
/* The list is empty. */
if (! messenger-routes ) {
messenger-routes = new_route;
return 0;
}
pn_route_t *old;
/* The route to be replaced is first on the list. */
if ( ! strcmp ( messenger-routes-pattern, new_route-pattern ) ) {
old = messenger-routes;
new_route-next = old-next;
messenger-routes = new_route;
free ( (char *) old );
return 0;
}
pn_route_t *route = messenger-routes;
/* The route to be replaced is somewhere down the list, or not there. */
while ( 1 ) {
/* No route in list had same pattern. */
if ( ! route-next ) {
route-next = new_route;
return 0;
}
/* Bingo ! */
if ( ! strcmp ( route-next-pattern, new_route-pattern ) ) {
old = route-next;
new_route-next = old-next;
route-next = new_route;
free ( (char *) old );
return 0;
}
route = route-next;
}
return 0;
}
[jira] [Created] (PROTON-286) Windows driver hangs on pending connection close
Cliff Jansen created PROTON-286: --- Summary: Windows driver hangs on pending connection close Key: PROTON-286 URL: https://issues.apache.org/jira/browse/PROTON-286 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen The Windows driver tracks the pending close count just like the Linux driver, but it fails to use non-blocking select() when the count 0. This can result in a hang. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-286) Windows driver hangs on pending connection close
[ https://issues.apache.org/jira/browse/PROTON-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-286. - Resolution: Fixed Fix Version/s: 0.5 Fixed: http://svn.apache.org/r1465858 Windows driver hangs on pending connection close Key: PROTON-286 URL: https://issues.apache.org/jira/browse/PROTON-286 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.5 The Windows driver tracks the pending close count just like the Linux driver, but it fails to use non-blocking select() when the count 0. This can result in a hang. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
