Skip to content
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

Jump to bottom

LeakSanitizer fails to detect an "obvious" leak #373

Closed
ramosian-glider opened this issue Sep 1, 2015 · 8 comments
Closed

LeakSanitizer fails to detect an "obvious" leak #373

ramosian-glider opened this issue Sep 1, 2015 · 8 comments
Labels
Priority-Medium ProjectAddressSanitizer Status-Accepted Type-Defect

Comments

@ramosian-glider
Copy link
Member

Originally reported on Google Code with ID 373

int main() {
  new int[10];
}

The leak is reported at -O0, but not at -O1 or higher.

It sounds like with LSan we should treat memory allocations as having side effects
and never optimize them out. The problem is, we don't know about LSan at compilation
time. We could do this in all ASan builds.

Reported by eugenis@google.com on 2015-01-15 09:55:29
@ramosian-glider
Copy link
Member Author 

Somewhat related: MSan suffers from another case of LLVM assuming operator new does
not have any side effects (and in MSan it does: poisoning of memory).

MSan adds "-fno-assume-sane-operator-new" in the driver.
http://llvm.org/bugs/show_bug.cgi?id=16386

Reported by eugenis@google.com on 2015-01-15 10:06:31

@ramosian-glider
Copy link
Member Author 

In your example, the call gets optimized out at -01 or higher regardless of whether
-fno-assume-sane-operator-new is present.

The original case where this came up actually looked a bit different:

T foo = *(new T);

It's pretty hard to write a test for this, though. So far, in every test I've come
up with, the call gets optimized out at -O2 regardless of whether -fno-assume-sane-operator-new
is present.

Reported by earthdok@chromium.org on 2015-02-17 14:54:07

@ramosian-glider
Copy link
Member Author 

(Oh, and at -O lower than 1/2, respectively, it never gets optimized out, again, regardless
of -fno-assume-sane-operator-new).

Reported by earthdok@chromium.org on 2015-02-17 14:54:59

@ramosian-glider
Copy link
Member Author 

I've committed the flag under r229498 anyway. Let's call it a day.

Reported by earthdok@google.com on 2015-02-17 15:12:03

  • Status changed: Fixed

@ramosian-glider
Copy link
Member Author 

But it does not do anything, how come this is 'fixed'?

Reported by eugenis@google.com on 2015-02-17 15:14:54

@ramosian-glider
Copy link
Member Author

Reported by earthdok@google.com on 2015-02-17 15:21:30

  • Status changed: Accepted

@ramosian-glider
Copy link
Member Author 

Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:06:35

  • Labels added: ProjectAddressSanitizer

@kcc kcc mentioned this issue Dec 1, 2015
Open
@kcc
Copy link
Contributor

kcc commented Dec 1, 2015

Closing in favor #374

@kcc kcc closed this as completed Dec 1, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Priority-Medium ProjectAddressSanitizer Status-Accepted Type-Defect
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ramosian-glider @kcc