fix a compile warning by huahang · Pull Request #8 · protocolbuffers/protobuf

huahang · 2014-09-03T07:08:50Z

This change fixes the following compiler warning:

warning: type qualifiers ignored on function return type [-Wignored-qualifiers]

This change fixes the following compiler warning: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]

fix a compile warning

liujisi · 2014-09-04T01:02:42Z

Thanks for the fix.

xfxyjwf · 2014-09-04T01:35:38Z

This patch only fixed the declaration in the header file. Shouldn't we also remove the const qualifier from the method definition in the source file?
https://github.com/google/protobuf/blob/master/src/google/protobuf/generated_message_reflection.cc#L1499

huahang · 2014-09-04T02:53:26Z

@xfxyjwf

my bad. it has been submitted as the following pull request:

#12

Amalgamated distribution (upb.c/upb.h) tool.

==500166==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0xdd383e in google::protobuf::compiler::DiskSourceTree::OpenDiskFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) build_msan/./contrib/protobuf/src/google/protobuf/compiler/importer.cc:504:7 #1 0xdd1eb2 in google::protobuf::compiler::DiskSourceTree::DiskFileToVirtualFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*) build_msan/./contrib/protobuf/src/google/protobuf/compiler/importer.cc:431:51 #2 0x540619 in google::protobuf::compiler::CommandLineInterface::MakeProtoProtoPathRelative(google::protobuf::compiler::DiskSourceTree*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, google::protobuf::DescriptorDatabase*) build_msan/./contrib/protobuf/src/google/protobuf/compiler/command_line_interface.cc:1362:24 #3 0x5314fb in google::protobuf::compiler::CommandLineInterface::MakeInputsBeProtoPathRelative(google::protobuf::compiler::DiskSourceTree*, google::protobuf::DescriptorDatabase*) build_msan/./contrib/protobuf/src/google/protobuf/compiler/command_line_interface.cc:1415:10 #4 0x5314fb in google::protobuf::compiler::CommandLineInterface::InitializeDiskSourceTree(google::protobuf::compiler::DiskSourceTree*, google::protobuf::DescriptorDatabase*) build_msan/./contrib/protobuf/src/google/protobuf/compiler/command_line_interface.cc:1168:8 #5 0x52541f in google::protobuf::compiler::CommandLineInterface::Run(int, char const* const*) build_msan/./contrib/protobuf/src/google/protobuf/compiler/command_line_interface.cc:1026:10 #6 0x50f5d6 in google::protobuf::compiler::ProtobufMain(int, char**) build_msan/./contrib/protobuf/src/google/protobuf/compiler/main.cc:104:14 protocolbuffers#7 0x50fe58 in main build_msan/./contrib/protobuf/src/google/protobuf/compiler/main.cc:112:10 protocolbuffers#8 0x7f817143db24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) protocolbuffers#9 0x48904d in _start (/mnt/ch/ClickHouse/build_msan/contrib/protobuf-cmake/protoc+0x48904d) Uninitialized value was created by an allocation of 'sb' in the stack frame of function '_ZN6google8protobuf8compiler14DiskSourceTree12OpenDiskFileERKNSt3__112basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEE' #0 0xdd3320 in google::protobuf::compiler::DiskSourceTree::OpenDiskFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) build_msan/./contrib/protobuf/src/google/protobuf/compiler/importer.cc:492 SUMMARY: MemorySanitizer: use-of-uninitialized-value build_msan/./contrib/protobuf/src/google/protobuf/compiler/importer.cc:504:7 in google::protobuf::compiler::DiskSourceTree::OpenDiskFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) Exiting

…uilder at return. See godbolt for Android ART compiler: https://godbolt.org/z/M9dWhdqbf This optimisation brings the implementation down from 284 bytes to 272 bytes. - `GeneratedMessage$Builder SingleFieldBuilder.getBuilder() [284 bytes]` - `GeneratedMessage$Builder SingleFieldBuilder.getBuilder__withLocalVariable() [272 bytes]` It's not big. It's just a few instructions dropped. These were dropped just before the `ret`: ``` -mov x23, x1 -ldr w0, [x23, #8] ``` And this load dropped before calling `markClean`. ``` -ldr w1, [x23, #8] ``` PiperOrigin-RevId: 677669563

