Summary: | [ARM] REGRESSION(r198235): 12000 JSC stress tests started to crash on ARMv7 Thumb2 Linux platforms | ||
---|---|---|---|
Product: | WebKit | Reporter: | Csaba Osztrogonác <ossy> |
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | Blocker | CC: | cgarcia, clopez, gyuyoung.kim, jh718.park, mark.lam, oliver, ossy |
Priority: | P1 | ||
Version: | Other | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Bug Depends on: | |||
Bug Blocks: | 108645, 155508 |
Description
Csaba Osztrogonác
2016-03-16 03:49:42 PDT
Bisect finished, http://trac.webkit.org/changeset/198235 is the culprit. - r198234 - https://build.webkit.org/builders/EFL%20Linux%20ARMv7%20Thumb2%20Release/builds/17504 - 22 JSC tests failed - r198241 - https://build.webkit.org/builders/EFL%20Linux%20ARMv7%20Thumb2%20Release/builds/17505 - zillion failures ( I just reported this regression and don't have time to work on it. If somebody is interested in it, feel free to pick it up. ) Sorry will look at this in 30-40 minutes. Very confused :-/ Sorry will look at this in 30-40 minutes. Very confused. Are there any stack traces? Your ARM build uses the on demand allocator, right? I wonder if there's a bug in my control logic for this. (In reply to comment #4) > Your ARM build uses the on demand allocator, right? Yes. > I wonder if there's a bug in my control logic for this. (In reply to comment #5) > (In reply to comment #4) > > Your ARM build uses the on demand allocator, right? > Yes. > > > I wonder if there's a bug in my control logic for this. Are you able to make you test bot actually produce stack traces? This is very peculiar (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > Your ARM build uses the on demand allocator, right? > > Yes. > > > > > I wonder if there's a bug in my control logic for this. > > Are you able to make you test bot actually produce stack traces? This is > very peculiar (Note, i am looking at this, a stack trace would just make it easier to work out where it's all going horribly wrong :-O) Hmmm. Ossy, do you have build access for that configuration atm? I'd be interested in knowing what happens in #else // ENABLE(EXECUTABLE_ALLOCATOR_FIXED) static inline void* writeToExecutableRegion(void *dst, const void *src, size_t n) { return memcpy(dst, src, n); } #endif if you put an ASSERT(((intptr_t)dst) & 1); before the memcpy (In reply to comment #8) > Hmmm. Ossy, do you have build access for that configuration atm? > > I'd be interested in knowing what happens in > #else // ENABLE(EXECUTABLE_ALLOCATOR_FIXED) > static inline void* writeToExecutableRegion(void *dst, const void *src, > size_t n) > { > return memcpy(dst, src, n); > } > #endif > > if you put an > ASSERT(((intptr_t)dst) & 1); > > before the memcpy Yes, I'll try it. But unfortunately the cross compiling and test running is quite slow, it will take at least 15-20 minutes. (In reply to comment #8) > Hmmm. Ossy, do you have build access for that configuration atm? > > I'd be interested in knowing what happens in > #else // ENABLE(EXECUTABLE_ALLOCATOR_FIXED) > static inline void* writeToExecutableRegion(void *dst, const void *src, > size_t n) > { > return memcpy(dst, src, n); > } > #endif > > if you put an > ASSERT(((intptr_t)dst) & 1); > > before the memcpy I think you meant the negated condition. It wasn't easy, because there are many assertions on ARMv7 due to bug154857. But I managed to use release assert instead of, but it didn't hit on the tests which crashed due to this bug. The original and fixed change was relanded and there is no similar issue now. |