00:20:14  * plutoniixjoined
00:26:37  * Ultrasaucejoined
01:00:08  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
01:02:52  * Guest59joined
02:22:56  <trungl-bot>Tree closed by [email protected]: closed (https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 from d0651bd108e0ee70ae822eda9bad7049cb2f3df4)
03:08:57  * bradleymeckjoined
03:16:43  * bradleymeckquit (Quit: bradleymeck)
05:33:49  * xaxxonjoined
07:17:56  <trungl-bot>Tree opened by [email protected]: open - watching gc stress
07:25:57  * xaxxonquit (Max SendQ exceeded)
07:28:06  * xaxxonjoined
07:38:41  * rexxjoined
08:41:30  * rexxquit (Ping timeout: 260 seconds)
08:49:46  * xaxxonquit (Quit: xaxxon)
10:25:34  * mylesborinsquit (Quit: farewell for now)
10:26:05  * mylesborinsjoined
12:01:49  * plutoniixquit (Quit: Leaving)
13:04:09  * bradleymeckjoined
13:09:47  * bradleymeckquit (Quit: bradleymeck)
13:45:55  <trungl-bot>Tree closed by [email protected]: closed (https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/11124 from c7e84f521644e273d669268dba90d5244bb90ecc)
13:54:46  * bradleymeckjoined
14:02:04  <trungl-bot>Tree opened by [email protected]: open (ulan is looking at GC test failures)
16:44:48  * RT|Chatzillaquit (Quit: ChatZilla [Firefox])
18:11:40  <Bakkot>aklein (or whoever): any pointers on tracking down the failure in https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355 ? I can't reproduce locally and can't for the life of me figure out how my change could have caused it
18:46:39  <aklein>Bakkot: what did you do to try to repro locally?
18:47:21  <aklein>you can use tools/dev/v8gen.py to create a build configuration exactly matching the bot
18:47:47  <aklein>v8gen.py -m client.v8 -b 'V8 Linux64 GC Stress - custom snapshot'
18:48:08  <aklein>and then build from there and run the test with the flags in the failure
18:48:38  <aklein>I also don't know off the top of my head why these would be related, but the blamelists for the failure (and the fact that it went away with the revert) does seem pretty clear
19:07:27  <caitp>Bakkot: not clear how it would affect wasm, but the change to Reparenter::VisitTryCatchStatement is semantically different from before
19:08:32  <Bakkot>aklein: built it with the gn args it lists (except not 'use_goma'), ran it with the command it lists
19:08:38  <Bakkot>will try with v8gen
19:08:47  <aklein>huh, that should be the same...
19:09:08  <aklein>I guess you can compare the gn args v8gen creates
19:09:14  <aklein>Bakkot: I can try reproing this afternoon
19:09:36  <Bakkot>caitp: how so? Keeping in mind that stmt->scope() was previously never null
19:10:34  <caitp>one, the order in which the try statements are visited, and 2, the fact that they are conditionally not visited, so you're potentially not reparenting stuff which needs to be, I think
19:11:31  <caitp>it may not actuallly break anything, I'd have to look at it closer to see, but it caught my eye as a potential breakage
19:15:05  <Bakkot>ah, they're only not visited if the scope is omitted entirely, which only happens if you don't have a binding; it works out I think. I have a test for it, at any rate. probably not the cause of this particular one.
19:27:03  <caitp>shouldn't it be more like: `Visit(stmt->try_block(); if (stmt->scope()) stmt->sope()->ReplaceOuterScope(scope_);` to semantically match + add the new behaviour?
19:27:20  <caitp>+ a closing paren in to close the Visit() call
19:30:28  <Bakkot>That's what it is, except with an additional else block, no? do you just mean that the else block shouldn't be there?
19:32:08  <Bakkot>else block is there because if the catch scope is missing then the catch block scope is the one which needs reparenting, instead of the catch scope
21:24:00  <aklein>Bakkot: I can repro the failure
21:24:21  <aklein>but still no clue why it happens
21:24:30  <aklein>the fact that it involves a try/catch is definitely suspicious, though
21:29:30  <Bakkot>aklein: thanks for confirming the repro, at least! what was your process?
21:30:01  <aklein>Bakkot: I added `v8_embed_script = "test/mjsunit/mjsunit.js"` to my usual x64 debug configuration
21:30:02  <Bakkot>v8gen doesn't work for me, incidentally - I get "V8 Linux64 GC Stress - custom snapshot does not exist in infra/mb/mb_config.pyl for client.v8"
21:30:12  <aklein>yeah, I noticed that v8gen doesn't know about this bot :/
21:30:20  <aklein>and then built d8
21:30:31  <aklein>and ran it with the commandline I saw here: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355/steps/Mjsunit/logs/trap-location
21:30:43  <aklein>(the v8_embed_script is also from the gn args I found there)
21:31:02  <Bakkot>yeah, ok, that's what I did too. I guess I probably need to try it on a linux machine.
21:32:11  <aklein>I'm a little surprised this depends on the OS, but then, it seems like it's hitting some weird edge condition, given it depends on the startup snapshot
21:37:08  * bradleymeckquit (Quit: )
21:38:53  <aklein>Bakkot: seems like the minimal set of flags is --expose-wasm --gc-interval=500 --stress-compaction
21:42:53  <Bakkot>great, thanks.
22:50:39  * RT|Chatzillajoined