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

Building firejail fbuilder creates 2 rodata sections and the data does not make valgrind happy. #118

Closed
matu3ba opened this issue Oct 6, 2021 · 3 comments

Comments

@matu3ba
Copy link

matu3ba commented Oct 6, 2021

I was trying to figure out the error source in fbuild, when I realized that mold creates two .rodata sections as you can see in the bug report. Using the regular linker does only create one .rodata section.
I think this makes valgrind very unhappy and it also looks abit odd.

Is this a bug of valgrind or is there some specification of how many identically named sections (or inspecial .rodata sections) may exist? Or is this some gcc shennanigan?
gdb starts fine, so I guess it has no problems with symbol lookup.

Reproducing instructions:

git clone https://github.com/netblue30/firejail
cd firejail
./configure && mold -run make -j8
cd src/fbuilder
objdump -h ./fbuilder | grep .rodata
@rui314
Copy link
Owner

rui314 commented Oct 7, 2021

In ELF, section names are not significant, so it is okay to create multiple sections with the same name. So, technically, this is a valgrind's issue. That being said, it isn't too hard for mold to not create multiple .rodata sections, so I'll make such change.

@rui314 rui314 closed this as completed in a8b2f52 Oct 7, 2021
@rui314
Copy link
Owner

rui314 commented Oct 7, 2021

With the above change, mold now creates .rodata.cst and .rodata.str instead of .rodata. Could you verify whether or not the above change fixes your problem?

@matu3ba
Copy link
Author

matu3ba commented Oct 7, 2021

I am really not sure why the sandbox was running and is currently not running, but the output is identical now with and without mold.
Valgrind does not complain, so I guess its fixed.

==22881== Memcheck, a memory error detector
==22881== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==22881== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==22881== Command: ./fbuilder /home/misterspoon/.local/nvim/bin/nvim +q
==22881==
Error: cannot run the sandbox
==22881==
==22881== HEAP SUMMARY:
==22881==     in use at exit: 35 bytes in 1 blocks
==22881==   total heap usage: 2 allocs, 1 frees, 135 bytes allocated
==22881==
==22881== LEAK SUMMARY:
==22881==    definitely lost: 0 bytes in 0 blocks
==22881==    indirectly lost: 0 bytes in 0 blocks
==22881==      possibly lost: 0 bytes in 0 blocks
==22881==    still reachable: 35 bytes in 1 blocks
==22881==         suppressed: 0 bytes in 0 blocks
==22881== Reachable blocks (those to which a pointer was found) are not shown.
==22881== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==22881==
==22881== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

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