[bug #49730] /proc/PID/environ returns I/O errors on read attempts

URL: Summary: /proc/PID/environ returns I/O errors on read attempts Project: The GNU Hurd Submitted by: baccala Submitted on: Tue 29 Nov 2016 07:42:00 AM GMT Category: Hurd Servers

Re: Unreclaimed swap space upon process termination?

Hello, Thomas Schwinge, on Mon 28 Nov 2016 17:10:26 +0100, wrote: > ..., but on the new ("bad") system, the first non-sensical (huge; > -2147479552 is 0x80001000) vm_allocate call actually succeeds: Yes, the userland address space is now 3G again, so it can now indeed allocate that much. > I

Re: Unreclaimed swap space upon process termination?

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: > > $

Re: Unreclaimed swap space upon process termination?

Hello, Thomas Schwinge, on Mon 28 Nov 2016 16:03:44 +0100, wrote: > But nevertheless, unreclaimed swap space upon process > termination sounds like a bug? It's actually not really a new problem. It has just been emphasized more with recent memory management changes. Samuel

Re: Unreclaimed swap space upon process termination?

On Mon, Nov 28, 2016 at 04:03:44PM +0100, Thomas Schwinge wrote: > 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. It's a known issue, a side effect of the page cache

Unreclaimed swap space upon process termination?

Hi! 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 $

Re: C++ vs. glibc/Hurd/Mach headers

Hi! On Sun, 27 Nov 2016 17:14:26 +0100, Samuel Thibault wrote: > Thomas Schwinge, on Sat 26 Nov 2016 19:53:34 +0100, wrote: > > When changing the GDB source code to use kern_return_t (or int) instead > > of error_t, I still see hurd.h:__hurd_fail and > >