|
From: Igmar P. <mai...@jd...> - 2003-07-27 10:56:32
|
Hi, Is there an option to let Valgrind complain is a program screws up things in a .data or .rosection part of a program ? I just spend 4 hours debugging in a threaded program, that was giving tons of illegal reads / writes that where related to screwing up some values in a .data section. Is Valgrind suppose to complain about ? I'm still looking as why it went wrong, and why I was getting about 1500 errors (which where false positives). Regards, Igmar |
|
From: Tom H. <th...@cy...> - 2003-07-27 11:57:08
|
In message <Pin...@jd...>
Igmar Palsenberg <mai...@jd...> wrote:
> Is there an option to let Valgrind complain is a program screws up things
> in a .data or .rosection part of a program ?
Well it can't complain about writes to things in .data as that is
intended to be writable - it includes things like static variables
that the program is fully entitled to change.
As for .rodata that would normally be mapped as read only by the
operating system and hence would cause a SEGV if you wrote to it even
without valgrind. The same goes for any section in an ELF file that
has the READONLY attribute set.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Igmar P. <mai...@jd...> - 2003-07-28 09:01:59
|
> > Is there an option to let Valgrind complain is a program screws up things > > in a .data or .rosection part of a program ? > > Well it can't complain about writes to things in .data as that is > intended to be writable - it includes things like static variables > that the program is fully entitled to change. True, but the issue seems more complicated when dealing with threads. Something I did was definetely causing heap / stack corruption, and caused > 1000 false reports. > As for .rodata that would normally be mapped as read only by the > operating system and hence would cause a SEGV if you wrote to it even > without valgrind. The same goes for any section in an ELF file that > has the READONLY attribute set. That doesn't seem the case, at least not in real-life practice. Igmar |
|
From: Tom H. <th...@cy...> - 2003-07-28 09:18:32
|
In message <Pin...@jd...>
Igmar Palsenberg <mai...@jd...> wrote:
> > > Is there an option to let Valgrind complain is a program screws up things
> > > in a .data or .rosection part of a program ?
> >
> > Well it can't complain about writes to things in .data as that is
> > intended to be writable - it includes things like static variables
> > that the program is fully entitled to change.
>
> True, but the issue seems more complicated when dealing with threads.
> Something I did was definetely causing heap / stack corruption, and caused
> 1000 false reports.
I don't see why it should be more complicated when threads are bought
into the picture. The .data section is program global data and is
writable because it contains those variables which are defined at
file scope (either static or extern) and which are initialised
(uninitialised ones will be in .bss instead). As a result valgrind
can't mark it as uninitialised or unaddressable for the simple reason
that it isn't.
The simple fact is that whilst valgrind is very good it isn't
completely omniscient and there are some ways in which you can
corrupt things that it won't be able to detect.
> > As for .rodata that would normally be mapped as read only by the
> > operating system and hence would cause a SEGV if you wrote to it even
> > without valgrind. The same goes for any section in an ELF file that
> > has the READONLY attribute set.
>
> That doesn't seem the case, at least not in real-life practice.
Well it is here. Try writing a program that writes to a string
constant for example - something like this:
int main( int argc, char **argv )
{
char *x = "abcd";
x[0] = 'g';
exit( 0 );
}
That string constant will be put in the .rodata section, at least
if you are using gcc and don't specify -fwritable-strings when you
compile. It will also segfault when it hits the assignment.
If you think writes to a read-only section aren't segfaulting then
you should check the output of "objdump -h" to make sure the section
really is marked as read-only.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|