How to make AddressSanitizer not check third party libraries












1















I am working on a C++ cmake project. Apart from my own source code, my project uses a lot of third party libraries. So, I am using shared libraries (with .so extension) which are present in /usr/local/lib and for some the code is present in /usr/local/include. (like I am using eigen library which is present in /usr/local/include/eigen3/).



How can I make sure that the Address Sanitizer only checks my source code and not any standard or third party libraries ??



PS : Currently, I am using Address Sanitizer like below :



ADD_COMPILE_OPTIONS(-O0 -g -Wall -fsanitize=address -fno-omit-frame-pointer)
SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsanitize=address")


And I am using gcc with version :



gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609










share|improve this question

























  • Not sure why you are using -fsanitize=address. It might be helpful to include more reasoning. The gcc documentation states Memory access instructions are instrumented to detect out-of-bounds and use-after-free bugs.. So, this is mainly a debugging option. Is your third-party library violating access rules? Can you just turn the flag off when you are not doing unit test on your own code? The questions may seem naive, but that is because we do not have a good explanation for what you are trying to accomplish.

    – John Murray
    Nov 20 '18 at 13:03













  • There are still a lot of memory bugs which gcc can't detect. AddressSanitizer is a tool specifically made for that purpose. So, I am trying to test my project for any kind of memory issues. Since my code uses a lot of third party code as well, the source files of which are directly accessed, I am getting a lot of bugs in those as well. So, I am looking for a way by which I can mention what part of code Address Sanitizer should not check

    – mascot
    Nov 22 '18 at 9:17


















1















I am working on a C++ cmake project. Apart from my own source code, my project uses a lot of third party libraries. So, I am using shared libraries (with .so extension) which are present in /usr/local/lib and for some the code is present in /usr/local/include. (like I am using eigen library which is present in /usr/local/include/eigen3/).



How can I make sure that the Address Sanitizer only checks my source code and not any standard or third party libraries ??



PS : Currently, I am using Address Sanitizer like below :



ADD_COMPILE_OPTIONS(-O0 -g -Wall -fsanitize=address -fno-omit-frame-pointer)
SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsanitize=address")


And I am using gcc with version :



gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609










share|improve this question

























  • Not sure why you are using -fsanitize=address. It might be helpful to include more reasoning. The gcc documentation states Memory access instructions are instrumented to detect out-of-bounds and use-after-free bugs.. So, this is mainly a debugging option. Is your third-party library violating access rules? Can you just turn the flag off when you are not doing unit test on your own code? The questions may seem naive, but that is because we do not have a good explanation for what you are trying to accomplish.

    – John Murray
    Nov 20 '18 at 13:03













  • There are still a lot of memory bugs which gcc can't detect. AddressSanitizer is a tool specifically made for that purpose. So, I am trying to test my project for any kind of memory issues. Since my code uses a lot of third party code as well, the source files of which are directly accessed, I am getting a lot of bugs in those as well. So, I am looking for a way by which I can mention what part of code Address Sanitizer should not check

    – mascot
    Nov 22 '18 at 9:17
















1












1








1








I am working on a C++ cmake project. Apart from my own source code, my project uses a lot of third party libraries. So, I am using shared libraries (with .so extension) which are present in /usr/local/lib and for some the code is present in /usr/local/include. (like I am using eigen library which is present in /usr/local/include/eigen3/).



How can I make sure that the Address Sanitizer only checks my source code and not any standard or third party libraries ??



PS : Currently, I am using Address Sanitizer like below :



ADD_COMPILE_OPTIONS(-O0 -g -Wall -fsanitize=address -fno-omit-frame-pointer)
SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsanitize=address")


And I am using gcc with version :



gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609










share|improve this question
















I am working on a C++ cmake project. Apart from my own source code, my project uses a lot of third party libraries. So, I am using shared libraries (with .so extension) which are present in /usr/local/lib and for some the code is present in /usr/local/include. (like I am using eigen library which is present in /usr/local/include/eigen3/).



How can I make sure that the Address Sanitizer only checks my source code and not any standard or third party libraries ??



PS : Currently, I am using Address Sanitizer like below :



ADD_COMPILE_OPTIONS(-O0 -g -Wall -fsanitize=address -fno-omit-frame-pointer)
SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsanitize=address")


And I am using gcc with version :



gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609







c++ gcc cmake address-sanitizer






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 20 '18 at 15:09