…uilder at return. See godbolt for Android ART compiler: https://godbolt.org/z/M9dWhdqbf This optimisation brings the implementation down from 284 bytes to 272 bytes. - `GeneratedMessage$Builder SingleFieldBuilder.getBuilder() [284 bytes]` - `GeneratedMessage$Builder SingleFieldBuilder.getBuilder__withLocalVariable() [272 bytes]` It's not big. It's just a few instructions dropped. These were dropped just before the `ret`: ``` -mov x23, x1 -ldr w0, [x23, #8] ``` And this load dropped before calling `markClean`. ``` -ldr w1, [x23, #8] ``` PiperOrigin-RevId: 683619150

There is no need to keep these inline as they are not specialized to the function. We also don't need branch prediction slots for them as the `ret` will always be correctly predicted, and the "end of buffer" branch is rarely taken. With these changes, the functions to parse fixed fields are about as short and optimal as they could be: <details> <summary>x86-64 Assembly</summary> ``` 0000000000000000 <upb_DecodeFast_Fixed32_Scalar_Tag1Byte>: 0: 45 84 c9 test r9b, r9b 3: 0f 85 00 00 00 00 jne 0x9 <upb_DecodeFast_Fixed32_Scalar_Tag1Byte+0x9> 0000000000000005: R_X86_64_PLT32 _upb_FastDecoder_DecodeGeneric-0x4 9: 4c 89 c8 mov rax, r9 c: 48 c1 e8 30 shr rax, 0x30 10: 45 89 ca mov r10d, r9d 13: 41 c1 ea 18 shr r10d, 0x18 17: 4d 0f ab d0 bts r8, r10 1b: 44 8b 56 01 mov r10d, dword ptr [rsi + 0x1] 1f: 44 89 14 02 mov dword ptr [rdx + rax], r10d 23: 48 83 c6 05 add rsi, 0x5 27: 48 3b 77 08 cmp rsi, qword ptr [rdi + 0x8] 2b: 0f 83 00 00 00 00 jae 0x31 <upb_DecodeFast_Fixed32_Scalar_Tag1Byte+0x31> 000000000000002d: R_X86_64_PLT32 upb_DecodeFast_MessageIsDoneFallback-0x4 31: 0f b7 06 movzx eax, word ptr [rsi] 34: 49 89 c9 mov r9, rcx 37: 49 c1 f9 08 sar r9, 0x8 3b: 41 89 c2 mov r10d, eax 3e: 41 21 ca and r10d, ecx 41: 41 81 e2 f8 00 00 00 and r10d, 0xf8 48: 4f 8b 5c 51 20 mov r11, qword ptr [r9 + 2*r10 + 0x20] 4d: 4f 8b 4c 51 18 mov r9, qword ptr [r9 + 2*r10 + 0x18] 52: 49 31 c1 xor r9, rax 55: 41 ff e3 jmp r11 ``` </details> <details> <summary>ARM64 Assembly</summary> ``` 0000000000000000 <upb_DecodeFast_Fixed32_Scalar_Tag1Byte>: 0: f2401cbf tst x5, #0xff 4: 54000040 b.eq 0xc <upb_DecodeFast_Fixed32_Scalar_Tag1Byte+0xc> 8: 14000000 b 0x8 <upb_DecodeFast_Fixed32_Scalar_Tag1Byte+0x8> 0000000000000008: R_AARCH64_JUMP26 _upb_FastDecoder_DecodeGeneric c: d370fca8 lsr x8, x5, #48 10: b840102 ldur w9, [x1, #0x1] 14: 5280002a mov w10, #0x1 // =1 18: 91001421 add x1, x1, #0x5 1c: b8286849 str w9, [x2, x8] 20: d358fca8 lsr x8, x5, #24 24: f9400409 ldr x9, [x0, #0x8] 28: 9ac82148 lsl x8, x10, x8 2c: eb01013f cmp x9, x1 30: 54000149 b.ls 0x58 <upb_DecodeFast_Fixed32_Scalar_Tag1Byte+0x58> 34: 79400029 ldrh w9, [x1] 38: 9348fc6a asr x10, x3, #8 3c: 12001c6b and w11, w3, #0xff 40: aa040104 orr x4, x8, x4 44: 8a09016b and x11, x11, x9 48: 8b0b054a add x10, x10, x11, lsl #1 4c: a941994b ldp x11, x6, [x10, #0x18] 50: ca090165 eor x5, x11, x9 54: d61f00c0 br x6 58: aa040104 orr x4, x8, x4 5c: 14000000 b 0x5c <upb_DecodeFast_Fixed32_Scalar_Tag1Byte+0x5c> 000000000000005c: R_AARCH64_JUMP26 upb_DecodeFast_MessageIsDoneFallback ``` </details> PiperOrigin-RevId: 765574494

