aw snap with glibc-2.24
Reported by
da_audio...@yahoo.com,
Aug 10 2016
|
|||||||||
Issue descriptionChrome Version : 52.0.2743.116 What steps will reproduce the problem? (1) Execute /usr/bin/chromium What is the expected result? Browser should work as the previous version 52.0.2743.85 did. What happens instead? All tabs display "Aw snap" and do not load the expected URL. See the attached terminal output for the full stack trace. Partial: % chromium Received signal 4 ILL_ILLOPN 556c6dc643e0 #0 0x556c695a8b0e <unknown> #1 0x556c695a8ee9 <unknown> #2 0x7f2945070080 <unknown> #3 0x556c6dc643e0 <unknown> #4 0x556c6a378610 <unknown> #5 0x556c6a378e33 <unknown> #6 0x556c6a376946 <unknown> #7 0x556c6a37708c <unknown> #8 0x556c6ab95965 Received signal 4 ILL_ILLOPN 556c6dc643e0 <unknown> #9 0x556c6ab88d2d <unknown> #10 0x556c6ab89ca0# 0 0x556c695a8b0e <unknown> #1 0x556c695a8ee9 <unknown> #2 0x7f2945070080 <unknown> #3 0x556c6dc643e0 Received signal 6 ... This has been verified by several users who have build chromium-52.0.2743.116 independently. For reference, the Arch Linux package is generated by this PKGBUILD which details build options: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/chromium&id=b155186d59e6b78d0e92faacd24e624c0cbfa0b8 Obviously, the pkgver variable is changed to match 52.0.2743.116 (and the corresponding check sums are also changed).
,
Aug 11 2016
Don't have Arch Linux to test and confirm this. Looping MTV team to take a look and help in triaging this further.
,
Aug 11 2016
,
Aug 12 2016
,
Aug 16 2016
Users also report same issue with Chromium 53 and 54 respectively. Looks like toolchain issue on our side? I'm trying bundled build in the meantime, then I will check with older repository snapshot.
,
Aug 16 2016
And here's the root cause: https://bugzilla.redhat.com/show_bug.cgi?id=1361157
,
Aug 16 2016
Thanks for that link and patch; I am able to build successfully with it.
,
Nov 17 2016
Confirmed both the problem and the patch on OpenMandriva Cooker. The patch looks more like a workaround for a deeper problem though - I'd guess there's a use after free (more precisely, MADV_FREE) somewhere.
,
Nov 18 2016
,
Dec 29 2016
Here's a symbolized stack trace from chromium checkout at 3345559e794bd83da5726b4568a73339e0a01aa4 (refs/heads/master@{#440889}, Dec 28 2016) #0 0x00007ffff179014f in raise () from /lib64/libc.so.6 #1 0x00007ffff179157a in abort () from /lib64/libc.so.6 #2 0x00005555579f6e15 in base::debug::BreakDebugger() () #3 0x0000555557a0fad5 in logging::LogMessage::~LogMessage() () #4 0x0000555557a8274c in base::decommitSystemPages(void*, unsigned long) () #5 0x00005555574fe4a0 in blink::MemoryRegion::decommit() () #6 0x00005555574feca3 in blink::FreePagePool::addFreePage(int, blink::PageMemory*) () #7 0x00005555574fc226 in blink::NormalPageArena::allocatePage() () #8 0x00005555574fc9fc in blink::NormalPageArena::outOfLineAllocate(unsigned long, unsigned long) () #9 0x000055555994c045 in blink::ChromeClientImpl::create(blink::WebViewImpl*) () #10 0x0000555559943986 in blink::WebViewImpl::WebViewImpl(blink::WebViewClient*, blink::WebPageVisibilityState) () #11 0x0000555559944863 in blink::WebView::create(blink::WebViewClient*, blink::WebPageVisibilityState) () #12 0x000055555af0aa54 in content::RenderViewImpl::Initialize(content::mojom::CreateViewParams const&, base::Callback<void (content::RenderWidget*, blink::WebNavigationPolicy, gfx::Rect const&), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&) () #13 0x000055555af0b802 in content::RenderViewImpl::Create(content::CompositorDependencies*, content::mojom::CreateViewParams const&, base::Callback<void (content::RenderWidget*, blink::WebNavigationPolicy, gfx::Rect const&), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&) () #14 0x000055555aef85eb in content::RenderThreadImpl::CreateView(mojo::StructPtr<content::mojom::CreateViewParams>) () #15 0x00005555561e583c in content::mojom::RendererStubDispatch::Accept(content::mojom::Renderer*, mojo::internal::SerializationContext*, mojo::Message*) () #16 0x0000555557bff6f9 in mojo::InterfaceEndpointClient::HandleValidatedMessage(mojo::Message*) () #17 0x0000555558434379 in IPC::(anonymous namespace)::ChannelAssociatedGroupController::AcceptOnProxyThread(mojo::Message) () #18 0x00005555584359e2 in base::internal::Invoker<base::internal::BindState<void (IPC::(anonymous namespace)::ChannelAssociatedGroupController::*)(mojo::Message), scoped_refptr<IPC::(anonymous namespace)::ChannelAssociatedGroupController>, base::internal::PassedWrapper<mojo::Message> >, void ()>::Run(base::internal::BindStateBase*) () #19 0x0000555557a86174 in base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) () #20 0x00005555598e0811 in blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue(blink::scheduler::internal::WorkQueue*, blink::scheduler::LazyNow*) ()
,
Dec 29 2016
,
Dec 29 2016
Uploaded https://codereview.chromium.org/2609553002/ for review. Other useful references: https://bugzilla.redhat.com/show_bug.cgi?id=1361157 https://bugzilla.redhat.com/show_bug.cgi?id=1366894 https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg82915.html https://codereview.chromium.org/2490893002
,
Dec 30 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/447a7a69008678046379b35bc14faad91ad2812f commit 447a7a69008678046379b35bc14faad91ad2812f Author: phajdan.jr <phajdan.jr@chromium.org> Date: Fri Dec 30 07:47:10 2016 Gracefully handle MADV_FREE available at compile time but not run time This fixes "aw snap" with glibc-2.24 . BUG= 636229 Review-Url: https://codereview.chromium.org/2609553002 Cr-Commit-Position: refs/heads/master@{#441020} [modify] https://crrev.com/447a7a69008678046379b35bc14faad91ad2812f/base/allocator/partition_allocator/page_allocator.cc
,
Dec 30 2016
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by barthal...@gmail.com
, Aug 10 2016