1640030 - Crash in [@ replace_malloc]

Status: RESOLVED WORKSFORME

(Core :: Memory Allocator, defect)

Description

[Andrew McCreight [:mccr8]]

This bug is for crash report bp-65bf9938-0aff-4a76-93db-db4620200521.

Top 10 frames of crashing thread:

0 mozglue.dll replace_malloc memory/replace/phc/PHC.cpp:1122
1 mozglue.dll moz_xmalloc memory/mozalloc/mozalloc.cpp:52
2 xul.dll static IPC::Message::IPDLMessage ipc/chromium/src/chrome/common/ipc_message.cc:108
3 xul.dll mozilla::dom::PBrowserChild::SendSessionStoreUpdate ipc/ipdl/PBrowserChild.cpp:2771
4 xul.dll mozilla::dom::BrowserChild::UpdateSessionStore dom/ipc/BrowserChild.cpp:3910
5  @0xf0a8bf 
6 xul.dll mozilla::dom::PBrowserChild::OnMessageReceived ipc/ipdl/PBrowserChild.cpp:4087
7 xul.dll mozilla::dom::PContentChild::OnMessageReceived ipc/ipdl/PContentChild.cpp:8245
8 xul.dll mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2110
9 xul.dll mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1989

There are a few of these crashes, from not many different installations. The crashes are inside PHC.cpp. I'm not sure what that means.

Comment 1

[Andrew McCreight [:mccr8]]

Nick, any ideas?

Comment 2

[Nicholas Nethercote [inactive]]

Let's see:

• It's a read of address 0x0.
• Line 1122 is just return PageMalloc(Nothing(), aReqSize); within replace_malloc. It doesn't seem possible that could cause a read of 0x0.
• Which suggests that there's something wrong with the stack trace. Maybe there are missing frames below frame 0, which could be in PHC code (e.g. in MaybePageAlloc) or could be in jemalloc itself.
• I don't see anything else of note in that crash report.
• But I do see 18 crash reports like this one, all coming from a single user, 17 of which occurred in a 90 second window. Perhaps a specific problem with their machine/installation/configuration?

Comment 3

[Mike Hommey [:glandium]]

Could be the anti-inlining measures that make the crash stack useless. (We only get the outer-most stack for things that are inlined. The alternative would be the inner-most, which is what we had before, and caused other problems). Downloading the minidump and processing it with windbg would probably give a better stack trace. David, could you check it out?

Comment 4

[(Away)]

The crash is on an aligned movaps instruction attempting to load from an address ending in hex digit 8 -- so not aligned. If we're not seeing this pattern from other installations then I assume it's not the compiler's fault but rather something on this machine.

Comment 5

[Andrew McCreight [:mccr8]]

There's a few other installations. On beta, for instance. But it is not widespread.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:glandium, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.