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

Jump to bottom

Do not use probing to determining main data root start if dl_iterate_phdr is available (Linux) #432

Closed
ivmai opened this issue Mar 8, 2022 · 3 comments
Closed

Do not use probing to determining main data root start if dl_iterate_phdr is available (Linux) #432

ivmai opened this issue Mar 8, 2022 · 3 comments
Labels
feature-request

Comments

@ivmai
Copy link
Owner

ivmai commented Mar 8, 2022

On behalf of @fweimer-rh (copied from #409):

dl_iterate_phdr should already give you the segment boundaries, without the need for probing.
These segfaults are really confusing to developers, so we would really like to find a way to eliminate them. Why are they needed?

I'm running on Fedora Linux with glibc 2.30. dl_iterate_phdr is definitely available, I can see GC_register_main_static_data return FALSE, which means that GC_register_dynamic_libraries_dl_iterate_phdr does NOT take the quick exit path, and performs the full scan.
However, I still see a segfault, and this is before GC_register_data_segments is even called. Here's the backtrace at the time of the segfault:

#0  0x00007ffff70e207e in GC_find_limit_with_bound (p=0x2cf20f0 "", up=0, bound=0x0) at ../src/extra/../os_dep.c:1028
#1  0x00007ffff70e20ee in GC_find_limit (p=0x2cf20f0, up=0) at ../src/extra/../os_dep.c:1040
#2  0x00007ffff70e1edc in GC_init_linux_data_start () at ../src/extra/../os_dep.c:472
#3  0x00007ffff70e03d3 in GC_init () at ../src/extra/../misc.c:1217
...
@ivmai ivmai mentioned this issue Mar 8, 2022
Closed
ivmai added a commit that referenced this issue Mar 10, 2022
@ivmai
Do not probe to find main data root start if dl_iterate_phdr exists
c9b3ca8 
Issue #432 (bdwgc).

This avoids invocation of GC_find_limit to get GC_data_start value in
case of GC_register_data_segments is not called.

* misc.c [SEARCH_FOR_DATA_START] (GC_init): Call
GC_init_linux_data_start() only if GC_REGISTER_MAIN_STATIC_DATA();
move GC_init_linux_data_start() call down (to be close but precede
GC_dirty_init call); add comment.
@ivmai
Copy link
Owner Author

ivmai commented Mar 11, 2022

@fweimer-rh, please check the above commit - it should not cause Sigsegv.

@ivmai ivmai closed this as completed Mar 11, 2022
@ivmai
Copy link
Owner Author

ivmai commented Mar 11, 2022

/cc @T-J-Teru

@sasshka
Copy link

sasshka commented Mar 12, 2022

I confirm there's no SIGSEGV anymore when running gdb under gdb during the gc initialization

ivmai added a commit that referenced this issue Mar 13, 2022
@ivmai
Do not probe to find main data root start if dl_iterate_phdr exists
8868a7a 
(a cherry-pick of commit c9b3ca8 from 'master')

Issue #432 (bdwgc).

This avoids invocation of GC_find_limit to get GC_data_start value in
case of GC_register_data_segments is not called.

* misc.c [SEARCH_FOR_DATA_START] (GC_init): Call
GC_init_linux_data_start() only if GC_REGISTER_MAIN_STATIC_DATA();
move GC_init_linux_data_start() call down (to be close but precede
GC_dirty_init call); add comment.
* misc.c [NETBSD && __ELF__] (GC_init): Call GC_init_netbsd_elf() only
if GC_REGISTER_MAIN_STATIC_DATA(); move GC_init_netbsd_elf() call down
(to be close but precede GC_dirty_init call).
* misc.c [GC_ASSERTIONS && GC_ALWAYS_MULTITHREADED
&& (SEARCH_FOR_DATA_START || NETBSD)] (GC_init): Move LOCK/UNLOCK down
to keep GC_init_linux_data_start and GC_init_netbsd_elf calls wrapped.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature-request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ivmai @sasshka