Thanks a lot for the reply! :-) Alright, I figured it was worth a shot! Thanks for clarifying the situation. The version information in our repository says:
#define V8_MAJOR_VERSION 4#define V8_MINOR_VERSION 5#define V8_BUILD_NUMBER 103#define V8_PATCH_LEVEL 29 So it looks like we indeed have that particular patch. Do you have ideas on other potentially related fixes? Do you have any suggestions on ways to track these kinds of issues down? Strategic places for logging? Best regards, Robert On Thu, Sep 10, 2015 at 5:27 PM, Jakob Kummerow <[email protected]> wrote: > 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.
