OOM from leveldb::DBImpl::BackgroundCompaction

60 views
Skip to first unread message

Alexander Yashkin

unread,
Apr 19, 2018, 10:45:35 AM4/19/18
to Chromium-dev
Hi all.
I am currently investigating series of crashes in our browser (fork of Chromium) process under windows.
From call stack I see that OnNoMemory is called from string allocation caused by work of leveldb::DBImpl::BackgroundCompaction function.
I see from crashdump that code tries to allocate very large strings with length of 10-17Mb.

I have not found exactly such issue in chromium bug tracker.
Does anybody already met with this problem in chromium? Can anyone with access, look for chromium crash reports with such signature? Are they exist?
I am interested if problem is common to our fork and Chromium or solely our pain. 

Also I am not sure that allocating such large memory chunks from 32bit process is good practice. It seems to me that 32 bit address 
space can become fragmented and could lack continuous regions of such size. WDYT?


WBR, Alexander Yashkin.


Scott Graham

unread,
Apr 19, 2018, 12:29:41 PM4/19/18
to Alexander Yashkin, chromium-dev
Hi Alexander,

I see a few crashes in that function in our crash database. There are not many on Windows, only a handful. Of those, I don't specifically see any that have hit an OOM (but it could be that that's the root cause, I didn't dig in too much).

There was also one UaF reported in that function found in 62 Canary, however it was eventually attributed to unrelated memory corruption and so there was no specific fix made.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/5644f846-1127-4018-bd7f-281a051ec520%40chromium.org.

Alexander Yashkin

unread,
Apr 19, 2018, 2:10:36 PM4/19/18
to Chromium-dev, a-...@yandex-team.ru
Hi Scott, thanks for answer.
Crash happens not exactly in leveldb::DBImpl::BackgroundCompaction but in the functions called by it, I forgot to attach partial stack, here it is:

base::`anonymous namespace'::OnNoMemory
malloc
operator new(unsigned int)
std::_Allocate(unsigned int, unsigned int, bool)
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Reallocate_grow_by<<lambda_ab246b20b9526e2ef7792587e4298a77>, char const*, unsigned int>
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::append(char const* const, unsigned int)
leveldb::BlockBuilder::Add(leveldb::Slice const&, leveldb::Slice const&)
leveldb::TableBuilder::Add(leveldb::Slice const&, leveldb::Slice const&)
leveldb::DBImpl::DoCompactionWork(leveldb::DBImpl::CompactionState*)

I suspect that problem could be caused by memory leak in another component. 
Do you have any advices/tips on finding memory leaks in browser process?

Scott Graham

unread,
Apr 19, 2018, 2:28:04 PM4/19/18
to Alexander Yashkin, chromium-dev
I didn't see any that specifically matched that stack, they were all bad memory accesses in the body of BackgroundCompaction. But again there were very few, so I'm not sure there's much signal there.

I don't have any specific tips on leak hunting, perhaps if it happens on all platforms you could try one where https://www.chromium.org/developers/testing/leaksanitizer works?

Dmitry Skiba

unread,
Apr 20, 2018, 12:47:05 PM4/20/18
to Alexander Yashkin, Chromium-dev
On Thu, Apr 19, 2018 at 11:11 AM Alexander Yashkin <a-...@yandex-team.ru> wrote:
Hi Scott, thanks for answer.
Crash happens not exactly in leveldb::DBImpl::BackgroundCompaction but in the functions called by it, I forgot to attach partial stack, here it is:

base::`anonymous namespace'::OnNoMemory

I think we need to propagate and surface allocation size that caused OnNoMemory. It would make a difference in this case, because if the size is small, then it's probably just low memory situation, not specific to leveldb. But if the size is large (100+ MiB) then it's probably a leveldb issue (i.e. inefficient storage strategy), and is actionable.

This came up before in crbug/747503 (sorry, it's internal), where Chrome for Android crashed during JSON serialization by JSONWriter because std::string:: __grow_by() caused OOM.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/652a3ac8-fd6b-4863-ab5d-9ccc670cd31c%40chromium.org.
Reply all
Reply to author
Forward
0 new messages