yugr

7,20921443




7,20921443










asked Nov 20 '18 at 12:40









mascotmascot

113




113













  • Not sure why you are using -fsanitize=address. It might be helpful to include more reasoning. The gcc documentation states Memory access instructions are instrumented to detect out-of-bounds and use-after-free bugs.. So, this is mainly a debugging option. Is your third-party library violating access rules? Can you just turn the flag off when you are not doing unit test on your own code? The questions may seem naive, but that is because we do not have a good explanation for what you are trying to accomplish.

    – John Murray
    Nov 20 '18 at 13:03













  • There are still a lot of memory bugs which gcc can't detect. AddressSanitizer is a tool specifically made for that purpose. So, I am trying to test my project for any kind of memory issues. Since my code uses a lot of third party code as well, the source files of which are directly accessed, I am getting a lot of bugs in those as well. So, I am looking for a way by which I can mention what part of code Address Sanitizer should not check

    – mascot
    Nov 22 '18 at 9:17





















  • Not sure why you are using -fsanitize=address. It might be helpful to include more reasoning. The gcc documentation states Memory access instructions are instrumented to detect out-of-bounds and use-after-free bugs.. So, this is mainly a debugging option. Is your third-party library violating access rules? Can you just turn the flag off when you are not doing unit test on your own code? The questions may seem naive, but that is because we do not have a good explanation for what you are trying to accomplish.

    – John Murray
    Nov 20 '18 at 13:03













  • There are still a lot of memory bugs which gcc can't detect. AddressSanitizer is a tool specifically made for that purpose. So, I am trying to test my project for any kind of memory issues. Since my code uses a lot of third party code as well, the source files of which are directly accessed, I am getting a lot of bugs in those as well. So, I am looking for a way by which I can mention what part of code Address Sanitizer should not check

    – mascot
    Nov 22 '18 at 9:17



















Not sure why you are using -fsanitize=address. It might be helpful to include more reasoning. The gcc documentation states Memory access instructions are instrumented to detect out-of-bounds and use-after-free bugs.. So, this is mainly a debugging option. Is your third-party library violating access rules? Can you just turn the flag off when you are not doing unit test on your own code? The questions may seem naive, but that is because we do not have a good explanation for what you are trying to accomplish.

– John Murray
Nov 20 '18 at 13:03







Not sure why you are using -fsanitize=address. It might be helpful to include more reasoning. The gcc documentation states Memory access instructions are instrumented to detect out-of-bounds and use-after-free bugs.. So, this is mainly a debugging option. Is your third-party library violating access rules? Can you just turn the flag off when you are not doing unit test on your own code? The questions may seem naive, but that is because we do not have a good explanation for what you are trying to accomplish.

– John Murray
Nov 20 '18 at 13:03















There are still a lot of memory bugs which gcc can't detect. AddressSanitizer is a tool specifically made for that purpose. So, I am trying to test my project for any kind of memory issues. Since my code uses a lot of third party code as well, the source files of which are directly accessed, I am getting a lot of bugs in those as well. So, I am looking for a way by which I can mention what part of code Address Sanitizer should not check

– mascot
Nov 22 '18 at 9:17







There are still a lot of memory bugs which gcc can't detect. AddressSanitizer is a tool specifically made for that purpose. So, I am trying to test my project for any kind of memory issues. Since my code uses a lot of third party code as well, the source files of which are directly accessed, I am getting a lot of bugs in those as well. So, I am looking for a way by which I can mention what part of code Address Sanitizer should not check

– mascot
Nov 22 '18 at 9:17














1 Answer
1






active

oldest

votes


















2














AddressSanitizer works by inserting code during the compilation (with the -fsanitize=address flag). So most code in third party libraries your code links to will be unaffected and not checked by AddressSanitizer, as they are already built into shared library files. If 3rd party calls standard function (memset, etc.), it'll still be checked.



Code in header files and header-only libraries such as Eigen are a special case, as all Eigen code gets directly inserted into your source files (through includes) and thus is also compiled with -fsanitize=address.



As the compiler doesn't differentiate between your code and included 3rd party code, there is no way to disable sanitizers for header-only 3rd party code.



In practice this does not usually cause any issues though. When using clang, you can create a sanitize-blacklist file to hide unwanted false positives (that you cannot fix upstream). Unfortunately gcc does not yet support blacklists.






