I don't know what else it might be. These kinds of crashes tend to be among the hardest to track down. Can you catch it in GDB? Inspecting the heap might provide valuable clues; or it might be entirely fruitless if the root cause of whatever chain of events is going wrong has long been overwritten and forgotten...
Do you have a repro you can share? Can you run the same test/code/whatever on a desktop build (ia32 or x64), and if yes, does it exhibit the same failure? +Hannes, is it possible that we need to extend RemoveInvalidSlots to filter typed slots as well? Maybe this is a slot that used to be in the middle of the code part of a code object, but that object has been overwritten, and now it points at garbage (or possibly at a valid tagged pointer, but being a CODE_ENTRY_SLOT it doesn't like tagged pointers). On Thu, Sep 10, 2015 at 5:45 PM, Robert Norlander <[email protected]> wrote: > 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.
