Skip to content

Conversation

pitrou
Copy link
Member

@pitrou pitrou commented Oct 7, 2025

Rationale for this change

Valgrind would report memory leaks induced by protobuf initialization on library load, for example:

==14628== 414 bytes in 16 blocks are possibly lost in loss record 22 of 26
==14628==    at 0x4914EFF: operator new(unsigned long) (vg_replace_malloc.c:487)
==14628==    by 0x8D0B6CA: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) [clone .isra.0] (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x8D33E62: google::protobuf::DescriptorPool::Tables::Tables() (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x8D340E2: google::protobuf::DescriptorPool::DescriptorPool(google::protobuf::DescriptorDatabase*, google::protobuf::DescriptorPool::ErrorCollector*) (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x8D341A2: google::protobuf::DescriptorPool::internal_generated_pool() (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x8D34277: google::protobuf::DescriptorPool::InternalAddGeneratedFile(void const*, int) (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x8D9C56F: google::protobuf::internal::AddDescriptorsRunner::AddDescriptorsRunner(google::protobuf::internal::DescriptorTable const*) (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x40D147D: call_init.part.0 (dl-init.c:70)
==14628==    by 0x40D1567: call_init (dl-init.c:33)
==14628==    by 0x40D1567: _dl_init (dl-init.c:117)
==14628==    by 0x40EB2C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)

This was triggered by the libprotobuf upgrade on conda-forge from 3.21.12 to 4.25.3.

What changes are included in this PR?

Add a Valgrind suppression for these leak reports, as there is probably not much we can do about them.

Are these changes tested?

Yes, by existing CI test.

Are there any user-facing changes?

No.

@pitrou
Copy link
Member Author

pitrou commented Oct 7, 2025

@github-actions crossbow submit test-conda-cpp-valgrind

@pitrou
Copy link
Member Author

pitrou commented Oct 7, 2025

Copy link

github-actions bot commented Oct 7, 2025

Revision: 90c193d

Submitted crossbow builds: ursacomputing/crossbow @ actions-c6463cc89b

Task Status
test-conda-cpp-valgrind GitHub Actions

Copy link
Contributor

@zanmato1984 zanmato1984 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with one nit.

@github-actions github-actions bot added awaiting committer review Awaiting committer review and removed awaiting review Awaiting review labels Oct 7, 2025
@pitrou
Copy link
Member Author

pitrou commented Oct 7, 2025

@github-actions crossbow submit test-conda-cpp-valgrind

Copy link

github-actions bot commented Oct 7, 2025

Revision: 8bccf7d

Submitted crossbow builds: ursacomputing/crossbow @ actions-d81ae2c48f

Task Status
test-conda-cpp-valgrind GitHub Actions

@pitrou pitrou merged commit 2e90823 into apache:main Oct 7, 2025
40 checks passed
@pitrou pitrou removed the awaiting committer review Awaiting committer review label Oct 7, 2025
@pitrou pitrou deleted the gh47742-valgrind branch October 7, 2025 20:18
Copy link

After merging your PR, Conbench analyzed the 2 benchmarking runs that have been run so far on merge-commit 2e90823.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 1 possible false positive for unstable benchmarks that are known to sometimes produce them.

raulcd pushed a commit that referenced this pull request Oct 8, 2025
…47743)

### Rationale for this change

Valgrind would report memory leaks induced by protobuf initialization on library load, for example:
```
==14628== 414 bytes in 16 blocks are possibly lost in loss record 22 of 26
==14628==    at 0x4914EFF: operator new(unsigned long) (vg_replace_malloc.c:487)
==14628==    by 0x8D0B6CA: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) [clone .isra.0] (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x8D33E62: google::protobuf::DescriptorPool::Tables::Tables() (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x8D340E2: google::protobuf::DescriptorPool::DescriptorPool(google::protobuf::DescriptorDatabase*, google::protobuf::DescriptorPool::ErrorCollector*) (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x8D341A2: google::protobuf::DescriptorPool::internal_generated_pool() (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x8D34277: google::protobuf::DescriptorPool::InternalAddGeneratedFile(void const*, int) (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x8D9C56F: google::protobuf::internal::AddDescriptorsRunner::AddDescriptorsRunner(google::protobuf::internal::DescriptorTable const*) (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x40D147D: call_init.part.0 (dl-init.c:70)
==14628==    by 0x40D1567: call_init (dl-init.c:33)
==14628==    by 0x40D1567: _dl_init (dl-init.c:117)
==14628==    by 0x40EB2C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
```

This was triggered by the `libprotobuf` upgrade on conda-forge from 3.21.12 to 4.25.3.

### What changes are included in this PR?

Add a Valgrind suppression for these leak reports, as there is probably not much we can do about them.

### Are these changes tested?

Yes, by existing CI test.

### Are there any user-facing changes?

No.

* GitHub Issue: #47742

Authored-by: Antoine Pitrou <[email protected]>
Signed-off-by: Antoine Pitrou <[email protected]>
zanmato1984 pushed a commit to zanmato1984/arrow that referenced this pull request Oct 15, 2025
…ation (apache#47743)

### Rationale for this change

Valgrind would report memory leaks induced by protobuf initialization on library load, for example:
```
==14628== 414 bytes in 16 blocks are possibly lost in loss record 22 of 26
==14628==    at 0x4914EFF: operator new(unsigned long) (vg_replace_malloc.c:487)
==14628==    by 0x8D0B6CA: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) [clone .isra.0] (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x8D33E62: google::protobuf::DescriptorPool::Tables::Tables() (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x8D340E2: google::protobuf::DescriptorPool::DescriptorPool(google::protobuf::DescriptorDatabase*, google::protobuf::DescriptorPool::ErrorCollector*) (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x8D341A2: google::protobuf::DescriptorPool::internal_generated_pool() (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x8D34277: google::protobuf::DescriptorPool::InternalAddGeneratedFile(void const*, int) (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x8D9C56F: google::protobuf::internal::AddDescriptorsRunner::AddDescriptorsRunner(google::protobuf::internal::DescriptorTable const*) (in /opt/conda/envs/arrow/lib/libprotobuf.so.25.3.0)
==14628==    by 0x40D147D: call_init.part.0 (dl-init.c:70)
==14628==    by 0x40D1567: call_init (dl-init.c:33)
==14628==    by 0x40D1567: _dl_init (dl-init.c:117)
==14628==    by 0x40EB2C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
```

This was triggered by the `libprotobuf` upgrade on conda-forge from 3.21.12 to 4.25.3.

### What changes are included in this PR?

Add a Valgrind suppression for these leak reports, as there is probably not much we can do about them.

### Are these changes tested?

Yes, by existing CI test.

### Are there any user-facing changes?

No.

* GitHub Issue: apache#47742

Authored-by: Antoine Pitrou <[email protected]>
Signed-off-by: Antoine Pitrou <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants