Seems to be working fine without goma.

Robbie, feel free to assign to the goma team if you think it's their bug.

Hmm, since we don't have gomacc hook for protoc, it is strange that goma affects protoc result...

FYI: -1073740791, which is 0xC0000409, is STATUS_STACK_BUFFER_OVERRUN.

https://blogs.technet.microsoft.com/srd/2009/01/28/stack-overflow-stack-exhaustion-not-the-same-as-stack-buffer-overflow/

shinyak, would you mind investigating further, since it seems you're already looking?

if you can't figure it out overnight, feel free to assign back to me so I can keep looking in the morning.

@dmazzoni, sorry I didn't get to this earlier today

@iannucci,

actually it didn't repro on my Windows, so it's hard to investigate what is happening :'(
I tried it with the same gn args (with changing goma_dir) with r461614.

@dmazzoni,

Could you try clobber build with the latest trunk?

I sometimes see same protoc error in windows build when I use high -j (e.g. 1000).

Then, @dmazzoni, what -j is used?
If it happens with high -j, I suspect gn dependency is not enough; for example: protoc is used before it's built. Such high -j works only with goma, so it might happen only with goma. (However, this does not match with the exit code, so it's a bit skeptical for me.)

Yes, I was using -j 500, whereas without goma I was using the default which was probably more like 18.

That sounds like a dependency issue in the build file, right? We should be able to ensure that protoc is built before it's used.

Maybe goma affect the behavior of protoc, but causing buffer overrun on protoc is strange.
(Why protoc died without any error message? error is hidden by protoc_wrapper?)
protoc has actual bug causing stack buffer overrun?

I was suspecting dependency issue, however, this does not reason the exit code (STATUS_STACK_BUFFER_OVERRUN). So I'm not sure the reason...
I think it's worth checking the dependency, though.

If dependency issue, the second try should succeed, since protoc has been built at that time?

dmazzoni@ Is this still happening? I feel it's really odd if this is a goma issue. Dependency problem might be revealed because of fast goma build, though... Anyway, I couldn't repro this and would like to release this a bit.

Hasn't happened since. I'll reopen if it happens again.

Un-duping as per https://bugs.chromium.org/p/chromium/issues/detail?id=703251#c31

I agree with the unduping. -1073741819 (reported in comments on 703251 after duping this to that bug) == 0xC0000005. The last time I hit this (on a local build) in protoc.exe and some other binaries it was because some of the code in the binaries was all zeroes, which executes poorly. I don't know the cause so I did a clean rebuild and that solved it. Not encouraging.

So, not related to 703251. Not clear if the recent reports are related to this bug either, although maybe the precise failure mode varies.

https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Fchromium.goma%2FCrWinGomaStaging%2F21021%2F%2B%2Frecipes%2Fsteps%2Fcompile%2F0%2Fstdout

FAILED: gen/media/remoting/rpc.pb.h gen/media/remoting/rpc.pb.cc pyproto/media/remoting/rpc_pb2.py 
E:/b/depot_tools/python276_bin/python.exe ../../tools/protoc_wrapper/protoc_wrapper.py rpc.proto --protoc ./protoc.exe --proto-in-dir ../../media/remoting --cc-out-dir gen/media/remoting --py-out-dir pyproto/media/remoting
Protoc has returned non-zero status: -1073741819 .

I'm also hitting this in one of my out/foo directories, I've kept the dir as it can reproduce the problem (but I'm not sure what to look at). Unlike Bruce I'm getting a reasonably-looking stack trace, so I might not be hitting the mostly-zeroes case:

protoc.exe!google::protobuf::FileDescriptorProto::set_has_package() Line 4217	C++	Symbols loaded.
protoc.exe!google::protobuf::FileDescriptorProto::mutable_package() Line 4259	C++	Symbols loaded.
protoc.exe!google::protobuf::FileDescriptorProto::MergePartialFromCodedStream(google::protobuf::io::CodedInputStream * input) Line 1454	C++	Symbols loaded.
protoc.exe!google::protobuf::`anonymous namespace'::InlineMergeFromCodedStream(google::protobuf::io::CodedInputStream * input, google::protobuf::MessageLite * message) Line 119	C++	Symbols loaded.
protoc.exe!google::protobuf::`anonymous namespace'::InlineParseFromCodedStream(google::protobuf::io::CodedInputStream * input, google::protobuf::MessageLite * message) Line 130	C++	Symbols loaded.
protoc.exe!google::protobuf::`anonymous namespace'::InlineParseFromArray(const void * data, int size, google::protobuf::MessageLite * message) Line 142	C++	Symbols loaded.
protoc.exe!google::protobuf::MessageLite::ParseFromArray(const void * data, int size) Line 215	C++	Symbols loaded.
protoc.exe!google::protobuf::EncodedDescriptorDatabase::Add(const void * encoded_file_descriptor, int size) Line 314	C++	Symbols loaded.
protoc.exe!google::protobuf::DescriptorPool::InternalAddGeneratedFile(const void * encoded_file_descriptor, int size) Line 1314	C++	Symbols loaded.
protoc.exe!google::protobuf::compiler::protobuf_google_2fprotobuf_2fcompiler_2fplugin_2eproto::AddDescriptorsImpl() Line 192	C++	Symbols loaded.
protoc.exe!google::protobuf::internal::FunctionClosure0::Run() Line 130	C++	Symbols loaded.
protoc.exe!google::protobuf::GoogleOnceInitImpl(int * once, google::protobuf::Closure * closure) Line 91	C++	Symbols loaded.
protoc.exe!google::protobuf::GoogleOnceInit(int * once, void(*)() init_func) Line 68	C++	Symbols loaded.
protoc.exe!google::protobuf::compiler::protobuf_google_2fprotobuf_2fcompiler_2fplugin_2eproto::AddDescriptors() Line 202	C++	Symbols loaded.
protoc.exe!google::protobuf::compiler::protobuf_google_2fprotobuf_2fcompiler_2fplugin_2eproto::StaticDescriptorInitializer::StaticDescriptorInitializer() Line 208	C++	Symbols loaded.
protoc.exe!google::protobuf::compiler::protobuf_google_2fprotobuf_2fcompiler_2fplugin_2eproto::`dynamic initializer for 'static_descriptor_initializer''() Line 209	C++	Symbols loaded.

Let me know if there's some useful thing I could be adding here, or check with me out of band if you'd like a look at my busted build directory.