There is no need to keep these inline as they are not specialized to the function. We also don't need branch prediction slots for them as the `ret` will always be correctly predicted, and the "end of buffer" branch is rarely taken. With these changes, the functions to parse fixed fields are about as short and optimal as they could be: <details> <summary>x86-64 Assembly</summary> ``` 0000000000000000 <upb_DecodeFast_Fixed32_Scalar_Tag1Byte>: 0: 45 84 c9 test r9b, r9b 3: 0f 85 00 00 00 00 jne 0x9 <upb_DecodeFast_Fixed32_Scalar_Tag1Byte+0x9> 0000000000000005: R_X86_64_PLT32 _upb_FastDecoder_DecodeGeneric-0x4 9: 4c 89 c8 mov rax, r9 c: 48 c1 e8 30 shr rax, 0x30 10: 45 89 ca mov r10d, r9d 13: 41 c1 ea 18 shr r10d, 0x18 17: 4d 0f ab d0 bts r8, r10 1b: 44 8b 56 01 mov r10d, dword ptr [rsi + 0x1] 1f: 44 89 14 02 mov dword ptr [rdx + rax], r10d 23: 48 83 c6 05 add rsi, 0x5 27: 48 3b 77 08 cmp rsi, qword ptr [rdi + 0x8] 2b: 0f 83 00 00 00 00 jae 0x31 <upb_DecodeFast_Fixed32_Scalar_Tag1Byte+0x31> 000000000000002d: R_X86_64_PLT32 upb_DecodeFast_MessageIsDoneFallback-0x4 31: 0f b7 06 movzx eax, word ptr [rsi] 34: 49 89 c9 mov r9, rcx 37: 49 c1 f9 08 sar r9, 0x8 3b: 41 89 c2 mov r10d, eax 3e: 41 21 ca and r10d, ecx 41: 41 81 e2 f8 00 00 00 and r10d, 0xf8 48: 4f 8b 5c 51 20 mov r11, qword ptr [r9 + 2*r10 + 0x20] 4d: 4f 8b 4c 51 18 mov r9, qword ptr [r9 + 2*r10 + 0x18] 52: 49 31 c1 xor r9, rax 55: 41 ff e3 jmp r11 ``` </details> <details> <summary>ARM64 Assembly</summary> ``` 0000000000000000 <upb_DecodeFast_Fixed32_Scalar_Tag1Byte>: 0: f2401cbf tst x5, #0xff 4: 54000040 b.eq 0xc <upb_DecodeFast_Fixed32_Scalar_Tag1Byte+0xc> 8: 14000000 b 0x8 <upb_DecodeFast_Fixed32_Scalar_Tag1Byte+0x8> 0000000000000008: R_AARCH64_JUMP26 _upb_FastDecoder_DecodeGeneric c: d370fca8 lsr x8, x5, #48 10: b840102 ldur w9, [x1, #0x1] 14: 5280002a mov w10, #0x1 // =1 18: 91001421 add x1, x1, #0x5 1c: b8286849 str w9, [x2, x8] 20: d358fca8 lsr x8, x5, #24 24: f9400409 ldr x9, [x0, #0x8] 28: 9ac82148 lsl x8, x10, x8 2c: eb01013f cmp x9, x1 30: 54000149 b.ls 0x58 <upb_DecodeFast_Fixed32_Scalar_Tag1Byte+0x58> 34: 79400029 ldrh w9, [x1] 38: 9348fc6a asr x10, x3, #8 3c: 12001c6b and w11, w3, #0xff 40: aa040104 orr x4, x8, x4 44: 8a09016b and x11, x11, x9 48: 8b0b054a add x10, x10, x11, lsl #1 4c: a941994b ldp x11, x6, [x10, #0x18] 50: ca090165 eor x5, x11, x9 54: d61f00c0 br x6 58: aa040104 orr x4, x8, x4 5c: 14000000 b 0x5c <upb_DecodeFast_Fixed32_Scalar_Tag1Byte+0x5c> 000000000000005c: R_AARCH64_JUMP26 upb_DecodeFast_MessageIsDoneFallback ``` </details> PiperOrigin-RevId: 765632464

