|
From: Igmar P. <mai...@jd...> - 2004-10-10 15:19:46
|
Hi, In coregrind/vg_main.c, around line 2790 : // Get the current process datasize rlimit, and set it to zero. // This prevents any internal uses of brk() from having any effect. // We remember the old value so we can restore it on exec, so that // child processes will have a reasonable brk value. VG_(getrlimit)(VKI_RLIMIT_DATA, &VG_(client_rlimit_data)); zero.rlim_max = VG_(client_rlimit_data).rlim_max; VG_(setrlimit)(VKI_RLIMIT_DATA, &zero); The limit actually get's set, but is never raised. This triggers grsec, which rightfully complains that later allocations in the data segment exceed the existing limits. This might be worth looking in to. Regards, Igmar |
|
From: Tom H. <th...@cy...> - 2004-10-10 16:04:01
|
In message <Pin...@jd...>
Igmar Palsenberg <mai...@jd...> wrote:
> In coregrind/vg_main.c, around line 2790 :
>
> // Get the current process datasize rlimit, and set it to zero.
> // This prevents any internal uses of brk() from having any effect.
> // We remember the old value so we can restore it on exec, so that
> // child processes will have a reasonable brk value.
> VG_(getrlimit)(VKI_RLIMIT_DATA, &VG_(client_rlimit_data));
> zero.rlim_max = VG_(client_rlimit_data).rlim_max;
> VG_(setrlimit)(VKI_RLIMIT_DATA, &zero);
>
> The limit actually get's set, but is never raised. This triggers grsec,
> which rightfully complains that later allocations in the data segment
> exceed the existing limits.
When you that it is never raised, what do you mean? It isn't supposed
to be raised in the valgrinded process - that is the whole point. It
should be restored on exec however. Is that what you are saying isn't
happening?
Equally, which later alloctions in the data segment are you talking
about? The whole point is to prevent any allocations in the data
segment and force the use of mmap instead.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Igmar P. <mai...@jd...> - 2004-10-10 17:17:34
|
> > The limit actually get's set, but is never raised. This triggers grsec, > > which rightfully complains that later allocations in the data segment > > exceed the existing limits. > > When you that it is never raised, what do you mean? It isn't supposed > to be raised in the valgrinded process - that is the whole point. It > should be restored on exec however. Is that what you are saying isn't > happening? I was confused by the manual page of brk(), since that indicates brk() returning -1 is things fail. Looking at the kernel code, brk() failing just returns the current data segment border. I'll simply patch grsec to make it shut up, since it's hardly of relevance on this devel machine. > Equally, which later alloctions in the data segment are you talking > about? The whole point is to prevent any allocations in the data > segment and force the use of mmap instead. Clear now. I'll fix up grsec in this case :) Igmar |
|
From: Tom H. <th...@cy...> - 2004-10-10 17:30:19
|
In message <Pin...@jd...>
Igmar Palsenberg <mai...@jd...> wrote:
>
> > > The limit actually get's set, but is never raised. This triggers grsec,
> > > which rightfully complains that later allocations in the data segment
> > > exceed the existing limits.
> >
> > When you that it is never raised, what do you mean? It isn't supposed
> > to be raised in the valgrinded process - that is the whole point. It
> > should be restored on exec however. Is that what you are saying isn't
> > happening?
>
> I was confused by the manual page of brk(), since that indicates brk()
> returning -1 is things fail. Looking at the kernel code, brk() failing
> just returns the current data segment border.
I believe there are substantial differences between what the brk
system call does and what the brk() function in glibc does, so you
might want to look at glibc as well.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-10-10 17:37:04
|
On Sun, 10 Oct 2004, Igmar Palsenberg wrote: > I was confused by the manual page of brk(), since that indicates brk() > returning -1 is things fail. Looking at the kernel code, brk() failing > just returns the current data segment border. Yes, it's one of the times when the kernel syscall and the glibc wrapper diverge significantly in behaviour. The man page describes the glibc version. I think getcwd() is another such example. N |