Linear scan crash: divergence #36977
Comments
aartbik
added
area-vm
|
The second issue reproduces for SIMDBC, in debug mode with a better assert failure:
|
|
Happened again in a nightly: |
|
Keeps coming back. This needs to be fixed soon! We end up with end = 2147483647 and start() = 1979 in the following assert:
|
|
What happens is that, for a parameter in ProcessInitialDefinition(), DBC calls BlockLocation() with the maximum position as end.
Later, this blows up, either on the following assert in AddUseInterval() with end = 2147483647 and start() = 1979:
or, without this assert, a bit later while accessing the BitField out of bounds during encode(). |
|
The assert happens for the R1-allocated parameter in a catch block in X0::foo0_0(). All registers see a similar range and, except for R1, an empty use interval. It blows up for R1, which already has a [1979, 1981) interval, which cannot be combined with [0, 2147483647). B167[target catch try_idx -1 catch_try_idx 0] {
v2 <- Parameter(0) T{X0}
v3 <- Parameter(1) T{Map<int, String>?}
v4 <- Parameter(2) T{int?}
v5 <- Parameter(3)
v6 <- Parameter(4)
v7 <- Parameter(5)
v8 <- SpecialParameter(kException) T{*}
v9 <- SpecialParameter(kStackTrace)
v10 <- Parameter(8)
v11 <- Parameter(9)
v12 <- Parameter(10)
.....
v32 <- Parameter(30)
.....
v40 <- Parameter(38)
v41 <- Parameter(39)
range [1944, 1946) for v2 has been allocated to R31:
range [1944, 1946) for v3 has been allocated to R30:
range [1944, 1946) for v4 has been allocated to R29:
range [1944, 1945) for v5 has been allocated to R28:
range [1944, 1946) for v6 has been allocated to R27:
range [1944, 1945) for v7 has been allocated to R26:
range [1944, 1945) for v8 has been allocated to ExceptionReg:
range [1944, 1945) for v9 has been allocated to StackTraceReg:
range [1944, 1945) for v10 has been allocated to R23:
range [1944, 1945) for v11 has been allocated to R22:
range [1944, 1945) for v12 has been allocated to R21:
range [1944, 1945) for v13 has been allocated to R20:
.....
range [1944, 1945) for v27 has been allocated to R6:
range [1944, 1945) for v28 has been allocated to R5:
range [1944, 1945) for v29 has been allocated to R4:
range [1944, 1945) for v30 has been allocated to R3:
range [1944, 1945) for v31 has been allocated to R2:
range [1944, 1945) for v32 has been allocated to R1: <= has a use interval
ASSERT FAIL! |
|
@mkustermann would you mind having a look if something jumps out? |
|
@mraleph any insights? Is it just because we run out of registers and that was never seen before (on DBC64, we start at R63), or is is something else? |
|
Based on a brief look - yeah this is just out of registers situation. On DBC32 we have only 32 registers and we need a register for every I think code in the If we do - then we should just [I actually don't remember why this number is set so low - because instruction encoding can accomodate up to 256 registers. Though if we set number of registers to 256 frame size for functions with try catch would balloon due to somewhat bizarre way of doing try-catch sync]. |
|
@mkustermann Martin could you work with @aartbik and find somebody to fix this bug? Should be rather straightforward change. Let me know if you need to guidance from me. |
|
I made a CL that fixes this. Please have a look if the solution makes sense. |
Rationale: Code had no guard on running out of registers #36977 Change-Id: Ifec1b7ef626e6a8720c437f0f25d119956dfb63a Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/106429 Commit-Queue: Aart Bik <ajcbik@google.com> Reviewed-by: Martin Kustermann <kustermann@google.com> Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Last night Dartfuzz results with two crashes. The first looks like the typical "false" divergence due to allocating too much. We have some plans in our design doc to avoid these cases better.
The second, however, may be something else
The text was updated successfully, but these errors were encountered: