fix(es/transforms): Fix capacity overflow with decorators #8815
Conversation
|
| @@ -1699,7 +1699,8 @@ impl VisitMut for Decorator202203 { | |||
| let old_extra_lets = self.extra_lets.take(); | |||
| let old_extra_vars = self.extra_vars.take(); | |||
|
|
|||
| let mut new = Vec::with_capacity(n.len()); | |||
There was a problem hiding this comment.
Looking into it more, I think the segfault is caused by the use of an Arena. The value it's providing here for .len() is crazy high. I opened #8816
Edit: not sure
There was a problem hiding this comment.
@kdy1 do you have any idea why this n.len() might sometimes be returning a very large 1314431791570856 / sizeof(Stmt)? We noticed it only after bumping to the latest swc patches in only some scenarios denoland/deno#23187 (comment)
There was a problem hiding this comment.
Cqn you try reverting dudykr/ddbase#27 ?
You can clone it and add [patch.crates.io] to the local clone. cc @bgw
There was a problem hiding this comment.
Thanks! It was actually locked to 0.2.6. I'll try 0.2.8 and see.
There was a problem hiding this comment.
Same issue in 0.2.8 as in 0.2.6. I'll try harder tomorrow on getting a local reproduction so that I can isolate the problem. It only seems to happen on the CI atm for some reason.
There was a problem hiding this comment.
This is definitely a corruption bug -- do these two 32-bit numbers look familiar? Indices perhaps?
>>> hex(1314431791570856)
'0x4ab7800049fa8'
>>> [0x49fa8, 0x4ab78]
[303016, 306040]
kdy1
changed the title
Description: Fixes an incorrect capacity (found while investigating a segfault).
More details: denoland/deno#23187 (comment)
Related issue (if exists): None