Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add address sanitizer (ASAN) support (fix #1002) #1004

Merged
merged 1 commit into from
Oct 28, 2015

Conversation

nicowilliams
Copy link
Contributor

No description provided.

@nicowilliams nicowilliams self-assigned this Oct 28, 2015
@nicowilliams nicowilliams added this to the 1.6 release milestone Oct 28, 2015
@@ -117,7 +122,7 @@ AS_IF([test "x$enable_docs" != "xno"],[
*****************************************************************
* Ruby dependencies for building jq documentation not found. *
* You can still build, install and hack on jq, but the manpage *
* will not be rebuilt and some of the tests won't run. *
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I meant to commit this separately. This fixes vim syntax mis-highlighting.

@nicowilliams
Copy link
Contributor Author

OK, I think it's ready. ASAN is fast enough that one can run with it compiled-in in many cases. I could see releasing executables with and without ASAN.

@nicowilliams
Copy link
Contributor Author

OTOH, it's not as good as valgrind...

dnl Running tests with Valgrind is slow; address sanitizer (ASAN) is
dnl faster.
AC_ARG_ENABLE([asan],
AC_HELP_STRING([--enable-asn], [enable address sanitizer]))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--enable-asan

@dtolnay
Copy link
Member

dtolnay commented Oct 28, 2015

Does asan catch anything valgrind does not? If so, we should run a fourth travis build with asan instead of valgrind.

@nicowilliams
Copy link
Contributor Author

From what I can tell, no, it catches a subset of the classes of errors that valgrind catches. For example, it doesn't catch reads of uninitialized memory. I'm thinking this is useful when there's no valgrind, or -because it's faster than valgrind- during development prior to sending a PR.

@dtolnay
Copy link
Member

dtolnay commented Oct 28, 2015

Okay. Looks good once you fix the typo.

@nicowilliams
Copy link
Contributor Author

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants