|
From: Julian S. <js...@ac...> - 2016-11-04 11:33:02
|
Hi, Some time in the last year or so, V started to complain if attempts to extend the brk segment failed. This usually never shows with Memcheck because that replaces malloc and acquires memory from mmap, not brk. But for tools that don't replace malloc, the message is printed repeatedly, often many times. For a run of Firefox in Cachegrind, I get 56 instances of it. This is annoying, also because it doesn't matter that brk will fail, since the libc malloc then tries mmap instead, and succeeds. I would like to turn this into a one-time message, thusly: ==2109== brk segment overflow in thread #1: can't grow to 0x4b37000 ==2109== (see section Limitations in user manual) ==2109== NOTE: Further instances of this message will not be shown Are there any objections to that? The user would still be informed of the first brk failure, but not spammed with messages, as it currently stands. J |
|
From: Mark W. <mj...@re...> - 2016-11-04 11:50:38
|
On Fri, 2016-11-04 at 12:32 +0100, Julian Seward wrote: > Some time in the last year or so, V started to complain if attempts to > extend the brk segment failed. This usually never shows with Memcheck > because that replaces malloc and acquires memory from mmap, not brk. > But for tools that don't replace malloc, the message is printed repeatedly, > often many times. For a run of Firefox in Cachegrind, I get 56 instances > of it. This is annoying, also because it doesn't matter that brk will > fail, since the libc malloc then tries mmap instead, and succeeds. > > I would like to turn this into a one-time message, thusly: > > ==2109== brk segment overflow in thread #1: can't grow to 0x4b37000 > ==2109== (see section Limitations in user manual) > ==2109== NOTE: Further instances of this message will not be shown > > Are there any objections to that? The user would still be informed of > the first brk failure, but not spammed with messages, as it currently > stands. No objections here. Maybe make it so that -v will show them all? And if you detect that brk does succeed at a later time then a next fail should also be reported I think. BTW. This might be related to bug #357833. Linux 4.5 changing the definition of RLIMIT_DATA. Cheers, Mark |
|
From: Ivo R. <iv...@iv...> - 2016-11-04 19:08:37
|
2016-11-04 12:32 GMT+01:00 Julian Seward <js...@ac...>: > This is annoying, also because it doesn't matter that brk will > fail, since the libc malloc then tries mmap instead, and succeeds. > > Are there any objections to that? No objections to that. Also note that glibc has this mmap backend fallback but for example Solaris libc does not. So a failure to raise brk is treated as a hard error here. I. |