Hi,
On Wed, Dec 3, 2014 at 3:59 PM, Kuba Brecka wrote:
> Hi everyone,
>
> I'd like to ask about the various symbolizers that are used by ASan and
> sanitizer_common, and then propose some changes to get better OS X support.
>
> If I understand correctly, the general llvm-symbolizer (and its inte
On Thu, Dec 4, 2014 at 8:06 PM, 'Dmitry Vyukov' via address-sanitizer
wrote:
> You answered your own question about user space :)
Yeah, I hoped someone would rush to overpersuade me...
-Y
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
T
On Thu, Dec 4, 2014 at 5:16 PM, Yury Gribov wrote:
> On 12/04/2014 05:04 PM, Dmitry Vyukov wrote:
>>
>> On Thu, Dec 4, 2014 at 4:48 PM, Yury Gribov wrote:
>>>
>>> On 12/04/2014 03:47 PM, Dmitry Vyukov wrote:
size_in_bytes = -1 instrumentation is too slow to be the default in
k
On 12/04/2014 05:04 PM, Dmitry Vyukov wrote:
On Thu, Dec 4, 2014 at 4:48 PM, Yury Gribov wrote:
On 12/04/2014 03:47 PM, Dmitry Vyukov wrote:
size_in_bytes = -1 instrumentation is too slow to be the default in
kernel.
If we want to pursue this, I propose a different scheme.
Handle 8+ byte acc
On Thu, Dec 4, 2014 at 4:48 PM, Yury Gribov wrote:
> On 12/04/2014 03:47 PM, Dmitry Vyukov wrote:
>>
>> size_in_bytes = -1 instrumentation is too slow to be the default in
>> kernel.
>>
>> If we want to pursue this, I propose a different scheme.
>> Handle 8+ byte accesses as 1/2/4 accesses. No cha
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 361 by jon34056...@gmail.com: CHECK failed (assert() tls + stack)
on Linux in 32bit threaded
https://code.google.com/p/address-sanitizer/issues/detail?id=361
What steps will reproduce the problem?
1. Build clang+compiler-rt
On 12/04/2014 03:47 PM, Dmitry Vyukov wrote:
size_in_bytes = -1 instrumentation is too slow to be the default in kernel.
If we want to pursue this, I propose a different scheme.
Handle 8+ byte accesses as 1/2/4 accesses. No changes to 1/2/4 access handling.
Currently when we allocate, say, 17-by
+address-sanitizer
Please don't hurry with it.
Do you have any numbers on how frequent are unaligned accesses in
kernel? Is it worth addressing at this cost?
size_in_bytes = -1 instrumentation is too slow to be the default in kernel.
If we want to pursue this, I propose a different scheme.
Hand
Side note: IIRC both atos and addr2line are inaccurate when it comes
to -gline-tables-only debug info. Though it's fine to have atos as a
fallback.
Regarding symbolization on the test machines, do you actually need it?
I suspect we aren't talking about continuous builds for which it
should be easy
In-process symbolizer sometimes makes deployment easy, as you don't need to
carry an extra library or binary. For the same reason we prefer linking
runtime library statically where possible.
AFAIK, libbacktrace is used in gcc asan only.
Another internal symbolizer can be found here:
https://code.
Comment #18 on issue 330 by mguse...@gmail.com: Support re-exec of
sanitized executable with preloading libasan on Linux and Android
https://code.google.com/p/address-sanitizer/issues/detail?id=330
Ping.
I still wonder about Reexec. In current design MaybeReexec part of Asan
runtime is not
11 matches
Mail list logo