Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

route_guide_server process core seen during string encode in linux 32bit #15418

Closed
babuveld opened this issue Jan 12, 2024 · 3 comments
Closed

Comments

@babuveld
Copy link

What version of protobuf and what language are you using?
Version: main/v3.6.0/v3.5.0 etc. (NOTE: please try updating to the latest version of protoc/runtime possible beforehand to attempt to resolve your problem)
3.19.6

Language: C++/Java/Python/C#/Ruby/PHP/Objective-C/Javascript
c++

What operating system (Linux, Windows, ...) and version?
Linux 32bit

What runtime / compiler are you using (e.g., python version or gcc version)
gcc 5.2.0

What did you do?
Steps to reproduce the behavior:
Upgraded libprotobuf from 3.6.1 to 3.19.6 and we see below core during encoding. Its with the route_guide_server.cc example. The core is seen only for following cases.

  • When string is being encoded. When number is encoded, there are no cores.
  • With 64bit compilation we don't see any cores. it works fine.

Program received signal SIGSEGV, Segmentation fault.
0xf7b674d7 in google::protobuf::internal::ThreadSafeArena::GetSerialArenaFallback(void*) () from /usr/lib/libprotobuf.so.30
(gdb) bt
#0 0xf7b674d7 in google::protobuf::internal::ThreadSafeArena::GetSerialArenaFallback(void*) () from /usr/lib/libprotobuf.so.30
#1 0xf7b672ea in google::protobuf::internal::ThreadSafeArena::AllocateAlignedWithCleanupFallback(unsigned int, std::type_info const*) () from /usr/lib/libprotobuf.so.30
#2 0xf7b678dc in google::protobuf::Arena::AllocateAlignedWithCleanup(unsigned int, std::type_info const*) () from /usr/lib/libprotobuf.so.30
#3 0xf7b680d0 in google::protobuf::internal::ArenaStringPtr::Set(google::protobuf::internal::ArenaStringPtr::EmptyDefault, std::string&&, google::protobuf::Arena*) () from /usr/lib/libprotobuf.so.30
#4 0x10046e5d in routeguide::Feature::set_namestd::string (arg0=..., this=0x1005e540) at ../gpb/lib/src/route_guide.pb.h:1186
#5 routeguide::Parser::TryParseOne (feature=0x1005e540, this=0xffffd6d8) at ../gpb/lib/src/helper.cc:111
#6 routeguide::ParseDb (db=..., feature_list=0xffffd8bc) at ../gpb/lib/src/helper.cc:163
#7 0x10044120 in RouteGuideImpl::RouteGuideImpl (db=..., this=0xffffd8a8) at ../gpb/lib/src/route_guide_server.cc:104
#8 RunServer (db_path=...) at ../gpb/lib/src/route_guide_server.cc:189
#9 0x100443a4 in main (argc=2, argv=0xffffda04) at ../gpb/lib/src/route_guide_server.cc:222
(gdb)

What did you expect to see
No cores

What did you see instead?
process core with SIGSEGV fault.

Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs).

Anything else we should know about your project / environment

@babuveld babuveld added the untriaged auto added to all issues by default when created. label Jan 12, 2024
@acozzette
Copy link
Member

I think the problem is likely a mismatch between the generated code version and the libprotobuf version, or possibly a mismatch between the protobuf headers that were built against and the libprotobuf used at runtime. It's important to make sure that the protoc version used to generate code exactly matches the libprotobuf version and also that the libprotobuf headers used at compile time are the same version of the libprotobuf used at runtime.

@acozzette acozzette removed the untriaged auto added to all issues by default when created. label Jan 12, 2024
@babuveld
Copy link
Author

Thanks for the quick response. I verified again and I could see there are no issues with the protoc/protobuf versions used. Its the same headers/library being used both during compile time and runtime.

Is there a way to figure out what is wrong from the backtrace? As I mentioned before setting numbers doesn't have any issue, problem is only with setting string.

@babuveld
Copy link
Author

Just an update. We replaced clang compiler with gcc/g++ and recompiled the 32bit libraries and the problem got resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants