https://build.chromium.org/p/chromium/builders/Win/builds/53449/ looks like another case of this?

The executables called by python are crashing once in a while. Sometimes mksnapshot, sometimes v8_shell. Not much we can do about this, except maybe a dumb retry loop in the python script? We also could think about how could get more output shown on a crash.

I don't think this code is owned by Chromium Infra team, removing Infra>Flakiness.

am getting crashes with mksnapshot.

stack:

c:\src\chromium\src>ninja -C out\goma64 chrome -j200
ninja: Entering directory `out\goma64'
[239/6047] ACTION //v8:run_mksnapshot(//build/toolchain/win:clang_x64)
FAILED: gen/v8/snapshot.cc snapshot_blob.bin
c:/src/depot_tools/python276_bin/python.exe ../../v8/tools/run.py ./mksnapshot --startup_src gen/v8/snapshot.cc --random-seed 314159265 --startup_blob snapshot_blob.bin


#
# Fatal error in ../../v8/src/snapshot/serializer-common.cc, line 27
# Check failed: map_->Get(addr).IsNothing().
#

==== C stack trace ===============================

        v8::base::debug::StackTrace::StackTrace [0x00007FF64063A67B+27] (C:\src\chromium\src\v8\src\base\debug\stack_trace_win.cc:177)
        v8::platform::`anonymous namespace'::PrintStackTrace [0x00007FF64055C994+36] (C:\src\chromium\src\v8\src\libplatform\default-platform.cc:25)
        V8_Fatal [0x00007FF640555576+118] (C:\src\chromium\src\v8\src\base\logging.cc:73)
        v8::internal::ExternalReferenceEncoder::ExternalReferenceEncoder [0x00007FF640379CC2+882] (C:\src\chromium\src\v8\src\snapshot\serializer-common.cc:27)
        v8::internal::Serializer::Serializer [0x00007FF64037A176+70] (C:\src\chromium\src\v8\src\snapshot\serializer.cc:16)
        v8::internal::StartupSerializer::StartupSerializer [0x00007FF64037F256+22] (C:\src\chromium\src\v8\src\snapshot\startup-serializer.cc:19)
        v8::SnapshotCreator::CreateBlob [0x00007FF63FBC4CD7+2071] (C:\src\chromium\src\v8\src\api.cc:699)
        v8::V8::CreateSnapshotDataBlob [0x00007FF63FBC567C+380] (C:\src\chromium\src\v8\src\api.cc:757)
        main [0x00007FF63FBB1309+265] (C:\src\chromium\src\v8\src\snapshot\mksnapshot.cc:176)
        __scrt_common_main_seh [0x00007FF64063BB39+285] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253)
        BaseThreadInitThunk [0x00007FFA9D8C8102+34]
        RtlUserThreadStart [0x00007FFA9FBFC5B4+52]
[244/6047] CXX obj/content/common/common/user_agent.obj
ninja: build stopped: interrupted by user.

gn flags:

is_debug = false
is_component_build = false
target_cpu="x64"
use_goma = true
symbol_level = 2
is_win_fastlink = true
goma_dir = "C:\src\goma\goma-win64"
is_clang = true
is_chrome_branded = true
dcheck_always_on = true
enable_nacl = false

The problem from comment 6 is duplicate of issue 726896, which should be resolved by now. The general problem of this issue here remains.

More mksnapshot crashes for the record:
https://build.chromium.org/p/chromium/builders/Win/builds/55845
https://build.chromium.org/p/chromium/builders/Win/builds/55665

Raising prio as this closes the tree each time it happens. Maybe a simple retry-loop would mitigate this? Suggested that already in comment 3.

This is flakily blocking commits. Could today's sheriff's look into it? Here's one recent occurrence:

https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_compile_dbg_ng/builds/436577

Can Infra-Troopers look into it?

The title says "python commands", but the stack traces look pretty squarely in V8 code. Is there a reason Python is being blamed for this?

If there is a bug in V8 code, the proper thing to do is bisect, identify it, and fix it, right? Wrapping the code in a retry loop only allows a fatal bug to exist indefinitely. This seems counterproductive to a stable code base.

See comment 3. Both v8_shell and mksnapshot have rare flakes. Nobody has cycles to analyze those. My main suggestion is still a simple retry loop in the python wrappers. E.g. call the v8 executable up to three times until return code is 0.

-Trooper: I don't think a trooper can help here.  The Chrome-side infrastructure for this looks fine afaict.  If you still think this is a trooper issue please re-add the label and be more specific about what you need looking into.

Another one:
https://build.chromium.org/p/chromium/builders/Win/builds/58903

The code referenced in #6 has recently changed. One explanation for the failure is that ICF could cause two external references to point to the same function, causing the assertion to fail. That assertion has since been removed.

Closing with fixed. Please open a new issue if this re-occurs.

Comment 6 was rather fly-by and is duplicate of issue 726896. The general issue here is that our scripts are flaky and fail once in a while leading to an overall compile failure. I thought we track this here. And we don't have a solid solution yet.

Another data point:
https://ci.chromium.org/buildbot/chromium.chrome/Google%20Chrome%20Win/25852

Looks like this still isn't resolved.

 Issue 743069  has been merged into this issue.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Is this a duplicate of  issue 644525 ?

It could well be. Has the bug occurred in the last eleven months or so, since the workaround was landed? If not then I think this could be closed as a duplicate of 644525.

Looks like. We could always open a new bug if it reoccurs.