share|improve this answer


























  • "most third party libraries your code links to will be unaffected and not checked by AddressSanitizer" - if 3rd party calls standard function (memset, etc.) it'll still be checked.

    – yugr
    Nov 20 '18 at 15:07











  • "just add it to your local sanitize-blacklist file" - unfortunately OP uses gcc which does not support blacklists.

    – yugr
    Nov 20 '18 at 15:08











  • Thanks for the corrections @yugr, I incorporated them into the answer. Feel free to edit the answer directly if you think it needs further improvement.

    – w-m
    Nov 20 '18 at 15:47











  • @w-m Thanks for your answer. I can see the problem. I am getting bugs in all those third party codes whose source files are directly accessed by my code. sanitize-blacklist seems like the option I am looking for. I will try this one.

    – mascot
    Nov 22 '18 at 9:22











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53393213%2fhow-to-make-addresssanitizer-not-check-third-party-libraries%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









2














AddressSanitizer works by inserting code during the compilation (with the -fsanitize=address flag). So most code in third party libraries your code links to will be unaffected and not checked by AddressSanitizer, as they are already built into shared library files. If 3rd party calls standard function (memset, etc.), it'll still be checked.



Code in header files and header-only libraries such as Eigen are a special case, as all Eigen code gets directly inserted into your source files (through includes) and thus is also compiled with -fsanitize=address.



As the compiler doesn't differentiate between your code and included 3rd party code, there is no way to disable sanitizers for header-only 3rd party code.



In practice this does not usually cause any issues though. When using clang, you can create a sanitize-blacklist file to hide unwanted false positives (that you cannot fix upstream). Unfortunately gcc does not yet support blacklists.






share|improve this answer


























  • "most third party libraries your code links to will be unaffected and not checked by AddressSanitizer" - if 3rd party calls standard function (memset, etc.) it'll still be checked.

    – yugr
    Nov 20 '18 at 15:07











  • "just add it to your local sanitize-blacklist file" - unfortunately OP uses gcc which does not support blacklists.

    – yugr
    Nov 20 '18 at 15:08











  • Thanks for the corrections @yugr, I incorporated them into the answer. Feel free to edit the answer directly if you think it needs further improvement.

    – w-m
    Nov 20 '18 at 15:47











  • @w-m Thanks for your answer. I can see the problem. I am getting bugs in all those third party codes whose source files are directly accessed by my code. sanitize-blacklist seems like the option I am looking for. I will try this one.

    – mascot
    Nov 22 '18 at 9:22
















2














AddressSanitizer works by inserting code during the compilation (with the -fsanitize=address flag). So most code in third party libraries your code links to will be unaffected and not checked by AddressSanitizer, as they are already built into shared library files. If 3rd party calls standard function (memset, etc.), it'll still be checked.



Code in header files and header-only libraries such as Eigen are a special case, as all Eigen code gets directly inserted into your source files (through includes) and thus is also compiled with -fsanitize=address.



As the compiler doesn't differentiate between your code and included 3rd party code, there is no way to disable sanitizers for header-only 3rd party code.



In practice this does not usually cause any issues though. When using clang, you can create a sanitize-blacklist file to hide unwanted false positives (that you cannot fix upstream). Unfortunately gcc does not yet support blacklists.






share|improve this answer


























  • "most third party libraries your code links to will be unaffected and not checked by AddressSanitizer" - if 3rd party calls standard function (memset, etc.) it'll still be checked.

    – yugr
    Nov 20 '18 at 15:07











  • "just add it to your local sanitize-blacklist file" - unfortunately OP uses gcc which does not support blacklists.

    – yugr
    Nov 20 '18 at 15:08











  • Thanks for the corrections @yugr, I incorporated them into the answer. Feel free to edit the answer directly if you think it needs further improvement.

    – w-m
    Nov 20 '18 at 15:47











  • @w-m Thanks for your answer. I can see the problem. I am getting bugs in all those third party codes whose source files are directly accessed by my code. sanitize-blacklist seems like the option I am looking for. I will try this one.

    – mascot
    Nov 22 '18 at 9:22














2












2








2







AddressSanitizer works by inserting code during the compilation (with the -fsanitize=address flag). So most code in third party libraries your code links to will be unaffected and not checked by AddressSanitizer, as they are already built into shared library files. If 3rd party calls standard function (memset, etc.), it'll still be checked.



