GTK Linux ARM Release ---------------------- - r198228 - Failed 111 jsc tests - https://build.webkit.org/builders/GTK%20Linux%20ARM%20Release/builds/10571 - r198253 - Failed 12070 jsc tests - https://build.webkit.org/builders/GTK%20Linux%20ARM%20Release/builds/10570 EFL Linux ARMv7 Thumb2 Release ------------------------------- - r198208 - Failed 18 jsc tests - https://build.webkit.org/builders/EFL%20Linux%20ARMv7%20Thumb2%20Release/builds/17500 - r198268 - Failed 12049 jsc tests - https://build.webkit.org/builders/EFL%20Linux%20ARMv7%20Thumb2%20Release/builds/17502 This regression occured between r198229-r198252. As far as I see, in this interval https://trac.webkit.org/changeset/198235 is the only one major JSC change which could cause this regression. I'll bisect it soon.
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.