Sorry for the late reply; v8-dev is noisy and mails tend to get overlooked (but we're in the process of changing that!).
I don't think the CL you've mentioned has something to do with the failure. It deals with *double alignment*, i.e. 8-byte alignment, whereas the failing DCHECK asserts 4-byte alignment. The requirement it guards hasn't changed (ever!) and isn't about to change (ever!). It's looking like the GC is stumbling over an invalid object; more specifically: it looks at value that's supposed to be a pointer to a code entry, but such pointers must be (at least) 4-byte aligned, and this value isn't. Such corruption can have all sorts of reasons. Which V8 version exactly are you using? A fix for a crasher involving SlotsBuffer::UpdateSlots was merged to the 4.5 branch as 4.5.103.24. AFAIK it manifested itself differently, but then again it might be related without anyone realizing it... On Wed, Sep 2, 2015 at 1:22 PM, Robert Norlander <[email protected]> wrote: > Hi, v8 developers! > > I was hoping to be able to get some guidance from you about a problem that > we've been seeing. The problem is that we've seen a failing assert on two > of our platforms, one is ARM based and one is MIPS based, so it seems that > it is not specific to one architecture. This is the call stack that we're > given: > > #0 0xb33554dc in base::debug::(anonymous > namespace)::StackDumpSignalHandler(int, > siginfo_t*, void*) () > #1 <signal handler called> > #2 0xb33554dc in base::debug::(anonymous > namespace)::StackDumpSignalHandler(int, siginfo_t*, void*) () > #3 <signal handler called> #4 0xb2753518 in raise () > #5 0xb27548e4 in abort () #6 0xb421204e in v8::base::OS::Abort() () > #7 0xb420e656 in V8_Fatal () > #8 0xb40577b0 in v8::internal::ObjectVisitor::VisitCodeEntry(unsigned > char*) () > #9 0xb3f89df4 in > v8::internal::SlotsBuffer::UpdateSlots(v8::internal::Heap*) () > #10 0xb3f8e186 in > v8::internal::MarkCompactCollector::EvacuateNewSpaceAndCandidates() () > #11 0xb3f8f89e in v8::internal::MarkCompactCollector::SweepSpaces() () > #12 0xb3f9219c in v8::internal::MarkCompactCollector::CollectGarbage() () > #13 0xb3f72a4a in v8::internal::Heap::MarkCompact() () > #14 0xb3f765b6 in > v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, > v8::GCCallbackFlags) () > #15 0xb3f76780 in > v8::internal::Heap::CollectGarbage(v8::internal::GarbageCollector, char > const*, char const*, v8::GCCallbackFlags) () > #16 0xb3f76ab2 in v8::internal::Heap::CollectAllAvailableGarbage(char > const*) () > #17 0xb3dd4bbe in v8::Isolate::LowMemoryNotification() () > > And the failing assert: > > # > # Fatal error in ../../v8/src/objects-inl.h, line 1468 > # Check failed: (reinterpret_cast<intptr_t>(address) & > ::v8::internal::kHeapObjectTagMask) == 0. > # > > The assert seems to be failing because it has detected unaligned memory > (at least - the DCHECK is called DCHECK_TAG_ALIGNED), and based on that > I've been trying to find potential patches causing the problem. Among other > candidates, I found this one which seemed relevant, especially because of > the last comment: > > https://codereview.chromium.org/1141523002 > "In follow-up CLs the scavenger and the MC collector should also respect > the unalignment of heap numbers." > > Since the assert seems to be happening during GC, this sounds suspicious. > I should also mention that we're currently using v4.5.103 of v8. > > It takes a very long time to reproduce the issue so it is difficult to > bisect. I haven't worked much with v8 previously so it's difficult to say > if it could be related, so I'd like to check - do you see any possibility > that the mentioned patch could be the cause for the failing assert and if > so how could we fix it? If not, do you have any ideas on what else might > have caused it? > > Best regards, > Robert > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
