Bug 155537
| 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 | ||
Csaba Osztrogonác
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
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
Sorry will look at this in 30-40 minutes. Very confused :-/
Oliver Hunt
Sorry will look at this in 30-40 minutes. Very confused. Are there any stack traces?
Oliver Hunt
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
(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
(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
(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
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
(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
(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
The original and fixed change was relanded and there is no similar issue now.