http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
Joost VandeVondele changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #41 from Joost VandeVondele
---
(In reply to Kostya Serebryany from comment #40)
> Is there anything else left in this bug?
> If not, please close this one and open another for the next problem(s)
I'll close it as soon as libbacktra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #40 from Kostya Serebryany ---
Thanks for the feedback!
Is there anything else left in this bug?
If not, please close this one and open another for the next problem(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #39 from Joost VandeVondele
---
(In reply to Sergey Matveev from comment #37)
> I've patched LSan to use the real memset(). At least on my machine this
> brought no performance improvement compared to kcc's latest change (just FYI
> -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #38 from Sergey Matveev ---
(In reply to Jakub Jelinek from comment #28)
> Author: jakub
> Date: Fri Nov 22 21:13:08 2013
> New Revision: 205290
It looks like you use dynamic linking by default. The last time I checked, leak
detection
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #37 from Sergey Matveev ---
I've patched LSan to use the real memset(). At least on my machine this brought
no performance improvement compared to kcc's latest change (just FYI - not
trying to make any point).
As of now, LSan will sti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #36 from Kostya Serebryany ---
(In reply to Jakub Jelinek from comment #34)
> And what is the reason why you want to duplicate the library optimization
> (which for memset/memcpy etc. is highly optimized, in glibc these days
> depends
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #35 from Kostya Serebryany ---
> What I meant is that LSan could clear the memory instead of relying on the
> sanitizer allocator to do it. Then we'd only have to call memset() from the
> LSan runtime.
Right, that's an option. (to c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #34 from Jakub Jelinek ---
And what is the reason why you want to duplicate the library optimization
(which for memset/memcpy etc. is highly optimized, in glibc these days depends
on the CPUs through ifunc etc.)?
I mean, for small size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #33 from Sergey Matveev ---
(In reply to Kostya Serebryany from comment #32)
> > I think standalone LSan should support the max_alloc_fill_size flag.
>
> Mmm. Maybe...
> max_alloc_fill_size in asan is there primarily to protect from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #32 from Kostya Serebryany ---
(In reply to Sergey Matveev from comment #31)
> (In reply to Kostya Serebryany from comment #30)
> > lsan's allocator clears all memory using internal_memset, which is damn
> > slow. (sets on byte at a ti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #31 from Sergey Matveev ---
(In reply to Kostya Serebryany from comment #30)
> lsan's allocator clears all memory using internal_memset, which is damn
> slow. (sets on byte at a time)
>
> asan's allocator doesn't do that (it sets firs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #30 from Kostya Serebryany ---
(In reply to Joost VandeVondele from comment #29)
> I've tried -fsanitize=leak and it works well, thanks!
>
> Concerning the speed, I'm still seeing about 20% slowdown (again, this is
> acceptable from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #29 from Joost VandeVondele
---
I've tried -fsanitize=leak and it works well, thanks!
Concerning the speed, I'm still seeing about 20% slowdown (again, this is
acceptable from my point of view). Under oprofile, the
__sanitizer::int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #28 from Jakub Jelinek ---
Author: jakub
Date: Fri Nov 22 21:13:08 2013
New Revision: 205290
URL: http://gcc.gnu.org/viewcvs?rev=205290&root=gcc&view=rev
Log:
PR sanitizer/59061
* common.opt (static-liblsan): Add.
* config
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #27 from Alexey Samsonov ---
(In reply to Jakub Jelinek from comment #26)
> libbacktrace doesn't use malloc (unless mmap isn't supported), handles
> inline frames just fine and Ian has posted today a patch to support also
> data symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #26 from Jakub Jelinek ---
libbacktrace doesn't use malloc (unless mmap isn't supported), handles inline
frames just fine and Ian has posted today a patch to support also data symbol
lookups. I think I'll post a sanitizer_symbolizer_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #25 from Kostya Serebryany ---
(In reply to Jakub Jelinek from comment #24)
> Just tried to bootstrap/regtest that patch, unfortunately it doesn't build
> at all on i686. Is it meant to work on x86_64 only (or only for
> SANITIZER_WOR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #24 from Jakub Jelinek ---
Just tried to bootstrap/regtest that patch, unfortunately it doesn't build at
all on i686. Is it meant to work on x86_64 only (or only for
SANITIZER_WORDSIZE == 64)?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #23 from Jakub Jelinek ---
Created attachment 31221
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31221&action=edit
gcc49-pr59061.patch
Untested patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #22 from Kostya Serebryany ---
(In reply to Joost VandeVondele from comment #21)
> (In reply to Kostya Serebryany from comment #20)
> > > I our simulation code, it looks like the overhead for leak checking is
> > > about
> > > 20%. I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #21 from Joost VandeVondele
---
(In reply to Kostya Serebryany from comment #20)
> > I our simulation code, it looks like the overhead for leak checking is about
> > 20%. I haven't done very careful measurements yet, since this is mor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #20 from Kostya Serebryany ---
> I our simulation code, it looks like the overhead for leak checking is about
> 20%. I haven't done very careful measurements yet, since this is more or
> less what we're willing to pay to integrate the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #19 from Joost VandeVondele
---
(In reply to Kostya Serebryany from comment #18)
> I don't think we've measured pure-lsan slowdown, but I expect it to be small.
> asan/lsan bring in a different allocator (malloc/free).
> We tried to m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #18 from Kostya Serebryany ---
(In reply to Joost VandeVondele from comment #17)
> (In reply to Sergey Matveev from comment #16)
> >
> > Under the current behavior -fsanitize=address,leak is equivalent to
> > -fsanitize=address.
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #17 from Joost VandeVondele
---
(In reply to Sergey Matveev from comment #16)
>
> Under the current behavior -fsanitize=address,leak is equivalent to
> -fsanitize=address.
>
> We've considered other options, such as making -fsanitiz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #16 from Sergey Matveev ---
(In reply to Kostya Serebryany from comment #11)
> > Easily doable of course, but we should create liblsan as shared
> > library in that case too. What combination of those do you allow? I mean,
> > is
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #15 from Andrew Pinski ---
(In reply to Kostya Serebryany from comment #7)
> >
> > Additionally, it seems important to have -g -fno-omit-frame-pointer in the
> > options. Maybe gcc should add these options for best 'user experience',
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #14 from Alexey Samsonov ---
(In reply to Kostya Serebryany from comment #13)
> > Why don't you use libbacktrace for that? It is not GPL, so Apple and other
>
> I *think* we evaluated libbacktrace over 2 years ago and
> discarded fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
Kostya Serebryany changed:
What|Removed |Added
CC||samsonov at google dot com
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #12 from Jakub Jelinek ---
(In reply to Kostya Serebryany from comment #9)
> We have work-in-progress to make the symbolizer in-process as opposed to
> the current one that is out-of-process (uses pipes):
> https://code.google.com/p/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #11 from Kostya Serebryany ---
> > I am not an expert in the gcc build system so this will have to be done by
> > someone else. Also, I am heavily frightened by the amount of differences
> > between the clang and gcc builds of libsan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #10 from Jakub Jelinek ---
(In reply to Kostya Serebryany from comment #7)
> > > Clang supports -fsanitize=leak which simply links a standalone lsan
> > > library
> > > (no instrumentation at compile time required).
> > > Perhaps gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #9 from Kostya Serebryany ---
(In reply to Joost VandeVondele from comment #8)
> (In reply to Kostya Serebryany from comment #7)
> > -fno-omit-frame-pointer: that may or may not be a good idea, I don't know.
>
> I seem to need it to g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #8 from Joost VandeVondele
---
(In reply to Kostya Serebryany from comment #7)
> -fno-omit-frame-pointer: that may or may not be a good idea, I don't know.
I seem to need it to get good backtraces (i.e. full stack, line numbers etc.)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #7 from Kostya Serebryany ---
> > Clang supports -fsanitize=leak which simply links a standalone lsan library
> > (no instrumentation at compile time required).
> > Perhaps gcc can add such option too.
>
> I agree that such an optio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #6 from Joost VandeVondele
---
(In reply to Kostya Serebryany from comment #5)
> > That's great... works even for Fortran code :-)
> Wow!
well, many thanks to those people making sanitizer happen, also in gcc.
> > In performance-c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #5 from Kostya Serebryany ---
(In reply to Joost VandeVondele from comment #4)
> That's great... works even for Fortran code :-)
Wow!
>
> One more question the docs mention:
>
> In performance-critical scenarios, LSan can also be u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #4 from Joost VandeVondele
---
That's great... works even for Fortran code :-)
One more question the docs mention:
In performance-critical scenarios, LSan can also be used without ASan
instrumentation.
But it is unclear from that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #3 from Kostya Serebryany ---
https://code.google.com/p/address-sanitizer/wiki/LeakSanitizer
I agree, we need to update the gcc doc to mention the URL above.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #2 from Joost VandeVondele
---
(In reply to Kostya Serebryany from comment #1)
> It should be there already:
triggering my report was indeed some vague memory that the recent merge would
bring leaksanitizer... I didn't see it mentio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #1 from Kostya Serebryany ---
It should be there already:
http://gcc.gnu.org/viewcvs?rev=204368&root=gcc&view=rev
Please check.
admittedly, the gcc tree lacks the tests for lsan.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
43 matches
Mail list logo
