GitHub pull request #3700 of commit c8ed45454745f27c663dd111735054cde5dd4de9, no merge conflicts.sha1origin/pr/3700/mergeghprbActualCommitc8ed45454745f27c663dd111735054cde5dd4de9ghprbActualCommitAuthorghprbActualCommitAuthorEmailghprbAuthorRepoGitUrlhttps://github.com/eduardo-elizondo/bcc.gitghprbTriggerAuthorghprbTriggerAuthorEmailghprbTriggerAuthorLoginyonghong-songghprbTriggerAuthorLoginMention@yonghong-songghprbPullId3700ghprbTargetBranchmasterghprbSourceBranchadd_strict_weak_orderingGIT_BRANCHadd_strict_weak_orderingghprbPullAuthorEmaileduardo.elizondorueda@gmail.comghprbPullAuthorLogineduardo-elizondoghprbPullAuthorLoginMention@eduardo-elizondoghprbPullDescriptionGitHub pull request #3700 of commit c8ed45454745f27c663dd111735054cde5dd4de9, no merge conflicts.ghprbPullTitleGuarantee strict weak order in Probe::finalize_locationsghprbPullLinkhttps://github.com/iovisor/bcc/pull/3700ghprbPullLongDescriptionCurrently, `Probe::finalize_locations` uses `std::sort` on its `locations_` via a custom defined lambda. The provided lambda though, does not guarantee [strict weak ordering](https://en.cppreference.com/w/cpp/concepts/strict_weak_order), and thus, violates one of the [requirements of the compare function](https://en.cppreference.com/w/cpp/named_req/Compare).\r\n\r\nThe comparison function `a.bin_path_ < b.bin_path_ || a.address_ < b.address_` fails the guarantee that `If comp(a,b)==true then comp(b,a)==false`. Quick example, let `a = (\"a\", 3)` and `b = (\"b\", 1)`. In this case, both `comp(a,b)==true and comp(b,a)==true`. Code sample: https://godbolt.org/z/vWbcazTvj\r\n\r\nIn practice, this undefined behavior might lead to weird behavior such as random segmentation faults which I managed to hit in some of my production binaries. i.e:\r\n```\r\n*** Signal 11 (SIGSEGV) received by PID X (code: -6), stack trace: ***\r\n @ (unknown)\r\n @ __memcmp_avx2_movbe\r\n @ void std::__unguarded_linear_insert<__gnu_cxx::__normal_iterator<USDT::Location*, std::vector<USDT::Location, std::allocator<USDT::Location> > >, __gnu_cxx::__ops::_Val_comp_iter<USDT::Probe::finalize_locations()::{lambda(USDT::Location const&, USDT::Location const&)#1}> >(__gnu_cxx::__normal_iterator<USDT::Location*, std::vector<USDT::Location, std::allocator<USDT::Location> > >, __gnu_cxx::__ops::_Val_comp_iter<USDT::Probe::finalize_locations()::{lambda(USDT::Location const&, USDT::Location const&)#1}>)\r\n @ USDT::Probe::finalize_locations()\r\n ... user code ...\r\n```\r\n\r\nTo solve this, we just need to guarantee the strict weak order through the use of `std::tie`. This allows it to have a lexicographical comparison and hence, no more undefined behavior. Performance-wise, this just creates a tuple in place with no copies, so it shouldn't be a big regression.ghprbCommentBody[buildbot, test this please]ghprbGhRepositoryiovisor/bccghprbCredentialsId6d3daf13-69b8-48b1-9c8f-ec5353264113false<a title="Guarantee strict weak order in Probe::finalize_locations" href="https://github.com/iovisor/bcc/pull/3700">PR #3700</a>: Guarantee strict weak order...#122211568637460664bcc-pr #12221222false12229768ABORTED1636996045032https://buildbot.iovisor.org/jenkins/user/danobi/my-views/view/all/job/bcc-pr/1222/git1210https://buildbot.iovisor.org/jenkins/user/danobi/my-views/view/all/job/bcc-pr/label=fc25/1210/1210https://buildbot.iovisor.org/jenkins/user/danobi/my-views/view/all/job/bcc-pr/label=fc26/1210/1210https://buildbot.iovisor.org/jenkins/user/danobi/my-views/view/all/job/bcc-pr/label=fc27/1210/1210https://buildbot.iovisor.org/jenkins/user/danobi/my-views/view/all/job/bcc-pr/label=fc28/1210/1210https://buildbot.iovisor.org/jenkins/user/danobi/my-views/view/all/job/bcc-pr/label=ubuntu1604/1210/1210https://buildbot.iovisor.org/jenkins/user/danobi/my-views/view/all/job/bcc-pr/label=ubuntu1710/1210/1210https://buildbot.iovisor.org/jenkins/user/danobi/my-views/view/all/job/bcc-pr/label=ubuntu1804/1210/