Code in header files and header-only libraries such as Eigen are a special case, as all Eigen code gets directly inserted into your source files (through includes) and thus is also compiled with -fsanitize=address.



As the compiler doesn't differentiate between your code and included 3rd party code, there is no way to disable sanitizers for header-only 3rd party code.



In practice this does not usually cause any issues though. When using clang, you can create a sanitize-blacklist file to hide unwanted false positives (that you cannot fix upstream). Unfortunately gcc does not yet support blacklists.






share|improve this answer















AddressSanitizer works by inserting code during the compilation (with the -fsanitize=address flag). So most code in third party libraries your code links to will be unaffected and not checked by AddressSanitizer, as they are already built into shared library files. If 3rd party calls standard function (memset, etc.), it'll still be checked.



Code in header files and header-only libraries such as Eigen are a special case, as all Eigen code gets directly inserted into your source files (through includes) and thus is also compiled with -fsanitize=address.



As the compiler doesn't differentiate between your code and included 3rd party code, there is no way to disable sanitizers for header-only 3rd party code.



In practice this does not usually cause any issues though. When using clang, you can create a sanitize-blacklist file to hide unwanted false positives (that you cannot fix upstream). Unfortunately gcc does not yet support blacklists.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 20 '18 at 15:45

























answered Nov 20 '18 at 13:10









w-mw-m

6,2242333




6,2242333













  • "most third party libraries your code links to will be unaffected and not checked by AddressSanitizer" - if 3rd party calls standard function (memset, etc.) it'll still be checked.

    – yugr
    Nov 20 '18 at 15:07











  • "just add it to your local sanitize-blacklist file" - unfortunately OP uses gcc which does not support blacklists.

    – yugr
    Nov 20 '18 at 15:08











  • Thanks for the corrections @yugr, I incorporated them into the answer. Feel free to edit the answer directly if you think it needs further improvement.

    – w-m
    Nov 20 '18 at 15:47











  • @w-m Thanks for your answer. I can see the problem. I am getting bugs in all those third party codes whose source files are directly accessed by my code. sanitize-blacklist seems like the option I am looking for. I will try this one.

    – mascot
    Nov 22 '18 at 9:22



















  • "most third party libraries your code links to will be unaffected and not checked by AddressSanitizer" - if 3rd party calls standard function (memset, etc.) it'll still be checked.

    – yugr
    Nov 20 '18 at 15:07











  • "just add it to your local sanitize-blacklist file" - unfortunately OP uses gcc which does not support blacklists.

    – yugr
    Nov 20 '18 at 15:08











  • Thanks for the corrections @yugr, I incorporated them into the answer. Feel free to edit the answer directly if you think it needs further improvement.

    – w-m
    Nov 20 '18 at 15:47











  • @w-m Thanks for your answer. I can see the problem. I am getting bugs in all those third party codes whose source files are directly accessed by my code. sanitize-blacklist seems like the option I am looking for. I will try this one.

    – mascot
    Nov 22 '18 at 9:22

















"most third party libraries your code links to will be unaffected and not checked by AddressSanitizer" - if 3rd party calls standard function (memset, etc.) it'll still be checked.

– yugr
Nov 20 '18 at 15:07





"most third party libraries your code links to will be unaffected and not checked by AddressSanitizer" - if 3rd party calls standard function (memset, etc.) it'll still be checked.

– yugr
Nov 20 '18 at 15:07













"just add it to your local sanitize-blacklist file" - unfortunately OP uses gcc which does not support blacklists.

– yugr
Nov 20 '18 at 15:08





"just add it to your local sanitize-blacklist file" - unfortunately OP uses gcc which does not support blacklists.

– yugr
Nov 20 '18 at 15:08













Thanks for the corrections @yugr, I incorporated them into the answer. Feel free to edit the answer directly if you think it needs further improvement.

– w-m
Nov 20 '18 at 15:47





Thanks for the corrections @yugr, I incorporated them into the answer. Feel free to edit the answer directly if you think it needs further improvement.

– w-m
Nov 20 '18 at 15:47













@w-m Thanks for your answer. I can see the problem. I am getting bugs in all those third party codes whose source files are directly accessed by my code. sanitize-blacklist seems like the option I am looking for. I will try this one.

– mascot
Nov 22 '18 at 9:22





