{"action":"created","issue":{"url":"https://api.github.com/repos/robotology/yarp/issues/861","repository_url":"https://api.github.com/repos/robotology/yarp","labels_url":"https://api.github.com/repos/robotology/yarp/issues/861/labels{/name}","comments_url":"https://api.github.com/repos/robotology/yarp/issues/861/comments","events_url":"https://api.github.com/repos/robotology/yarp/issues/861/events","html_url":"https://github.com/robotology/yarp/pull/861","id":169898996,"number":861,"title":"Remote control board remapper","user":{"login":"traversaro","id":1857049,"avatar_url":"https://avatars.githubusercontent.com/u/1857049?v=3","gravatar_id":"","url":"https://api.github.com/users/traversaro","html_url":"https://github.com/traversaro","followers_url":"https://api.github.com/users/traversaro/followers","following_url":"https://api.github.com/users/traversaro/following{/other_user}","gists_url":"https://api.github.com/users/traversaro/gists{/gist_id}","starred_url":"https://api.github.com/users/traversaro/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/traversaro/subscriptions","organizations_url":"https://api.github.com/users/traversaro/orgs","repos_url":"https://api.github.com/users/traversaro/repos","events_url":"https://api.github.com/users/traversaro/events{/privacy}","received_events_url":"https://api.github.com/users/traversaro/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/robotology/yarp/labels/Status:%20In%20Progress","name":"Status: In Progress","color":"ededed"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2016-08-08T11:15:06Z","updated_at":"2016-08-12T08:35:48Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/robotology/yarp/pulls/861","html_url":"https://github.com/robotology/yarp/pull/861","diff_url":"https://github.com/robotology/yarp/pull/861.diff","patch_url":"https://github.com/robotology/yarp/pull/861.patch"},"body":"Add the new `remotecontrolboardremapper` device, rationale for its use can be found in the class documentation https://github.com/robotology/yarp/compare/devel...traversaro:RemoteControlBoardRemapper?expand=1#diff-2ce8be34020e8c21cfd98d56050157a4R22 and in https://github.com/robotology/yarp/pull/746 .\r\n\r\nTests of the `controlboardremapper` device have been modified to test also the `remotecontorlboardmapper`  . \r\n\r\nDocumentation of the `remote_controlboard` has been also added for consistency : https://github.com/robotology/yarp/commit/f5e88f2b1c7be0862f747f9d9ba68635d92dad53 .\n<a href='#crh-start'></a><a href='#crh-data-%7B%22processed%22%3A%20%5B%22https%3A//github.com/robotology/yarp/pull/861%23issuecomment-238487668%22%2C%20%22https%3A//github.com/robotology/yarp/pull/861%23issuecomment-238822697%22%2C%20%22https%3A//github.com/robotology/yarp/pull/861%23issuecomment-238943211%22%2C%20%22https%3A//github.com/robotology/yarp/pull/861%23issuecomment-239009277%22%2C%20%22https%3A//github.com/robotology/yarp/pull/861%23issuecomment-239384104%22%5D%2C%20%22comments%22%3A%20%7B%22General%20Comment%22%3A%20%7B%22html_url%22%3A%20%22https%3A//github.com/robotology/yarp/pull/861%23issuecomment-238487668%22%2C%20%22comments%22%3A%20%5B%7B%22body%22%3A%20%22There%20are%20various%20compilation%20failures%20in%20Travis%2C%20but%20apparently%20they%20also%20%20occur%20in%20the%20%60master%60/%60devel%60%20branches%2C%20so%20they%20are%20not%20directly%20related%20to%20this%20PR.%20%22%2C%20%22created_at%22%3A%20%222016-08-09T08%3A29%3A22Z%22%2C%20%22user%22%3A%20%7B%22avatar_url%22%3A%20%22https%3A//avatars.githubusercontent.com/u/1857049%3Fv%3D3%22%2C%20%22html_url%22%3A%20%22https%3A//github.com/traversaro%22%7D%7D%2C%20%7B%22body%22%3A%20%22%40traversaro%20the%20build%20should%20be%20fixed%2C%20can%20you%20please%20rebase%20the%20branch%3F%22%2C%20%22created_at%22%3A%20%222016-08-10T10%3A05%3A38Z%22%2C%20%22user%22%3A%20%7B%22avatar_url%22%3A%20%22https%3A//avatars.githubusercontent.com/u/1100056%3Fv%3D3%22%2C%20%22html_url%22%3A%20%22https%3A//github.com/drdanz%22%7D%7D%2C%20%7B%22body%22%3A%20%22%60Valgrind%60%20build%20on%20Travis%20catched%20a%20valid%20leak%2C%20apparently%3A%20https%3A//travis-ci.org/traversaro/yarp/jobs/151172548%20%20.%20%22%2C%20%22created_at%22%3A%20%222016-08-10T17%3A36%3A43Z%22%2C%20%22user%22%3A%20%7B%22avatar_url%22%3A%20%22https%3A//avatars.githubusercontent.com/u/1857049%3Fv%3D3%22%2C%20%22html_url%22%3A%20%22https%3A//github.com/traversaro%22%7D%7D%2C%20%7B%22body%22%3A%20%22Finally%20Valgrind%20tests%20were%20useful%21%20%3Atada%3A%22%2C%20%22created_at%22%3A%20%222016-08-10T21%3A24%3A40Z%22%2C%20%22user%22%3A%20%7B%22avatar_url%22%3A%20%22https%3A//avatars.githubusercontent.com/u/1100056%3Fv%3D3%22%2C%20%22html_url%22%3A%20%22https%3A//github.com/drdanz%22%7D%7D%2C%20%7B%22body%22%3A%20%22Debugging%20the%20issue%20on%20%60Ubuntu%2016.04%60%20rather%20then%20%60Ubuntu%2014.04%60%20used%20in%20%60Travis%60%2C%20I%20got%20the%20following%20leaks%3A%20%5Cr%5Cn%7E%7E%7E%5Cr%5Cn%3D%3D17000%3D%3D%20HEAP%20SUMMARY%3A%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20%20in%20use%20at%20exit%3A%2072%2C736%20bytes%20in%202%20blocks%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20total%20heap%20usage%3A%20658%2C430%20allocs%2C%20658%2C428%20frees%2C%20119%2C016%2C174%20bytes%20allocated%5Cr%5Cn%3D%3D17000%3D%3D%20%5Cr%5Cn%3D%3D17000%3D%3D%20Thread%201%3A%5Cr%5Cn%3D%3D17000%3D%3D%2032%20bytes%20in%201%20blocks%20are%20still%20reachable%20in%20loss%20record%201%20of%202%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20at%200x4C2FB55%3A%20calloc%20%28in%20/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x7A5C626%3A%20_dlerror_run%20%28/build/glibc-GKVZIf/glibc-2.23/dlfcn/dlerror.c%3A141%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x7A5BFA0%3A%20dlopen%40%40GLIBC_2.2.5%20%28/build/glibc-GKVZIf/glibc-2.23/dlfcn/dlopen.c%3A87%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x67A24EB%3A%20ACE_DLL_Handle%3A%3Aopen%28char%20const%2A%2C%20int%2C%20void%2A%2C%20ACE_Fixed_Stack%3CACE_String_Base%3Cchar%3E%2C%2010ul%3E%2A%29%20%28in%20/usr/lib/libACE-6.3.3.so%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x67A2A57%3A%20ACE_DLL_Manager%3A%3Aopen_dll%28char%20const%2A%2C%20int%2C%20void%2A%2C%20ACE_Fixed_Stack%3CACE_String_Base%3Cchar%3E%2C%2010ul%3E%2A%29%20%28in%20/usr/lib/libACE-6.3.3.so%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x67604EA%3A%20ACE_DLL%3A%3Aopen_i%28char%20const%2A%2C%20int%2C%20bool%2C%20void%2A%29%20%28in%20/usr/lib/libACE-6.3.3.so%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x5AE164C%3A%20yarp%3A%3Aos%3A%3ASharedLibrary%3A%3Aopen%28char%20const%2A%29%20%28in%20/home/traversaro/src/codyco-superbuild/build/external/YARP/lib/libYARP_OS.so.2.3.67.1%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x5AE1E09%3A%20yarp%3A%3Aos%3A%3ASharedLibraryFactory%3A%3Aopen%28char%20const%2A%2C%20char%20const%2A%29%20%28in%20/home/traversaro/src/codyco-superbuild/build/external/YARP/lib/libYARP_OS.so.2.3.67.1%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x5AFB245%3A%20yarp%3A%3Aos%3A%3AYarpPluginSettings%3A%3Asubopen%28yarp%3A%3Aos%3A%3ASharedLibraryFactory%26%2C%20yarp%3A%3Aos%3A%3AConstString%20const%26%2C%20yarp%3A%3Aos%3A%3AConstString%20const%26%29%20%28in%20/home/traversaro/src/codyco-superbuild/build/external/YARP/lib/libYARP_OS.so.2.3.67.1%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x5AFCB00%3A%20yarp%3A%3Aos%3A%3AYarpPluginSettings%3A%3Aopen%28yarp%3A%3Aos%3A%3ASharedLibraryFactory%26%29%20%28in%20/home/traversaro/src/codyco-superbuild/build/external/YARP/lib/libYARP_OS.so.2.3.67.1%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x4F24CAF%3A%20DriversHelper%3A%3Aload%28char%20const%2A%29%20%28in%20/home/traversaro/src/codyco-superbuild/build/external/YARP/lib/libYARP_dev.so.2.3.67.1%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x4F26074%3A%20yarp%3A%3Adev%3A%3ADrivers%3A%3Afind%28char%20const%2A%29%20%28in%20/home/traversaro/src/codyco-superbuild/build/external/YARP/lib/libYARP_dev.so.2.3.67.1%29%5Cr%5Cn%3D%3D17000%3D%3D%20%5Cr%5Cn%3D%3D17000%3D%3D%2072%2C704%20bytes%20in%201%20blocks%20are%20still%20reachable%20in%20loss%20record%202%20of%202%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20at%200x4C2DB8F%3A%20malloc%20%28in%20/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x5DF8EFF%3A%20%3F%3F%3F%20%28in%20/usr/lib/x86_64-linux-gnu/libstdc%2B%2B.so.6.0.21%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x40104E9%3A%20call_init.part.0%20%28/build/glibc-GKVZIf/glibc-2.23/elf/dl-init.c%3A72%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x40105FA%3A%20call_init%20%28/build/glibc-GKVZIf/glibc-2.23/elf/dl-init.c%3A30%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x40105FA%3A%20_dl_init%20%28/build/glibc-GKVZIf/glibc-2.23/elf/dl-init.c%3A120%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x4000CF9%3A%20%3F%3F%3F%20%28in%20/lib/x86_64-linux-gnu/ld-2.23.so%29%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200x3%3A%20%3F%3F%3F%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200xFFEFFFFAA%3A%20%3F%3F%3F%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200xFFEFFFFF5%3A%20%3F%3F%3F%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200xFFEFFFFFD%3A%20%3F%3F%3F%5Cr%5Cn%3D%3D17000%3D%3D%20%20%20%20by%200xFFF000008%3A%20%3F%3F%3F%5Cr%5Cn%7E%7E%7E%5Cr%5Cn%5Cr%5Cn%23%23%2032%20bytes%20%5C%22leak%5C%22%5Cr%5CnThe%2032%20bytes%20leaks%20is%20probably%20the%20one%20detected%20by%20Travis.%20This%20is%20a%20known%20bug%20in%20%60dlopen%60%2C%20see%20for%20example%20%5B2%5D.%20On%20debian%20system%20a%20suppression%20for%20this%20error%20can%20be%20found%20in%20%60/usr/lib/valgrind/debian.supp%60%2C%20but%20I%20guess%20this%20suppression%20is%20not%20used%20automatically%20or%20something%20slightly%20changes%20so%20the%20error%20is%20not%20actually%20suppressed.%20%5Cr%5Cn%5Cr%5Cn%23%23%2072%2C704%20bytes%20%5C%22leak%5C%22%5Cr%5CnThe%2072%2C704%20loss%20record%20is%20a%20known%20area%20of%20memory%20that%20is%20not%20freed%20in%20gcc%205.1.%20%5B1%5D%5Cr%5Cn%5Cr%5Cn%23%23%20Proposed%20solution%5Cr%5CnI%20think%20it%20make%20sense%20to%20add%20it%20to%20a%20YARP-specific%20Valgrind%20suppression%20file%20to%20suppress%20this%20errors.%20%5Cr%5Cn%40drdanz%20what%20do%20you%20think%3F%20If%20you%20give%20me%20the%20green%20light%20on%20this%20I%20can%20add%20it%20and%20integrate%20it%20with%20CMake%20test%20logic.%20%5Cr%5Cn%5Cr%5Cn%5Cr%5Cn%5B1%5D%20%3A%20https%3A//gcc.gnu.org/bugzilla/show_bug.cgi%3Fid%3D66339%5Cr%5Cn%5B2%5D%20%3A%20https%3A//bugs.debian.org/cgi-bin/bugreport.cgi%3Fbug%3D700899%22%2C%20%22created_at%22%3A%20%222016-08-12T07%3A55%3A41Z%22%2C%20%22user%22%3A%20%7B%22avatar_url%22%3A%20%22https%3A//avatars.githubusercontent.com/u/1857049%3Fv%3D3%22%2C%20%22html_url%22%3A%20%22https%3A//github.com/traversaro%22%7D%7D%5D%2C%20%22title%22%3A%20%22General%20Comment%22%7D%7D%7D'></a>\n<a href='https://www.codereviewhub.com/'><img src='http://www.codereviewhub.com/site/github-bar.png' height=40></a>\n- [ ] <a href='#crh-comment-General Comment'></a> <img src='http://www.codereviewhub.com/site/github-remaining.png' height=16 width=60>&nbsp;<b><a href='https://github.com/robotology/yarp/pull/861#issuecomment-238487668'>General Comment</a></b>\n- <a href='https://github.com/traversaro'><img border=0 src='https://avatars.githubusercontent.com/u/1857049?v=3' height=16 width=16'></a> There are various compilation failures in Travis, but apparently they also  occur in the `master`/`devel` branches, so they are not directly related to this PR.\n- <a href='https://github.com/drdanz'><img border=0 src='https://avatars.githubusercontent.com/u/1100056?v=3' height=16 width=16'></a> @traversaro the build should be fixed, can you please rebase the branch?\n- <a href='https://github.com/traversaro'><img border=0 src='https://avatars.githubusercontent.com/u/1857049?v=3' height=16 width=16'></a> `Valgrind` build on Travis catched a valid leak, apparently: https://travis-ci.org/traversaro/yarp/jobs/151172548  .\n- <a href='https://github.com/drdanz'><img border=0 src='https://avatars.githubusercontent.com/u/1100056?v=3' height=16 width=16'></a> Finally Valgrind tests were useful! :tada:\n- <a href='https://github.com/traversaro'><img border=0 src='https://avatars.githubusercontent.com/u/1857049?v=3' height=16 width=16'></a> Debugging the issue on `Ubuntu 16.04` rather then `Ubuntu 14.04` used in `Travis`, I got the following leaks:\n~~~\n==17000== HEAP SUMMARY:\n==17000==     in use at exit: 72,736 bytes in 2 blocks\n==17000==   total heap usage: 658,430 allocs, 658,428 frees, 119,016,174 bytes allocated\n==17000==\n==17000== Thread 1:\n==17000== 32 bytes in 1 blocks are still reachable in loss record 1 of 2\n==17000==    at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n==17000==    by 0x7A5C626: _dlerror_run (/build/glibc-GKVZIf/glibc-2.23/dlfcn/dlerror.c:141)\n==17000==    by 0x7A5BFA0: dlopen@@GLIBC_2.2.5 (/build/glibc-GKVZIf/glibc-2.23/dlfcn/dlopen.c:87)\n==17000==    by 0x67A24EB: ACE_DLL_Handle::open(char const*, int, void*, ACE_Fixed_Stack<ACE_String_Base<char>, 10ul>*) (in /usr/lib/libACE-6.3.3.so)\n==17000==    by 0x67A2A57: ACE_DLL_Manager::open_dll(char const*, int, void*, ACE_Fixed_Stack<ACE_String_Base<char>, 10ul>*) (in /usr/lib/libACE-6.3.3.so)\n==17000==    by 0x67604EA: ACE_DLL::open_i(char const*, int, bool, void*) (in /usr/lib/libACE-6.3.3.so)\n==17000==    by 0x5AE164C: yarp::os::SharedLibrary::open(char const*) (in /home/traversaro/src/codyco-superbuild/build/external/YARP/lib/libYARP_OS.so.2.3.67.1)\n==17000==    by 0x5AE1E09: yarp::os::SharedLibraryFactory::open(char const*, char const*) (in /home/traversaro/src/codyco-superbuild/build/external/YARP/lib/libYARP_OS.so.2.3.67.1)\n==17000==    by 0x5AFB245: yarp::os::YarpPluginSettings::subopen(yarp::os::SharedLibraryFactory&, yarp::os::ConstString const&, yarp::os::ConstString const&) (in /home/traversaro/src/codyco-superbuild/build/external/YARP/lib/libYARP_OS.so.2.3.67.1)\n==17000==    by 0x5AFCB00: yarp::os::YarpPluginSettings::open(yarp::os::SharedLibraryFactory&) (in /home/traversaro/src/codyco-superbuild/build/external/YARP/lib/libYARP_OS.so.2.3.67.1)\n==17000==    by 0x4F24CAF: DriversHelper::load(char const*) (in /home/traversaro/src/codyco-superbuild/build/external/YARP/lib/libYARP_dev.so.2.3.67.1)\n==17000==    by 0x4F26074: yarp::dev::Drivers::find(char const*) (in /home/traversaro/src/codyco-superbuild/build/external/YARP/lib/libYARP_dev.so.2.3.67.1)\n==17000==\n==17000== 72,704 bytes in 1 blocks are still reachable in loss record 2 of 2\n==17000==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n==17000==    by 0x5DF8EFF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)\n==17000==    by 0x40104E9: call_init.part.0 (/build/glibc-GKVZIf/glibc-2.23/elf/dl-init.c:72)\n==17000==    by 0x40105FA: call_init (/build/glibc-GKVZIf/glibc-2.23/elf/dl-init.c:30)\n==17000==    by 0x40105FA: _dl_init (/build/glibc-GKVZIf/glibc-2.23/elf/dl-init.c:120)\n==17000==    by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)\n==17000==    by 0x3: ???\n==17000==    by 0xFFEFFFFAA: ???\n==17000==    by 0xFFEFFFFF5: ???\n==17000==    by 0xFFEFFFFFD: ???\n==17000==    by 0xFFF000008: ???\n~~~\n## 32 bytes \"leak\"\nThe 32 bytes leaks is probably the one detected by Travis. This is a known bug in `dlopen`, see for example [2]. On debian system a suppression for this error can be found in `/usr/lib/valgrind/debian.supp`, but I guess this suppression is not used automatically or something slightly changes so the error is not actually suppressed.\n## 72,704 bytes \"leak\"\nThe 72,704 loss record is a known area of memory that is not freed in gcc 5.1. [1]\n## Proposed solution\nI think it make sense to add it to a YARP-specific Valgrind suppression file to suppress this errors.\n@drdanz what do you think? If you give me the green light on this I can add it and integrate it with CMake test logic.\n[1] : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339\n[2] : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700899\n\n\n<a href='https://www.codereviewhub.com/robotology/yarp/pull/861?mark_as_completed=1'><img src='http://www.codereviewhub.com/site/github-mark-as-completed.png' height=26></a>&nbsp;<a href='https://www.codereviewhub.com/robotology/yarp/pull/861?approve=1'><img src='http://www.codereviewhub.com/site/github-approve.png' height=26></a>&nbsp;<a href='https://github.com/robotology/yarp/pull/861'><img src='http://www.codereviewhub.com/site/github-refresh.png' height=26></a>\n<a href='#crh-end'></a>"},"comment":{"url":"https://api.github.com/repos/robotology/yarp/issues/comments/239391500","html_url":"https://github.com/robotology/yarp/pull/861#issuecomment-239391500","issue_url":"https://api.github.com/repos/robotology/yarp/issues/861","id":239391500,"user":{"login":"traversaro","id":1857049,"avatar_url":"https://avatars.githubusercontent.com/u/1857049?v=3","gravatar_id":"","url":"https://api.github.com/users/traversaro","html_url":"https://github.com/traversaro","followers_url":"https://api.github.com/users/traversaro/followers","following_url":"https://api.github.com/users/traversaro/following{/other_user}","gists_url":"https://api.github.com/users/traversaro/gists{/gist_id}","starred_url":"https://api.github.com/users/traversaro/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/traversaro/subscriptions","organizations_url":"https://api.github.com/users/traversaro/orgs","repos_url":"https://api.github.com/users/traversaro/repos","events_url":"https://api.github.com/users/traversaro/events{/privacy}","received_events_url":"https://api.github.com/users/traversaro/received_events","type":"User","site_admin":false},"created_at":"2016-08-12T08:35:48Z","updated_at":"2016-08-12T08:35:48Z","body":"Even by suppressing the leak errors, I still have problem of not initialized memory. \r\nTo clarify : all this issues have not been introduced by this PR, but this PR introduces a test that for the first time tests the `RemoteControlBoard` and the `ControlBoardWrapper` classes, and all the code that they use. "}}
{"actor":{"display_login":"traversaro"}}