fix a compile warning

27fcf9b

This change fixes the following compiler warning: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]

liujisi added a commit that referenced this pull request Sep 4, 2014

Merge pull request #8 from huahang/patch-1

1392f42

fix a compile warning

liujisi merged commit 1392f42 into protocolbuffers:master Sep 4, 2014

cloudkey mentioned this pull request Feb 4, 2015

FileDescriptorTables *** glibc detected *** double free or corruption (out) #194

Closed

roczpwu mentioned this pull request Jul 21, 2017

protobuf-3.3.2 segment fault: 11 #3402

Closed

FZUPotato mentioned this pull request Aug 21, 2017

coredump under the MIPS64 architecture #3532

Closed

jakiechris mentioned this pull request Nov 20, 2017

[solved, pls close this issue] protobuf crashes on android 4.4.2 on Huawei p7 #3922

Closed

gatkinso mentioned this pull request Nov 23, 2017

[C++] Intermittent Segmentation fault Mutex MacOS #2943

Closed

E-HERO mentioned this pull request Dec 3, 2017

proto used by executable file and shared lib crash #3991

Closed

ujmedia mentioned this pull request Jul 23, 2018

terminate called after throwing an instance of 'std::system_error' - after switching to version 3.6.0 (from 3.5.1) #4958

Closed

catskul mentioned this pull request Aug 21, 2018

Problems with Python Layer: Protobuf Internal Error - Mutex Lock #3671

Closed

TeBoring pushed a commit to TeBoring/protobuf that referenced this pull request Jan 19, 2019

Merge pull request protocolbuffers#8 from cfallin/master

efffb86

Amalgamated distribution (upb.c/upb.h) tool.

arnow117 mentioned this pull request Apr 1, 2019

python: SIGSEGV when use PyImport_Import import symbol_database #5979

Closed

sunbibei mentioned this pull request Sep 26, 2019

-m32 is not compatible with -freg-struct-return #6700

Closed

snehasinha13 mentioned this pull request Sep 30, 2020

Weird SIGSEGV in protobuf import #7931

Closed

xianggao mentioned this pull request Oct 27, 2021

core dump initializing at google::protobuf::internal::EpsCopyInputStream::ReadString #9163

Closed

saai63 mentioned this pull request Dec 7, 2021

MessageToJsonString() always seems to crash when linked statically to protobuf #9286

Closed

sin-zx mentioned this pull request Jan 18, 2022

coredump when calls MessageToJsonString() #9417

Closed

blacktek mentioned this pull request Jun 7, 2022

segfault with both php 7.4 and php 8.1 in _zend_is_inconsistent (ht=0x0, file=0x5616496c7238 #10113

Closed

blacktek mentioned this pull request Sep 22, 2022

Protobuf PHP compiled library segmentation faults googleads/google-ads-php#845

Closed

rong-lai mentioned this pull request Jul 25, 2023

Occasional coredump occurred when using ParseFromString #13387

Closed

rschu1ze mentioned this pull request Oct 24, 2023

Silence MSAN warning when running protoc ClickHouse/google-protobuf#3

Closed

babuveld mentioned this pull request Jan 12, 2024

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

Closed

M-Labedzki mentioned this pull request May 23, 2024

Invalid symbol name: google.protobuf.@ #16940

Closed

xuquanwei2019 mentioned this pull request Jun 27, 2025

AddDescriptors is not thread safe, but multi-thread access may occur when the SO is opened through dlopen #22425

Closed

kkzheng mentioned this pull request Oct 30, 2025

coredump in RepeatedPtrFieldBase::DestroyProtos() #24221

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix a compile warning#8

fix a compile warning#8
liujisi merged 1 commit intoprotocolbuffers:masterfrom
huahang:patch-1

huahang commented Sep 3, 2014

Uh oh!

liujisi commented Sep 4, 2014

Uh oh!

xfxyjwf commented Sep 4, 2014

Uh oh!

huahang commented Sep 4, 2014

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

huahang commented Sep 3, 2014

Uh oh!

liujisi commented Sep 4, 2014

Uh oh!

xfxyjwf commented Sep 4, 2014

Uh oh!

huahang commented Sep 4, 2014

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants