This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/13119] Erroneous "libgcc_s.so.1 must be installed for pthread_cancel to work" message


https://sourceware.org/bugzilla/show_bug.cgi?id=13119

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #4 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
This is not really due the fact process has no virtual memory left neither due
synchronization issues on libgcc_s.so loading, but rather due Linux overcommit
making subsequent mprotect on returned mmap memory fail with ENOMEM.

With vm.overcommit_memory=0 (default on my system) I get:

[pid 28817] mmap(NULL, 2185488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
3, 0) = 0x7fc0b850b000
[pid 28817] mprotect(0x7fc0b8521000, 2093056, PROT_NONE) = -1 ENOMEM (Cannot
allocate memory)
[pid 28817] mmap(0x7fc0b8720000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = -1 ENOMEM (Cannot allocate
memory)

Not considering overcommit this should fail, since mmap requested a memory of
size 0x215910 (2185488) and kernel returned 0x7fc0b850b000.  So a mprotect of
(0x7fc0b8521000, 0x7fc0b8720000) should not fail since it is within
(0x7fc0b850b000, 0x7fc0b8720910).

The test pass with vm.overcommit_memory=2 (always check, never overcommit):

[pid 29891] mmap(NULL, 2185488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
3, 0) = 0x7f71c0028000
[pid 29891] mprotect(0x7f71c003e000, 2093056, PROT_NONE) = 0
[pid 29891] mmap(0x7f71c023d000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7f71c023d000
[...]
[pid 29891] exit(0)                     = ?
[pid 29889] <... futex resumed> )       = 0
[pid 29891] +++ exited with 0 +++
exit_group(0) 

So I do not think this is an issue with glibc itself and afaik there is not
non-portable mmap flag to use to avoid overcommit in such mmap call.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]