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.

Sign up for GitHub

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

Jump to bottom

Segmentation fault when call ParseFromArray #19625

Open
bigbrotherwei opened this issue Dec 12, 2024 · 3 comments
Open

Segmentation fault when call ParseFromArray #19625

bigbrotherwei opened this issue Dec 12, 2024 · 3 comments
Labels
c++

Comments

@bigbrotherwei
Copy link

What version of protobuf and what language are you using?
Version: v2.6.1
Language: C++

What operating system (Linux, Windows, ...) and version?
linux(centos 7.9, 3.10)

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

What did you do?

message UMessage {
    required Head head = 1;
    required Body body = 2;
};

message Head {
    required uint32 version = 1;
    required uint32 magic_flag = 2 [default = 0x12340987];
    required uint32 random_num = 3;
    required uint32 flow_no = 4;
    required string session_no = 5;
    required int32 message_type = 6;
    required int32 worker_index = 7;
    optional bool tint_flag = 8;
    required uint32 source_entity = 9;
    optional uint32 dest_entity = 11;
    optional string call_purpose = 13;
    optional bytes access_token = 14;
    optional bytes reserved = 15;
    optional string client_ip = 20;
    optional string target_ip = 30;    
    optional uint32 target_port = 40;             
};

my code is as follows. when l call ParseFromArray, Sometimes a segment fault error occurs. l can make sure that src has the correct data, because I take data out of coredunmp and parse it properly.

char *src = new char[data_size];
// get data from other place
conn->RemoveData(data, data_size);

UMessagePtr um(new UMessage());
um->ParseFromArray(src, data_size);

What did you expect to see
l want to know the reason for crash and how to deal with it.

What did you see instead?
stack is as follows

#0  0x000000000088eeda in std::string::_M_rep (this=0xffffffff00000000) at /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/basic_string.tcc:1089
#1  std::string::size (this=0xffffffff00000000) at /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/basic_string.h:3836
#2  std::string::resize (this=this@entry=0xffffffff00000000, __n=__n@entry=36, __c=__c@entry=0 '\000') at /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/basic_string.tcc:1092
#3  0x0000000000dc4360 in std::string::resize (__n=36, this=0xffffffff00000000) at ./google/protobuf/stubs/stl_util.h:68
#4  google::protobuf::STLStringResizeUninitialized (new_size=36, s=0xffffffff00000000) at ./google/protobuf/stubs/stl_util.h:68
#5  google::protobuf::io::CodedInputStream::InternalReadStringInline (size=<optimized out>, buffer=0xffffffff00000000, this=0x7f64032c7620) at ./google/protobuf/io/coded_stream_inl.h:53
#6  google::protobuf::internal::WireFormatLite::ReadString (input=input@entry=0x7f64032c7620, value=0xffffffff00000000) at google/protobuf/wire_format_lite.cc:459
#7  0x0000000000daf8fa in Head::MergePartialFromCodedStream (this=this@entry=0x19984cb0, input=input@entry=0x7f64032c7620) at test.pb.h:1468
#8  0x0000000000db3bbe in google::protobuf::internal::WireFormatLite::ReadMessageNoVirtual<Head> (value=<optimized out>, input=0x7f64032c7620)
    at /usr/local/include/google/protobuf/io/coded_stream.h:1140
#9  test::UMessage::MergePartialFromCodedStream (this=0x21d0d0e0, input=0x7f64032c7620) at test.pb.cc:526
#10 0x0000000000dc2b9c in google::protobuf::(anonymous namespace)::InlineMergeFromCodedStream (message=0x21d0d0e0, input=0x7f64032c7620) at google/protobuf/message_lite.cc:132
#11 google::protobuf::(anonymous namespace)::InlineParseFromCodedStream (message=0x21d0d0e0, input=0x7f64032c7620) at google/protobuf/message_lite.cc:132
#12 google::protobuf::(anonymous namespace)::InlineParseFromArray (message=0x21d0d0e0, size=<optimized out>, data=<optimized out>) at google/protobuf/message_lite.cc:143
#13 google::protobuf::MessageLite::ParseFromArray (this=0x21d0d0e0, data=<optimized out>, size=<optimized out>) at google/protobuf/message_lite.cc:207

Head value, other string field is set to 0x26a80e0, only session_no_ is set to 0xffffffff00000000

  version_ = 2,
  magic_flag_ = 305400199,
  random_num_ = 0,
  flow_no_ = 521723,
  session_no_ = 0xffffffff00000000,
  message_type_ = 320111,
  worker_index_ = 0,
  tint_flag_ = false,
  source_entity_ = 0,
  call_purpose_ = 0x197735a0,
  access_token_ = 0x26a80e0,
  reserved_ = 0x26a80e0,
  dest_entity_ = 521723,
  target_port_ = 0,
  client_ip_ = 0x26a80e0,
  target_ip_ = 0x26a80e0,

it seems session_no_ is set to an illegal addr, this is so weird

Anything else we should know about your project / environment
@bigbrotherwei bigbrotherwei added the untriaged auto added to all issues by default when created. label Dec 12, 2024
@bigbrotherwei
Copy link
Author

In addition, it will occasionally crash during object destruction. the reason is same as above, field session_no_ is set to illegal addr 0xffffffff00000000

#0  0x0000000000db5079 in _M_rep (this=0xffffffff00000000) at test.pb.cc:781
#1  ~basic_string (this=0xffffffff00000000, __in_chrg=<optimized out>) at /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/basic_string.h:3640
#2  test::Head::SharedDtor (this=this@entry=0x197bd960) at test.pb.cc:781
#3  0x0000000000db53f7 in test::Head::~Head (this=0x197bd960, __in_chrg=<optimized out>) at test.pb.cc:776
#4  0x0000000000db5419 in test::Head::~Head (this=0x197bd960, __in_chrg=<optimized out>) at test.pb.cc:774
#5  0x0000000000db4d9f in test::UMessage::SharedDtor (this=0x539cd50) at test.pb.cc:474
#6  0x0000000000db4de7 in test::UMessage::~UMessage (this=0x539cd50, __in_chrg=<optimized out>) at test.pb.cc:469
#7  0x0000000000db4e09 in test::UMessage::~UMessage (this=0x539cd50, __in_chrg=<optimized out>) at test.pb.cc:467

@shaod2
Copy link
Member

shaod2 commented Dec 12, 2024

I wonder if updating the Protobuf version would make things different.

@shaod2 shaod2 added c++ and removed untriaged auto added to all issues by default when created. labels Dec 12, 2024
@bigbrotherwei
Copy link
Author

bigbrotherwei commented Dec 13, 2024 •
edited
Loading

I wonder if updating the Protobuf version would make things different.

Thanks for your reply. I cannot reproduce the problem stably, so I don't know if the upgraded version is effective.
Have similar problems been encountered in history, one of the string field ptr store an illegal addr ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
c++
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@shaod2 @bigbrotherwei