search

theRockLiu / address-sanitizer

Automatically exported from code.google.com/p/address-sanitizer
1 stars 0 forks source link

stack depot grows uncontrollably on chrome #177

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
1. build asan-ified chrome
2. run it on some google-docs file
3. press F5 (reload) periodically 

The memory usage will grow endlessly. 
The culprit is stack depot -- it grows and grows and grows. 
I suspect that we have too many frames from V8 and those frames
change when we reload a page. 

More info will follow.

Original issue reported on code.google.com by konstant...@gmail.com on 12 Apr 2013 at 9:31

GoogleCodeExporter commented 9 years ago 
Update: there is often a garbage in the last frame (or two!). E.g. I am seeing 
stack traces like these: 

STACK 3 0x7f05bf66cca3 0x7f05b88a3a89 0x60400000d4d0 
STACK 3 0x7f05bf66cca3 0x7f05b88a3a89 0x00000000000e 
STACK 3 0x7f05bf66cca3 0x7f05b88a3a89 0x7f05be1e5d28 
STACK 3 0x7f05bf66cca3 0x7f05b88a3a89 0x000000000000 
STACK 3 0x7f05bf66cca3 0x7f05b88a3a89 0x7f05c9644b00 
STACK 3 0x7f05bf66cca3 0x7f05b88a3a89 0x484341435f455355 

0x7f05b88a3a89 comes from a system lib which has no frame pointers.
so the following frame is an arbitrary garbage.

Original comment by konstant...@gmail.com on 12 Apr 2013 at 11:52

GoogleCodeExporter commented 9 years ago 
Removing all last frames will only save ~5%.

My initial idea about V8 seems to be right: lots of stacks look like this:
... 0x7fe54c4e15fc 0x7fe54c609bad 0x38d4dc3062ee 0x38d4dc3162b1 0x38d4dc30b654 
0x38d4dc325cde 0x38d4dc3079f7 0x7fe54c0e51e3 0x7fe54c0ead15 ... 

(0x38d4... is from V8)

Original comment by konstant...@gmail.com on 12 Apr 2013 at 12:50

GoogleCodeExporter commented 9 years ago 
Just FTR, attached is the dump of all stack traces in a typical chrome process
with google docs after pressing reload a few times.
If all V8 frames (in this process they start at 0x38) are replaced with a 
single dummy frame, we could reduce the number of traces by 5x. 
Not sure if that's easy to do though. 

This issue affects only long-running chrome processes (or other stuff with JITs)
and have a clear workaround (e.g. ASAN_OPTIONS=malloc_context_size=5), so 
I am lowering the priority.

Original comment by konstant...@gmail.com on 12 Apr 2013 at 2:49

Attachments: