|
From: Paul A. C. <pa...@us...> - 2003-07-31 14:21:14
|
First, Valgrind is a very impressive tool. I've found it exceedingly helpful, and am quite impressed with it's performance, given what it does. So, sincere kudos to the team! I think this is a feature request rather than a bug report, but I'm not knowledgable enough in this area. I was porting some code to Linux, and in a fit of "get this thing linked so I can run it", I just created stubs for all unresolved symbols, which indeed allowed me to run. Mostly. I later ran into a situation where the program would crash, and gdb showed me the line: a simple assignment to a global variable. (Perhaps you've put two and two together already.) I spent hours on this one. gdb even let me set the value to what the program was trying to do. Valgrind didn't report any errors. Nothing obvious, but the program crashed reliably at that statement every time. The net is that I had stubbed a global *variable* symbol with a *function*. Thus, the assignment to that variable was actually trying to write into the TOC (is that the correct term?). Could Valgrind be enhanced to detect this error? Regards, Paul Clarke P.S. What is the preferred pronunciation for "Valgrind"? is it a long or short "i"? |
|
From: Tom H. <th...@cy...> - 2003-07-31 14:53:33
|
In message <1059661265.907.15.camel@pc>
Paul A. Clarke <pa...@us...> wrote:
> The net is that I had stubbed a global *variable* symbol with a
> *function*. Thus, the assignment to that variable was actually trying
> to write into the TOC (is that the correct term?).
I assume by TOC you mean the symbol table, in which case the answer
is no, that isn't what it is trying to do. What it is trying to do is
write to the text segment of the program - ie the actual code.
Basically assigning to a global variable will get the address of that
variable and then try and write the assigned value to that address. In
this case when the linker resolved the address of the symbol it
actually gets the address of the code for the function and the program
therefore tries to write to that address and fails.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-07-31 14:56:33
|
On 31 Jul 2003, Paul A. Clarke wrote: > The net is that I had stubbed a global *variable* symbol with a > *function*. Thus, the assignment to that variable was actually trying > to write into the TOC (is that the correct term?). > > Could Valgrind be enhanced to detect this error? Valgrind's memory checker tracks validity and addressability of memory bytes, but not read/write permissions, which is what you're basically asking for, if I understand correctly. It would be a pretty big change to how the memory checker works -- extra information would have to be tracked for each byte, and every read/write would have to have additional permission checking. This would slow the memory checker down, make it use even more memory, and make it more complex. And it could catch more bugs, but not many more I would guess -- you're the first person I'm aware of who's had such a problem, and that was only because you were doing something unusual. So I don't consider it a likely addition. Sorry. But thanks for the suggestion. > P.S. What is the preferred pronunciation for "Valgrind"? is it a long > or short "i"? Short, ie. like "Valgrinned" rather than "Valgrined"... almost everybody gets it wrong :) Although I use the second pronunciation as the verb form (with past participle "valground"), although I think Julian prefers "valgrindify". It's named after the gate into Valhalla (google for something like "valgrind -linux -seward norse" for info). Someone who knows about that sort of thing will probably now tell me that it should be pronounced "Fahl-grint" or something... :) N |
|
From: Josef W. <Jos...@gm...> - 2003-07-31 15:50:20
|
On Thursday 31 July 2003 16:56, Nicholas Nethercote wrote: > On 31 Jul 2003, Paul A. Clarke wrote: > > The net is that I had stubbed a global *variable* symbol with a > > *function*. Thus, the assignment to that variable was actually trying > > to write into the TOC (is that the correct term?). > > > > Could Valgrind be enhanced to detect this error? > > Valgrind's memory checker tracks validity and addressability of memory > bytes, but not read/write permissions, which is what you're basically > asking for, if I understand correctly. > > It would be a pretty big change to how the memory checker works -- extra > information would have to be tracked for each byte, and every read/write > would have to have additional permission checking. This would slow the > memory checker down, make it use even more memory, and make it more > complex. And it could catch more bugs, but not many more I would guess -- > you're the first person I'm aware of who's had such a problem, and that > was only because you were doing something unusual. > > So I don't consider it a likely addition. Sorry. But thanks for the > suggestion. Hmmm.. Writing to read-only places is an error easy to detect: it immediatly will produce a SEGFAULT. And valgrind doesn't need support for it, as the hardware already detects the error. Perhaps valgrind could provide a SEGFAULT handler and give out a meaningfull error message by checking /proc/pic/maps against the faulting address... Josef > It's named after the gate into Valhalla (google for something like > "valgrind -linux -seward norse" for info). Someone who knows about that > sort of thing will probably now tell me that it should be pronounced > "Fahl-grint" or something... :) Interesting ;-) |