TestCases/stress_dtls.c was failing when we ran memprof tests for the first time. The test checks that __tls_get_addr is not in the output for the last run when it is possible for the interceptor __interceptor___tls_get_addr to be in the output from stack dumps. The test actually intends to check that the various __tls_get_addr reports don't get emitted when intercept_tls_get_addr=0. This updates the test to also check for the following : which should ignore the __interceptor___tls_get_addr interceptor.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
https://luci-milo.appspot.com/ui/artifact/raw/invocations/u-swarming-2021-10-04-23-04-00-7ae3a948d9c5c831/tests/MemProfiler-x86_64-linux%20::%20TestCases%2Fstress_dtls.c/results/7705c5d3-01778/artifacts/artifact-content-in-request contains the full log for the failure. One thing worth noting is that I couldn't reproduce this locally, so I'm not entirely sure if this patch is the right way to approach this and it's just sweeping something under the rug.
May be more robust to use ==__tls_get_addr: to ensure the printed line is not __interceptor___tls_get_addr
lgtm, but I like @MaskRay 's suggested change. I ran it locally and don't see any stack traces that involve __libc_memalign, so perhaps that is only used in some environments. I looked at some documentation and it appears to be dependent on the version of libc used. So that could explain why it is only showing up in some cases.