Hi! On Mon, 28 Nov 2016 16:03:44 +0100, I wrote: > Updating a Debian GNU/Hurd virtual machine to recent packages after many > months, and then running the GCC testsuite, I observe the following > behavior, which should be reproducible with the executable in the > attached tarball: > > $ vmstat | grep swap\ free > swap free: 4096M > $ ./1.exe > $ vmstat | grep swap\ free > swap free: 3288M > $ ./1.exe > $ vmstat | grep swap\ free > swap free: 2495M > $ ./1.exe > $ vmstat | grep swap\ free > swap free: 1726M > $ ./1.exe > $ vmstat | grep swap\ free > swap free: 931M > $ ./1.exe > $ vmstat | grep swap\ free > swap free: 164M > $ ./1.exe > Bus error > $ vmstat | grep swap\ free > swap free: 0 > > At this point, the system doesn't recover from this low memory situation. > > For each invocation of the executable, there are three "no more room in > [...] (./1.exe([...])" messages on the Mach console. > > The executable is compiled from > [gcc]/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/insert/char/1.cc > from commit a050099a416f013bda35832b878d9a57b0cbb231 (gcc-6-branch branch > point; 2016-04-15), which doesn't look very spectacular -- apart from > maybe the __gnu_test::set_memory_limits call, which I'll try to figure > out what it does.
That uses setrlimit for RLIMIT_DATA, RLIMIT_RSS, RLIMIT_VMEM, RLIMIT_AS, but there is no change with that call removed. > But nevertheless, unreclaimed swap space upon process > termination sounds like a bug? > > Unless this a known issue, or somebody can quickly pinpoint the problem, > I'll try to bisect core system packages, between the version of the > "good" and "bad" disk images. Running with rpctrace, I see that on the old ("good") system, at the end of the process, we got: [...] task52(pid2198)->vm_deallocate (16973824 16) = 0 task52(pid2198)->vm_allocate (0 -2147479552 1) = 0x3 ((os/kern) no space available) task52(pid2198)->vm_allocate (0 -2147348480 1) = 0x3 ((os/kern) no space available) task52(pid2198)->vm_map (0 2097152 0 1 (null) 0 1 0 7 1) = 0 21405696 task52(pid2198)->vm_deallocate (21405696 614400) = 0 task52(pid2198)->vm_deallocate (23068672 434176) = 0 task52(pid2198)->vm_protect (22020096 135168 0 3) = 0 task52(pid2198)->vm_allocate (0 -2147479552 1) = 0x3 ((os/kern) no space available) 61<--68(pid2198)->proc_mark_exit_request (0 0) = 0 task52(pid2198)->task_terminate () = 0 Child 2198 exited with 0 ..., but on the new ("bad") system, the first non-sensical (huge; -2147479552 is 0x80001000) vm_allocate call actually succeeds: [...] task154(pid1080)->vm_deallocate (16973824 16) = 0 task154(pid1080)->vm_allocate (0 -2147479552 1) = 0 268742656 task154(pid1080)->vm_allocate (0 -2147479552 1) = 0x3 ((os/kern) no space available) task154(pid1080)->vm_allocate (0 -2147348480 1) = 0x3 ((os/kern) no space available) task154(pid1080)->vm_map (0 2097152 0 1 (null) 0 1 0 7 1) = 0 21655552 task154(pid1080)->vm_deallocate (21655552 364544) = 0 task154(pid1080)->vm_deallocate (23068672 684032) = 0 task154(pid1080)->vm_protect (22020096 135168 0 3) = 0 task154(pid1080)->vm_allocate (0 -2147479552 1) = 0x3 ((os/kern) no space available) task154(pid1080)->vm_deallocate (268742656 -2147479552) = 0 163<--170(pid1080)->proc_mark_exit_request (0 0) = 0 task154(pid1080)->task_terminate () = 0 Child 1080 exited with 0 I have not yet figured out where these vm_allocate calls and/or their huge size parameters are coming from. Grüße Thomas