Issue metadata
Sign in to add a comment
|
protoc crashes
Reported by
msten...@opera.com,
Oct 9 2017
|
||||||||||||||||||||||
Issue description
When building content_shell:
python ../../tools/protoc_wrapper/protoc_wrapper.py call_stack_profile.proto cast_logs.proto chrome_user_metrics_extension.proto execution_context.proto extension_install.proto histogram_event.proto memory_leak_report.proto omnibox_event.proto omnibox_input_type.proto perf_data.proto perf_stat.proto printer_event.proto reporting_info.proto sampled_profile.proto system_profile.proto translate_event.proto ukm/entry.proto ukm/report.proto ukm/source.proto user_action_event.proto --protoc ./protoc --proto-in-dir ../../components/metrics/proto --cc-out-dir gen/components/metrics/proto --py-out-dir pyproto/components/metrics/proto
Protoc has returned non-zero status: -11 .
Even running protoc without arguments crashes:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7a5e1c6 in ?? () from /opt/chr/work/src/out/Debug/./libc++.so
#0 0x00007ffff7a5e1c6 in std::__1::basic_ostream<char, std::__1::char_traits<char> >::sentry::sentry (
this=0x7fffffffb768, __os=...) at ../../buildtools/third_party/libc++/trunk/include/ostream:262
#1 0x00000000002fd586 in std::__1::__put_character_sequence<char, std::__1::char_traits<char> > (__os=...,
__str=0x201215 "Usage: ", __len=7) at ../../buildtools/third_party/libc++/trunk/include/ostream:721
#2 0x00000000002f150c in std::__1::operator<< <std::__1::char_traits<char> > (__os=..., __str=0x201215 "Usage: ")
at ../../buildtools/third_party/libc++/trunk/include/ostream:864
#3 0x00000000002e4606 in google::protobuf::compiler::CommandLineInterface::PrintHelpText (this=0x7fffffffdf10)
at ../../third_party/protobuf/src/google/protobuf/compiler/command_line_interface.cc:1463
#4 0x00000000002dc631 in google::protobuf::compiler::CommandLineInterface::ParseArguments (this=0x7fffffffdf10, argc=1,
argv=0x7fffffffe1b8) at ../../third_party/protobuf/src/google/protobuf/compiler/command_line_interface.cc:1017
#5 0x00000000002d971b in google::protobuf::compiler::CommandLineInterface::Run (this=0x7fffffffdf10, argc=1,
argv=0x7fffffffe1b8) at ../../third_party/protobuf/src/google/protobuf/compiler/command_line_interface.cc:766
#6 0x00000000002d0087 in main (argc=1, argv=0x7fffffffe1b8)
at ../../third_party/protobuf/src/google/protobuf/compiler/main.cc:105
https://chromium-review.googlesource.com/696190 seemed relevant, but after some testing, it seems that reverting it doesn't really solve the crash when running from the command line (maybe that's how it supposed to work, for all I know). I got a successful Debug build, though.
Using Debian 9 (Stretch), FWIW.
,
Oct 9 2017
This (on Wed Oct 4) introduced a problem: https://chromium-review.googlesource.com/699741 It doesn't cause protoc to crash, but the build fails anyway, with: FAILED: gen/modules/audio_processing/debug.pb.h gen/modules/audio_processing/debug.pb.cc pyproto/modules/audio_processing/debug_pb2.py python ../../tools/protoc_wrapper/protoc_wrapper.py debug.proto --protoc ./protoc --proto-in-dir ../../third_party/webrtc/modules/audio_processing --cc-out-dir gen/modules/audio_processing --py-out-dir pyproto/modules/audio_processing debug.proto:8:12: "int32" is not defined. debug.proto:9:12: "int32" is not defined. debug.proto:10:12: "int32" is not defined. debug.proto:11:12: "int32" is not defined. debug.proto:12:12: "int32" is not defined. debug.proto:13:12: "int32" is not defined. debug.proto:14:12: "int32" is not defined. debug.proto:15:12: "int32" is not defined. debug.proto:16:12: "int32" is not defined. debug.proto:22:12: "bytes" is not defined. debug.proto:26:12: "bytes" is not defined. debug.proto:32:12: "bytes" is not defined. debug.proto:33:12: "bytes" is not defined. debug.proto:35:12: "int32" is not defined. debug.proto:36:12: "sint32" is not defined. debug.proto:37:12: "int32" is not defined. debug.proto:38:12: "bool" is not defined.
,
Oct 9 2017
Here's what introduces the crash (on Fri Oct 6): https://chromium-review.googlesource.com/701464
,
Oct 9 2017
So, the obvious workaround here is to set use_lld to false manually, and protoc will behave again.
,
Oct 9 2017
I can't seem to reproduce either of those problems here. Is there anything else in your args.gn? $ ninja gen/components/metrics/proto/call_stack_profile.pb.cc [1/1] Regenerating ninja files [222/222] ACTION //components/metrics/proto:proto_gen(//build/toolchain/linux:clang_x64) $ ninja gen/modules/audio_processing/debug.pb.h [2/2] ACTION //third_party/webrtc/modules/audio_processing:audioproc_debug_proto_gen(//build/toolchain/linux:clang_x64) $ cat args.gn is_debug = true linux_use_bundled_binutils = false
,
Oct 9 2017
Now it looks like all is confused by ccache. Removing cc_wrapper="ccache" Seems to fix things.
,
Oct 9 2017
ccache -C or even removing the whole ccache directory didn't help.
,
Oct 10 2017
Wouldn't a reasonable fix be to condition use_lld on linux_use_bundled_binutils being true? It seems wrong to use the bundled lld if we're not using the other bundled binutils.
,
Oct 27 2017
Issue 696730 ? There's also Issue 765323 with a different protoc error (Windows). Maybe related.
,
Oct 27 2017
> Wouldn't a reasonable fix be to condition use_lld on linux_use_bundled_binutils being true? It seems wrong to use the bundled lld if we're not using the other bundled binutils. That sounds reasonable to me. pcc, what do you think?
,
Oct 27 2017
This could be related to issue 778209 . Could you folks see if the same workaround works for you?
,
Nov 8 2017
,
Jan 13 2018
OP is the issue fixed with use_lld=true now? There was a clang/llvm roll that included a fix for something similar.
,
Jan 13 2018
The bug appears to be an OS bug rather than a linker bug - the generated binary is actually fine on disk but gets incorrectly mapped into memory when being run "too soon" after being linked. Details in the master bug, which this is a duplicate of. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by msten...@opera.com
, Oct 9 2017