@w-m Thanks for your answer. I can see the problem. I am getting bugs in all those third party codes whose source files are directly accessed by my code. sanitize-blacklist seems like the option I am looking for. I will try this one.

– mascot
Nov 22 '18 at 9:22




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53393213%2fhow-to-make-addresssanitizer-not-check-third-party-libraries%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

鏡平學校

ꓛꓣだゔៀៅຸ໢ທຮ໕໒ ,ໂ'໥໓າ໼ឨឲ៵៭ៈゎゔit''䖳𥁄卿' ☨₤₨こゎもょの;ꜹꟚꞖꞵꟅꞛေၦေɯ,ɨɡ𛃵𛁹ޝ޳ޠ޾,ޤޒޯ޾𫝒𫠁သ𛅤チョ'サノބޘދ𛁐ᶿᶇᶀᶋᶠ㨑㽹⻮ꧬ꧹؍۩وَؠ㇕㇃㇪ ㇦㇋㇋ṜẰᵡᴠ 軌ᵕ搜۳ٰޗޮ޷ސޯ𫖾𫅀ल, ꙭ꙰ꚅꙁꚊꞻꝔ꟠Ꝭㄤﺟޱސꧨꧼ꧴ꧯꧽ꧲ꧯ'⽹⽭⾁⿞⼳⽋២៩ញណើꩯꩤ꩸ꩮᶻᶺᶧᶂ𫳲𫪭𬸄𫵰𬖩𬫣𬊉ၲ𛅬㕦䬺𫝌𫝼,,𫟖𫞽ហៅ஫㆔ాఆఅꙒꚞꙍ,Ꙟ꙱エ ,ポテ,フࢰࢯ𫟠𫞶 𫝤𫟠ﺕﹱﻜﻣ𪵕𪭸𪻆𪾩𫔷ġ,ŧآꞪ꟥,ꞔꝻ♚☹⛵𛀌ꬷꭞȄƁƪƬșƦǙǗdžƝǯǧⱦⱰꓕꓢႋ神 ဴ၀க௭எ௫ឫោ ' េㇷㇴㇼ神ㇸㇲㇽㇴㇼㇻㇸ'ㇸㇿㇸㇹㇰㆣꓚꓤ₡₧ ㄨㄟ㄂ㄖㄎ໗ツڒذ₶।ऩछएोञयूटक़कयँृी,冬'𛅢𛅥ㇱㇵㇶ𥄥𦒽𠣧𠊓𧢖𥞘𩔋цѰㄠſtʯʭɿʆʗʍʩɷɛ,əʏダヵㄐㄘR{gỚṖḺờṠṫảḙḭᴮᵏᴘᵀᵷᵕᴜᴏᵾq﮲ﲿﴽﭙ軌ﰬﶚﶧ﫲Ҝжюїкӈㇴffצּ﬘﭅﬈軌'ffistfflſtffतभफɳɰʊɲʎ𛁱𛁖𛁮𛀉 𛂯𛀞నఋŀŲ 𫟲𫠖𫞺ຆຆ ໹້໕໗ๆทԊꧢꧠ꧰ꓱ⿝⼑ŎḬẃẖỐẅ ,ờỰỈỗﮊDžȩꭏꭎꬻ꭮ꬿꭖꭥꭅ㇭神 ⾈ꓵꓑ⺄㄄ㄪㄙㄅㄇstA۵䞽ॶ𫞑𫝄㇉㇇゜軌𩜛𩳠Jﻺ‚Üမ႕ႌႊၐၸဓၞၞၡ៸wyvtᶎᶪᶹစဎ꣡꣰꣢꣤ٗ؋لㇳㇾㇻㇱ㆐㆔,,㆟Ⱶヤマފ޼ޝަݿݞݠݷݐ',ݘ,ݪݙݵ𬝉𬜁𫝨𫞘くせぉて¼óû×ó£…𛅑הㄙくԗԀ5606神45,神796'𪤻𫞧ꓐ㄁ㄘɥɺꓵꓲ3''7034׉ⱦⱠˆ“𫝋ȍ,ꩲ軌꩷ꩶꩧꩫఞ۔فڱێظペサ神ナᴦᵑ47 9238їﻂ䐊䔉㠸﬎ffiﬣ,לּᴷᴦᵛᵽ,ᴨᵤ ᵸᵥᴗᵈꚏꚉꚟ⻆rtǟƴ𬎎

Why https connections are so slow when debugging (stepping over) in Java?