December 26, 2017
On Tuesday, 26 December 2017 at 22:11:18 UTC, Jon Degenhardt wrote:
> On Monday, 25 December 2017 at 17:03:37 UTC, Johan Engelen wrote:
>> I've been writing this article since August, and finally found some time to finish it:
>>
>> http://johanengelen.github.io/ldc/2017/12/25/LDC-and-AddressSanitizer.html
>>
>
> Nice article. Main question / comment is about the need for blacklisting D standard libraries (druntime/phobos). If someone wants to try ASan out on their own code, can they start by ignoring the D standard libraries? And, for programs that use druntime/phobos, will this be effective? If I understand the post, the answer is "yes", but I think it could be more explicit.

Indeed, yes. I've used ASan successfully on the ddmd lexer. "successfully" = I found and fixed an actual bug with it.
Without ASan-enabled standard libs, ASan testing will cover your code and (most) std lib _templated_ code.
A blacklist may be needed for templated std lib code that doesn't work with ASan (yet), either because of a bug in the std lib (not very likely I think) or something else. We need much more testing of LDC+ASan.

> Second comment is related - If the reader was to try instrumenting druntime/phobos along with their own code, how much effort should be expected to correctly blacklist druntime/phobos code? Would many programs have smooth sailing if they took the blacklist published in the post? Or is this early stage enough that some real effort should be expected?

Very early stage. I myself have not worked on ASan-enabled druntime/phobos for more than 30 minutes. Already found some trouble with cpuid functions (inline asm): `fun:_D4core5cpuid*` must be added to the blacklist.
I think the first goal should be to make a blacklist such that all tests pass, adding blacklist items in a "# not reviewed" section. Then afterwards, we can reduce the blacklist bit-by-bit by figuring out exactly why ASan triggers: either a bug, expected behavior, or an ASan bug.
A counterpart to the blacklist file is an `@no_sanitize("address")` magic UDA; to disable ASan and document it inside the code. This should be done in such a way that it is upstreamable. (e.g. version(LDC) static import ldc.attributes, alias no_sanitize = ...)

> Also, if the blacklist file in the post represents a meaningful starting point,

it does

> perhaps it makes sense to check it in and distribute it. This would provide a place for contributors to start making improvements.

Definitely makes sense. I think this should be inside the runtime libraries' repos, right? (So one blacklist for druntime, and another for Phobos).
(I'm even thinking about adding `-fsanitize-blacklist=<...>` to the shipped blacklist in `ldc.conf`.)

I'll figure out how to incorporate your comments into the article, thanks.

cheers,
  Johan

December 28, 2017
On Monday, 25 December 2017 at 17:03:37 UTC, Johan Engelen wrote:
> I've been writing this article since August, and finally found some time to finish it:
>
> http://johanengelen.github.io/ldc/2017/12/25/LDC-and-AddressSanitizer.html

Is it a good fit with /r/programming ?

-Johan
December 29, 2017
On Thursday, 28 December 2017 at 16:29:49 UTC, Johan Engelen wrote:
> On Monday, 25 December 2017 at 17:03:37 UTC, Johan Engelen wrote:
>> I've been writing this article since August, and finally found some time to finish it:
>>
>> http://johanengelen.github.io/ldc/2017/12/25/LDC-and-AddressSanitizer.html
>
> Is it a good fit with /r/programming ?
>
> -Johan

I'd definitely say so.

Atila
January 04, 2018
On 12/25/2017 06:03 PM, Johan Engelen wrote:
> I've been writing this article since August, and finally found some time to finish it:
> 
> http://johanengelen.github.io/ldc/2017/12/25/LDC-and-AddressSanitizer.html

Just built dmd with AddressSanitizer and ran dmd's, druntime's, and phobos' test-suite.

https://issues.dlang.org/show_bug.cgi?id=18189 https://issues.dlang.org/show_bug.cgi?id=18190

Nothing in the D part, not too surprising given dmd's approach to memory management though ;).

-Martin
January 03, 2018
On 1/3/2018 3:16 PM, Martin Nowak wrote:
> https://issues.dlang.org/show_bug.cgi?id=18190

This is a stack overflow caused by having 4096 expression statements. The compiler joins them with a commaexpression, and then recursively traverses it.

> Nothing in the D part, not too surprising given dmd's approach to memory
management though ;).

Stack overflow has nothing to do with memory management.
January 04, 2018
On Wednesday, 3 January 2018 at 23:16:45 UTC, Martin Nowak wrote:
> On 12/25/2017 06:03 PM, Johan Engelen wrote:
>> I've been writing this article since August, and finally found some time to finish it:
>> 
>> http://johanengelen.github.io/ldc/2017/12/25/LDC-and-AddressSanitizer.html
>
> Just built dmd with AddressSanitizer and ran dmd's, druntime's, and phobos' test-suite.

Nice.
Plans to make it part of CI ?

-Johan

January 04, 2018
On 1/3/2018 4:46 PM, Walter Bright wrote:
> On 1/3/2018 3:16 PM, Martin Nowak wrote:
>> https://issues.dlang.org/show_bug.cgi?id=18190
> 
> This is a stack overflow caused by having 4096 expression statements. The compiler joins them with a commaexpression, and then recursively traverses it.
> 
>  > Nothing in the D part, not too surprising given dmd's approach to memory
> management though ;).
> 
> Stack overflow has nothing to do with memory management.

I'm a little curious about the stack overflow. I thought Linux would automatically extend the stack if it overflowed?
January 05, 2018
On Friday, 5 January 2018 at 01:32:50 UTC, Walter Bright wrote:
> On 1/3/2018 4:46 PM, Walter Bright wrote:
>> On 1/3/2018 3:16 PM, Martin Nowak wrote:
>>> https://issues.dlang.org/show_bug.cgi?id=18190
>> 
>> This is a stack overflow caused by having 4096 expression statements. The compiler joins them with a commaexpression, and then recursively traverses it.
>> 
>>  > Nothing in the D part, not too surprising given dmd's approach to memory
>> management though ;).
>> 
>> Stack overflow has nothing to do with memory management.
>
> I'm a little curious about the stack overflow. I thought Linux would automatically extend the stack if it overflowed?

it will, but only up to the rlimit. then it will SIGSEGV.

http://man7.org/linux/man-pages/man2/getrlimit.2.html

1 2
Next ›   Last »