-
Notifications
You must be signed in to change notification settings - Fork 47
Add AddressSanitizer
to DEBUG
builds
#1279
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
base: master
Are you sure you want to change the base?
Conversation
#1276 addressed a `Segementation fault`, but from the error alone, the root cause was not obvious: ``` 31168 Segmentation fault: 11 build/cpp_client ``` By adding [`asan`](https://learn.microsoft.com/en-us/cpp/sanitizers/asan) to the `DEBUG` builds, the CI job would've failed with a much more helpful error message: ``` ================================================================= ==37978==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000040 (pc 0x7eff21446d48 bp 0x7efeff67fce0 sp 0x7efeff67fcd0 T22) ==37978==The signal is caused by a READ memory access. ==37978==Hint: address points to the zero page. #0 0x7eff21446d48 in hazelcast::logger::enabled(hazelcast::logger::level) /home/runner/work/hazelcast-cpp-client/hazelcast-cpp-client/hazelcast/src/hazelcast/logger.cpp:71 #1 0x7eff20a05b1d in hazelcast::client::protocol::codec::client_addclusterviewlistener_handler::handle(hazelcast::client::protocol::ClientMessage&) /home/runner/work/hazelcast-cpp-client/hazelcast-cpp-client/hazelcast/generated-sources/src/hazelcast/client/protocol/codec/codecs.cpp:145 {...} AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /home/runner/work/hazelcast-cpp-client/hazelcast-cpp-client/hazelcast/src/hazelcast/logger.cpp:71 in hazelcast::logger::enabled(hazelcast::logger::level) ``` An _alternative_ implementation would've been to hardcode the flags in the `build-unix`/`build-windows` instead.
Co-authored-by: ihsan demir <[email protected]>
Co-authored-by: ihsan demir <[email protected]>
@ihsandemir thanks for your feedback. I was actually waiting for a green PR builder before un-drafting this PR but it seems GitHub gave you a heads-up. The good news is that
...the bad news is that these failures are actually blocking this PR from being merged. What do you think the next steps should be?
|
b7cef7f
to
573b430
Compare
The change in hazelcast#1279 made it obvious that adding configuration for `Debug` builds (e.g. "add an extra compilation argument") was very tedious as it needs to be declared in _each_ workflow and then passed all the way down to the actual scripts that build the code. Instead, it'd be much cleaner if the jobs _only_ declare a release type, and the build scripts react to that with the appropriate actions (e.g. adding some extra debug or whatever). Changes: - migrate the _implementation_ of the `DEBUG` builds into the `build-` scripts - e.g. `WARN_AS_ERROR` can be assumed when `DEBUG` is enabled, rather than being duplicated in each job configuration - remove the architecture to pass these redundant params down - pass `BUILD_TYPE` into the `build-` scripts as an environment variable, as used for other parameters - rename `BUILD_CONFIGURATION` to `BUILD_TYPE` in Windows scripts for consistency - enable `WARN_AS_ERROR` on Windows for consistency This PR also helps to make hazelcast#1279 smaller.
The change in hazelcast#1279 made it obvious that adding configuration for `Debug` builds (e.g. "add an extra compilation argument") was very tedious as it needs to be declared in _each_ workflow and then passed all the way down to the actual scripts that build the code. Instead, it'd be much cleaner if the jobs _only_ declare a release type, and the build scripts react to that with the appropriate actions (e.g. adding some extra debug or whatever). Changes: - migrate the _implementation_ of the `DEBUG` builds into the `build-` scripts - e.g. `WARN_AS_ERROR` can be assumed when `DEBUG` is enabled, rather than being duplicated in each job configuration - remove the architecture to pass these redundant params down - pass `BUILD_TYPE` into the `build-` scripts as an environment variable, as used for other parameters - rename `BUILD_CONFIGURATION` to `BUILD_TYPE` in Windows scripts for consistency - enable `WARN_AS_ERROR` on Windows for consistency This PR also helps to make hazelcast#1279 smaller.
7dfca18
to
7d23115
Compare
7d23115
to
e1a6f1e
Compare
Test leaks may not be significant, still can be fixed later on. I suggest this:
This may be planned in tech debt for C++ client. I do not think we need to block any release if these are just test objects related at the moment. |
scripts/build-windows.bat
Outdated
if "%BUILD_CONFIGURATION%"=="Debug" ( | ||
REM Enable address sanitizer to provide meaningful stack traces | ||
REM Not enabled due to failure with tooling on GitHub Actions | ||
REM https://github.com/actions/runner-images/issues/7739 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue seems to have a solution. why commented out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The solution (explicitly install the "correct" tooling) is non-trivial (what is the correct version for this project? Where does it come from?).
I think have this for a build is enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We specify the VC version used at here Minimum supported we test against VC 2019.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We specify the VC version used at here Minimum supported we test against VC 2019.
Unfortunately I don't know how to translate ^ that ^ into a fix for Windows, hence showing an example implementation with a TODO
for the future.
67b7026
to
7ad4b8b
Compare
The change in #1279 made it obvious that adding configuration for `Debug` builds (e.g. "add an extra compilation argument") was very tedious as it needs to be declared in _each_ workflow and then passed all the way down to the actual scripts that build the code. Instead, it'd be much cleaner if the jobs _only_ declare a release type, and the build scripts react to that with the appropriate actions (e.g. adding some extra debug or whatever). Changes: - migrate the _implementation_ of the `DEBUG` builds into the `build-` scripts - e.g. `WARN_AS_ERROR` can be assumed when `DEBUG` is enabled, rather than being duplicated in each job configuration - remove the architecture to pass these redundant params down - pass `BUILD_TYPE` into the `build-` scripts as an environment variable, as already used for other parameters and for the Windows equivalent (`BUILD_CONFIGURATION`) This PR is the refactor-half of #1279, split out separately to make that PR smaller.
The change in hazelcast#1279 made it obvious that adding configuration for `Debug` builds (e.g. "add an extra compilation argument") was very tedious as it needs to be declared in _each_ workflow and then passed all the way down to the actual scripts that build the code. Instead, it'd be much cleaner if the jobs _only_ declare a release type, and the build scripts react to that with the appropriate actions (e.g. adding some extra debug or whatever). Changes: - migrate the _implementation_ of the `DEBUG` builds into the `build-` scripts - e.g. `WARN_AS_ERROR` can be assumed when `DEBUG` is enabled, rather than being duplicated in each job configuration - remove the architecture to pass these redundant params down - pass `BUILD_TYPE` into the `build-` scripts as an environment variable, as already used for other parameters and for the Windows equivalent (`BUILD_CONFIGURATION`) This PR is the refactor-half of hazelcast#1279, split out separately to make that PR smaller.
The change in hazelcast#1279 made it obvious that adding configuration for `Debug` builds (e.g. "add an extra compilation argument") was very tedious as it needs to be declared in _each_ workflow and then passed all the way down to the actual scripts that build the code. Instead, it'd be much cleaner if the jobs _only_ declare a release type, and the build scripts react to that with the appropriate actions (e.g. adding some extra debug or whatever). Changes: - migrate the _implementation_ of the `DEBUG` builds into the `build-` scripts - e.g. `WARN_AS_ERROR` can be assumed when `DEBUG` is enabled, rather than being duplicated in each job configuration - remove the architecture to pass these redundant params down - pass `BUILD_TYPE` into the `build-` scripts as an environment variable, as already used for other parameters and for the Windows equivalent (`BUILD_CONFIGURATION`) This PR is the refactor-half of hazelcast#1279, split out separately to make that PR smaller.
The change in hazelcast#1279 made it obvious that adding configuration for `Debug` builds (e.g. "add an extra compilation argument") was very tedious as it needs to be declared in _each_ workflow and then passed all the way down to the actual scripts that build the code. Instead, it'd be much cleaner if the jobs _only_ declare a release type, and the build scripts react to that with the appropriate actions (e.g. adding some extra debug or whatever). Changes: - migrate the _implementation_ of the `DEBUG` builds into the `build-` scripts - e.g. `WARN_AS_ERROR` can be assumed when `DEBUG` is enabled, rather than being duplicated in each job configuration - remove the architecture to pass these redundant params down - pass `BUILD_TYPE` into the `build-` scripts as an environment variable, as already used for other parameters and for the Windows equivalent (`BUILD_CONFIGURATION`) This PR is the refactor-half of hazelcast#1279, split out separately to make that PR smaller.
The change in hazelcast#1279 made it obvious that adding configuration for `Debug` builds (e.g. "add an extra compilation argument") was very tedious as it needs to be declared in _each_ workflow and then passed all the way down to the actual scripts that build the code. Instead, it'd be much cleaner if the jobs _only_ declare a release type, and the build scripts react to that with the appropriate actions (e.g. adding some extra debug or whatever). Changes: - migrate the _implementation_ of the `DEBUG` builds into the `build-` scripts - e.g. `WARN_AS_ERROR` can be assumed when `DEBUG` is enabled, rather than being duplicated in each job configuration - remove the architecture to pass these redundant params down - pass `BUILD_TYPE` into the `build-` scripts as an environment variable, as already used for other parameters and for the Windows equivalent (`BUILD_CONFIGURATION`) This PR is the refactor-half of hazelcast#1279, split out separately to make that PR smaller.
The change in #1279 made it obvious that adding configuration for `Debug` builds (e.g. "add an extra compilation argument") was very tedious as it needs to be declared in _each_ workflow and then passed all the way down to the actual scripts that build the code. Instead, it'd be much cleaner if the jobs _only_ declare a release type, and the build scripts react to that with the appropriate actions (e.g. adding some extra debug or whatever). Changes: - migrate the _implementation_ of the `DEBUG` builds into the `build-` scripts - e.g. `WARN_AS_ERROR` can be assumed when `DEBUG` is enabled, rather than being duplicated in each job configuration - remove the architecture to pass these redundant params down - pass `BUILD_TYPE` into the `build-` scripts as an environment variable, as already used for other parameters and for the Windows equivalent (`BUILD_CONFIGURATION`) This PR is the refactor-half of #1279, split out separately to make that PR smaller.
@ihsandemir are you able to review, please? |
@ihsandemir bump :) |
Co-authored-by: ihsan demir <[email protected]>
#1276 addressed a
Segementation fault
, but from the error alone, the root cause was not obvious:By adding
asan
to theDEBUG
builds, the CI job would've failed with a much more helpful error message: