RESOLVED FIXED 155537
[ARM] REGRESSION(r198235): 12000 JSC stress tests started to crash on ARMv7 Thumb2 Linux platforms 
https://bugs.webkit.org/show_bug.cgi?id=155537
Summary [ARM] REGRESSION(r198235): 12000 JSC stress tests started to crash on ARMv7 T...
Csaba Osztrogonác
Reported 2016-03-16 03:49:42 PDT
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.
Attachments
Add attachment proposed patch, testcase, etc.
Csaba Osztrogonác
Comment 1 2016-03-16 06:06:39 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. )
Oliver Hunt
Comment 2 2016-03-16 07:36:18 PDT
Sorry will look at this in 30-40 minutes. Very confused :-/
Oliver Hunt
Comment 3 2016-03-16 07:37:49 PDT
Sorry will look at this in 30-40 minutes. Very confused. Are there any stack traces?
Oliver Hunt
Comment 4 2016-03-16 10:18:12 PDT
Your ARM build uses the on demand allocator, right? I wonder if there's a bug in my control logic for this.
Csaba Osztrogonác
Comment 5 2016-03-16 10:19:41 PDT
(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.
Oliver Hunt
Comment 6 2016-03-16 10:20:53 PDT
(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
Oliver Hunt
Comment 7 2016-03-16 10:22:05 PDT
(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)
Oliver Hunt
Comment 8 2016-03-16 10:26:45 PDT
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
Csaba Osztrogonác
Comment 9 2016-03-16 10:35:57 PDT
(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.
Csaba Osztrogonác
Comment 10 2016-03-23 06:31:10 PDT
(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.
Csaba Osztrogonác
Comment 11 2016-04-13 01:27:44 PDT
The original and fixed change was relanded and there is no similar issue now.
Note You need to log in before you can comment on or make changes to this bug.