Bug#859923: [Pkg-zsh-devel] Bug#859923: linux-image-4.9.0-2-amd64: mmap system call problem
Control: close 859923 Control: retitle 807836 zshbuiltins: Clarify the meaning of "hard limit" in the documentation of 'ulimit' and 'unlimit' Ben Hutchings wrote on Wed, Apr 12, 2017 at 18:02:04 +0100: > Control: retitle -1 zshbuiltins(1): Explain what data segment means for ulimit > Control: reassign -1 zsh Let's close -1 as a duplicate of #807836. I've retitled the latter to include not only unlimit but also ulimit. Thanks for the report, Daniel
Bug#859923: linux-image-4.9.0-2-amd64: mmap system call problem
On Wed, Apr 12, 2017 at 06:02:04PM +0100, Ben Hutchings wrote: > It looks like you're using zsh, for which the manual page says: > > -d Kilobytes on the size of the data segment. > > While the bash manual page says similarly: > > -d The maximum size of a process's data segment > > These could both benefit from a longer description of 'data segment'. Anyway I tried to run "java -version" after setting "ulimit -d 20" to no avail. -- Fernando Santagata
Bug#859923: linux-image-4.9.0-2-amd64: mmap system call problem
Control: severity -1 normal Control: clone -1 -2 Control: retitle -1 zshbuiltins(1): Explain what data segment means for ulimit Control: reassign -1 zsh Control: retitle -2 bash(1): Explain what data segment means for ulimit Control: reassign -2 bash On Wed, 2017-04-12 at 10:07 +0200, Fernando Santagata wrote: [...] > Right now is at its default state: [...] > -d: data seg size (kbytes) 131072 No, the default is unlimited. [...] > previously I tried to increase it to 20, but it didn't work. > I guess the problem is with the heap, not the data segment. The 'data segment' includes the heap. From the setrlimit(2) manual page: RLIMIT_DATA The maximum size of the process's data segment (initialized data, uninitialized data, and heap). This limit affects calls to brk(2) and sbrk(2), which fail with the error ENOMEM upon encountering the soft limit of this resource. Looking at the implementation, I can see that it applies to all memory mappings that are writable, not shared and not specified as stack. I think that the above description is close enough to that. It looks like you're using zsh, for which the manual page says: -d Kilobytes on the size of the data segment. While the bash manual page says similarly: -d The maximum size of a process's data segment These could both benefit from a longer description of 'data segment'. Ben. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your sig. signature.asc Description: This is a digitally signed message part
Bug#859923: linux-image-4.9.0-2-amd64: mmap system call problem
On Tue, Apr 11, 2017 at 11:34:56PM +0100, Ben Hutchings wrote: > On Tue, 2017-04-11 at 22:55 +0200, Fernando Santagata wrote: > > On Mon, Apr 10, 2017 at 05:23:26PM +0100, Ben Hutchings wrote: > > > Control: tag -1 moreinfo > > > > > > On Sun, 2017-04-09 at 12:09 +0200, Fernando Santagata wrote: > > > > I think this is related to this thread in the linux-mm mailing list, > > > > dating > > > > back to kernel version 4.7, the first one that exibits this behavior: > > > > > > > > https://lists.gt.net/linux/kernel/2528084 > > > > > > > > This error shows even when using concurrent programming under Perl6, so > > > > it > > > > seems to be really related to sharing memory. > > > > > > > > The last usable kernel in this respect is version 4.6. > > > > > > The warning message tells you how to work around this (add kernel > > > parameter 'ignore_rlimit_data'). Doesn't that work? > > > > I only tried fiddling with ulimit, but ignore_rlimit_data works fine. > > > > I suggest adding either a warning in some doc file, or making that > > option the default, lest you receive dozens of stupid bug reports :-) > > I certainly don't want to disable a resource limit globally - the > failure to apply the data size limit was itself a bug. And I hope that > it is not very common to set data size limits that are too low, so we > don't have to document yet another change in the release notes that > will mostly be ignored. > > Can you please check whether the data limit is already set in a shell > (ulimit -d)? Right now is at its default state: $ ulimit -a -t: cpu time (seconds) unlimited -f: file size (blocks) unlimited -d: data seg size (kbytes) 131072 -s: stack size (kbytes) 8192 -c: core file size (blocks) 0 -m: resident set size (kbytes) unlimited -u: processes 31447 -n: file descriptors1024 -l: locked-in-memory size (kbytes) 64 -v: address space (kbytes) unlimited -x: file locks unlimited -i: pending signals 31447 -q: bytes in POSIX msg queues 819200 -e: max nice0 -r: max rt priority 0 -N 15: unlimited previously I tried to increase it to 20, but it didn't work. I guess the problem is with the heap, not the data segment. -- Fernando Santagata
Bug#859923: linux-image-4.9.0-2-amd64: mmap system call problem
[Reply to all, not just to me] On Tue, 2017-04-11 at 22:55 +0200, Fernando Santagata wrote: > On Mon, Apr 10, 2017 at 05:23:26PM +0100, Ben Hutchings wrote: > > Control: tag -1 moreinfo > > > > On Sun, 2017-04-09 at 12:09 +0200, Fernando Santagata wrote: > > > I think this is related to this thread in the linux-mm mailing list, > > > dating > > > back to kernel version 4.7, the first one that exibits this behavior: > > > > > > https://lists.gt.net/linux/kernel/2528084 > > > > > > This error shows even when using concurrent programming under Perl6, so it > > > seems to be really related to sharing memory. > > > > > > The last usable kernel in this respect is version 4.6. > > > > The warning message tells you how to work around this (add kernel > > parameter 'ignore_rlimit_data'). Doesn't that work? > > I only tried fiddling with ulimit, but ignore_rlimit_data works fine. > > I suggest adding either a warning in some doc file, or making that > option the default, lest you receive dozens of stupid bug reports :-) I certainly don't want to disable a resource limit globally - the failure to apply the data size limit was itself a bug. And I hope that it is not very common to set data size limits that are too low, so we don't have to document yet another change in the release notes that will mostly be ignored. Can you please check whether the data limit is already set in a shell (ulimit -d)? Ben. -- Ben Hutchings 73.46% of all statistics are made up. signature.asc Description: This is a digitally signed message part
Bug#859923: [Fwd: Re: Bug#859923: linux-image-4.9.0-2-amd64: mmap system call problem]
Forwarded Message From: Fernando Santagata <na...@ipers.net> To: Ben Hutchings <b...@decadent.org.uk> Subject: Re: Bug#859923: linux-image-4.9.0-2-amd64: mmap system call problem Date: Tue, 11 Apr 2017 22:55:05 +0200 Message-id: <20170411205505.np365524kv2go...@gretux.ipers.net> On Mon, Apr 10, 2017 at 05:23:26PM +0100, Ben Hutchings wrote: > Control: tag -1 moreinfo > > On Sun, 2017-04-09 at 12:09 +0200, Fernando Santagata wrote: > > I think this is related to this thread in the linux-mm mailing list, dating > > back to kernel version 4.7, the first one that exibits this behavior: > > > > https://lists.gt.net/linux/kernel/2528084 > > > > This error shows even when using concurrent programming under Perl6, so it > > seems to be really related to sharing memory. > > > > The last usable kernel in this respect is version 4.6. > > The warning message tells you how to work around this (add kernel > parameter 'ignore_rlimit_data'). Doesn't that work? I only tried fiddling with ulimit, but ignore_rlimit_data works fine. I suggest adding either a warning in some doc file, or making that option the default, lest you receive dozens of stupid bug reports :-) Thank you! -- Fernando Santagata
Bug#859923: linux-image-4.9.0-2-amd64: mmap system call problem
Control: tag -1 moreinfo On Sun, 2017-04-09 at 12:09 +0200, Fernando Santagata wrote: [...] > The last line in dmesg is: > > [ 503.531581] mmap: java (6830): VmData 134582272 exceed data ulimit > 134217728. Update limits or use boot option ignore_rlimit_data. > > but > > $ ulimit > unlimited ulimit with no options shows the file size limit, not the data size limit. > I think this is related to this thread in the linux-mm mailing list, dating > back to kernel version 4.7, the first one that exibits this behavior: > > https://lists.gt.net/linux/kernel/2528084 > > This error shows even when using concurrent programming under Perl6, so it > seems to be really related to sharing memory. > > The last usable kernel in this respect is version 4.6. The warning message tells you how to work around this (add kernel parameter 'ignore_rlimit_data'). Doesn't that work? Ben. -- Ben Hutchings 73.46% of all statistics are made up. signature.asc Description: This is a digitally signed message part
Bug#859923: linux-image-4.9.0-2-amd64: mmap system call problem
Package: src:linux Version: 4.9.18-1 Severity: important Dear Maintainer, Using kernel 4.9 (and all previous kernels up, but not including version 4.6) I receive this error: $ java -version OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory 0x7f2033e1e000, 172032, 0) failed; error='Cannot allocate memory' (errno=12) # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (mmap) failed to map 172032 bytes for committing reserved memory. # An error report file with more information is saved as: # /home/nando/dev/bug/hs_err_pid6829.log $ readlink -f `which java` /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java $ dpkg -S /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java openjdk-8-jre-headless:amd64: /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java The first three lines of the error file read: # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (mmap) failed to map 172032 bytes for committing reserved memory. The last line in dmesg is: [ 503.531581] mmap: java (6830): VmData 134582272 exceed data ulimit 134217728. Update limits or use boot option ignore_rlimit_data. but $ ulimit unlimited I think this is related to this thread in the linux-mm mailing list, dating back to kernel version 4.7, the first one that exibits this behavior: https://lists.gt.net/linux/kernel/2528084 This error shows even when using concurrent programming under Perl6, so it seems to be really related to sharing memory. The last usable kernel in this respect is version 4.6. -- Package-specific info: ** Version: Linux version 4.9.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170321 (Debian 6.3.0-11) ) #1 SMP Debian 4.9.18-1 (2017-03-30) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-2-amd64 root=UUID=afa7e916-e956-4a2f-976f-257b3e061777 ro vga=0x0307 ** Tainted: POE (12289) * Proprietary module has been loaded. * Out-of-tree module has been loaded. * Unsigned module has been loaded. ** Kernel log: [3.580067] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [3.586488] lpc_ich: Resource conflict(s) found affecting gpio_ich [3.592893] input: PC Speaker as /devices/platform/pcspkr/input/input9 [3.605551] usb-storage 3-1.8:1.0: USB Mass Storage device detected [3.611966] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 163840 ms ovfl timer [3.618617] RAPL PMU: hw unit of domain pp0-core 2^-16 Joules [3.619714] usb-storage 3-1.8:1.0: Quirks match for vid 05e3 pid 0723: 8000 [3.619746] scsi host4: usb-storage 3-1.8:1.0 [3.619801] usbcore: registered new interface driver usb-storage [3.644015] RAPL PMU: hw unit of domain package 2^-16 Joules [3.650238] RAPL PMU: hw unit of domain pp1-gpu 2^-16 Joules [3.658441] usbcore: registered new interface driver uas [3.672451] snd_hda_intel :01:00.1: Disabling MSI [3.678908] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client [3.701165] iTCO_vendor_support: vendor-support=0 [3.709165] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [3.709196] iTCO_wdt: Found a Cougar Point TCO device (Version=2, TCOBASE=0x0460) [3.709551] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [3.712834] [drm] Memory usable by graphics device = 2048M [3.712835] checking generic (e900 14) vs hw (d000 1000) [3.712836] [drm] Replacing VGA console driver [3.755786] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC892: line_outs=3 (0x14/0x15/0x16/0x0/0x0) type:line [3.755787] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [3.755788] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) [3.755789] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0 [3.755789] snd_hda_codec_realtek hdaudioC0D0:dig-out=0x1e/0x0 [3.755790] snd_hda_codec_realtek hdaudioC0D0:inputs: [3.755791] snd_hda_codec_realtek hdaudioC0D0: Front Mic=0x19 [3.755792] snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18 [3.755793] snd_hda_codec_realtek hdaudioC0D0: Line=0x1a [3.761033] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [3.761033] [drm] Driver supports precise vblank timestamp query. [3.783430] [drm] Initialized i915 1.6.0 20160919 for :00:02.0 on minor 0 [3.860170] intel_rapl: Found RAPL domain package [3.866761] intel_rapl: Found RAPL domain core [3.866762] intel_rapl: Found RAPL domain uncore [3.929172] Adding 27378684k swap on /dev/sda2. Priority:-1 extents:1 across:27378684k SSFS [4.157980] i915 :00:02.0: No connectors reported connected with modes [4.163969] snd_hda_intel :00:1b.0: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [4.170211] [drm] Cannot find any crtc or sizes - going 1024x768 [4.176615] checking generic (e900
