You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(11) |
2
|
|
3
(5) |
4
(8) |
5
(33) |
6
(11) |
7
(1) |
8
(3) |
9
(4) |
|
10
(3) |
11
(12) |
12
(17) |
13
(10) |
14
(13) |
15
(7) |
16
|
|
17
(2) |
18
(22) |
19
(9) |
20
(7) |
21
(1) |
22
(4) |
23
(1) |
|
24
|
25
(1) |
26
(3) |
27
(8) |
28
(3) |
29
(16) |
30
(4) |
|
31
|
|
|
|
|
|
|
|
From: Michael E. L. <me...@co...> - 2003-08-29 22:33:34
|
On Friday 29 August 2003 03:51 pm, Steve G wrote: > > As for doing a transaction based system, it sounds like you > are going to be doing a setjmp & longjmp when it doesn't > work out. This is similar in concept to libchkpt which is a > check pointing library. The only difference is that rather > than moving the process to another machine, you will want > to do something else. > > You may be able to adapt libsafe+libchkpt to achieve a > transaction based system. Sounds interesting. Great suggestion, thanks. I appreciate the pointers. I'll check out your additions to libsafe and look into combining a libckp= t=20 approach. As I understand it, our main problem with using libsafe is twof= old:=20 its termination of the process when an overflow is discovered, and libsaf= e=20 only covers certain C library functions. We'd want to mark sections of co= de=20 that should be run intstrumented no matter what functions are inside the=20 marked section. In addition, we're really looking for fine-grained tracking of memory (mo= re=20 than the bounds checking done by libsafe/libverify, Stackguard, Propolice= ,=20 etc.) -- and Valgrind seems to provide that capability very well. Cheers, Michael |
|
From: Brian M. <bm...@di...> - 2003-08-29 20:48:31
|
> > My mistake - you only get the second part of the report if the > uninitialised value is in memory. If it's in a register then you > don't as there isn't much to say. > > Your best bet in that case is to inspect the code at the failing > location and see if there is an obvious cause, and if not then to > try inserting some assertions using the valgrind macros to try and > work out what is uninitialised - assertions like this will do it: > > assert( !VALGRIND_CHECK_READABLE( &variable, sizeof( variable ) ) ); > Ah, it must be in a register -- of course, I should have thought of that. Thanks for the tip about the macro. I'll give it a try. Thanks again, --Brian |
|
From: Steve G <lin...@ya...> - 2003-08-29 19:51:29
|
>The motivating example here is a fairly ambitious >project to automatically patch certain known classes >of software vulnerabilities like stack or heap-based >overflows. Have you looked at libsafe? It might be an easier approach to do this kind of thing. As a matter of fact, I have hacked it to add instrumentation for several more overflows than the authors did. You can get my imprroved version here: www.web-insights.net/libsafe. You can diff it against the official version to see how easy it is to add instrumentation. As for doing a transaction based system, it sounds like you are going to be doing a setjmp & longjmp when it doesn't work out. This is similar in concept to libchkpt which is a check pointing library. The only difference is that rather than moving the process to another machine, you will want to do something else. You may be able to adapt libsafe+libchkpt to achieve a transaction based system. Sounds interesting. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Tom H. <th...@cy...> - 2003-08-29 19:50:47
|
In message <608...@pd...>
Brian Mosher <bm...@di...> wrote:
> It sounds like there is additional output that I should be seeing. Am I
> missing something? When you say that there is a second half to the error
> report -- Is that a summary group at the bottom of the report, or will the
> additional info appear along with the error statement in the body of the
> output?
My mistake - you only get the second part of the report if the
uninitialised value is in memory. If it's in a register then you
don't as there isn't much to say.
Your best bet in that case is to inspect the code at the failing
location and see if there is an obvious cause, and if not then to
try inserting some assertions using the valgrind macros to try and
work out what is uninitialised - assertions like this will do it:
assert( !VALGRIND_CHECK_READABLE( &variable, sizeof( variable ) ) );
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Michael E. L. <me...@co...> - 2003-08-29 19:41:31
|
On Friday 29 August 2003 02:13 am, Tom Hughes wrote: > In message <200...@co...> > > "Michael E. Locasto" <me...@co...> wrote: > > I'm wondering if there is any way that valgrind can be dynamically tu= rned > > on and off during execution; that is, instead of valgrind translating= and > > instrumenting the executable right away, can it allow the program to > > execute on the real CPU until a macro is called from the program, at > > which point it could start the translation and instrumentation until = some > > later point (another macro that VG will recognize) and return control= to > > the real CPU and the uninstrumented code. > > If you did that, how would valgrind know what memory was initialised > whe you turned it on? Any changes made while it would off would not be > known about and it wouldn't be able to report errors properly when you > turned it back on. In this context, it's ok. I'm looking to run the program inside Valgrind,= but=20 _not_ incur the cost of translation and emulation during much of the runt= ime.=20 The purpose would be to provide a sandbox for production servers that can= =20 protect against certain buffer overflow attacks. The "turn on" point would be where we care about starting to keep track o= f=20 values. A snapshot of the current "real" CPU state would be stored in mem= ory=20 and the instrumented execution (in valgrind) would begin. At the "turn of= f"=20 point, if all memory accesses were clean (no corruption of heap or stack,= =20 etc.) we would merrily return to the real CPU. If not, we would roll memo= ry=20 back to the last known good state snapshot and return to the real CPU. Kind of like how Valgrind does function calls, but in reverse. Cheers, Michael |
|
From: Michael E. L. <me...@co...> - 2003-08-29 19:25:10
|
On Friday 29 August 2003 03:30 am, Nicholas Nethercote wrote: > On Fri, 29 Aug 2003, Tom Hughes wrote: > > <snip/> > > If you only want to instrument certain functions, you could write a ski= n > that does that. Then for most of the program you'd have the 5x or so > slowdown you get with no instrumentation, and the instrumented function= s > would run more slowly. Accurately instrumenting only certain functions > may require debug information to be present in your programs, however. > Depends exactly what you want to do. Tom and Nick, thanks for your replies. Points well taken. This was my initial approach, and I began to write a skin to do just this= =2E=20 > Can you give more detail about what you want to do with this virtual > machine monitor? That might help in identifying ways of achieving your > goals. The motivating example here is a fairly ambitious project to automaticall= y=20 patch certain known classes of software vulnerabilities like stack or=20 heap-based overflows.=20 The primary use of the virtual machine monitor would be to test a suspect= ed=20 infection vector (the byte stream that will cause the overflow and the=20 subsequent appearance of a worm) on an appropriately instrumented=20 version of the application (Apache, etc.) If the infection vector does ca= use=20 an overflow, then we can use Valgrind to identify the specific buffer and= =20 detect if execution has shifted to the stack, heap, or some other locatio= n=20 (like an unused library function). This creates a transaction analogy, where "unsuccessful" transactions (th= ose=20 in which the potential infection vector causes infection/abnormal operati= on)=20 are rolled back (effectively ignored) and execution continues. Cheers, Michael |
|
From: Adam D. <am...@st...> - 2003-08-29 19:16:06
|
Perhaps valgrind should dump the context when it runs into a STACK = OVERFLOW? That would make these problems much easier to track down. Thanks, Adam |
|
From: Brian M. <bm...@di...> - 2003-08-29 18:37:27
|
>> That's only half the error - there should be a second half to the >> error report that describes the address of the uninitialised data. I re-ran it and here is the entire output around the error. ==10863== Use of uninitialised value of size 4 ==10863== at 0x808CF4F: void Filter(float*, float const*, float const*, float const*, int) (Filter/Filter.h:90) ==10863== by 0x808CC84: _t_ErrCode FilterTmplt(CBoundedBlock*, CBoundedBlock const*, unsigned char, unsigned char, unsigned char) (Filter/Filter.h:151) ==10863== by 0x808C967: FilterThreshold(CBoundedBlock*, CBoundedBlock const*, unsigned char, unsigned char, unsigned char) (Filter/Filter.cpp:44) ==10863== by 0x8069357: _Z13ReadP17CReadOutPK13CBlockIhEPK10CVectorIfEPK12CMatrixIfEhPK9CVectorItEPK 5CBlPSH_SC_ (Read.cpp:382) It sounds like there is additional output that I should be seeing. Am I missing something? When you say that there is a second half to the error report -- Is that a summary group at the bottom of the report, or will the additional info appear along with the error statement in the body of the output? Thanks again, --Brian |
|
From: Nicholas N. <nj...@ca...> - 2003-08-29 13:42:39
|
On Fri, 29 Aug 2003, Ken Weinert wrote: > Have I just missed this somewhere? Or is it something that valgrind > isn't really suited for? Er... missed what? > I've been looking for something that I could use to easily trace > program flow (trying to sort out a third party library and how it's > being used - I have source, but with callbacks and a data driven > architecture it's not really straightforward) and it just seemed that > valgrind would be able to do this. Valgrind could well be useful. What do you mean by "program flow"? N |
|
From: Josef W. <Jos...@gm...> - 2003-08-29 13:17:11
|
On Friday 29 August 2003 14:19, Ken Weinert wrote: > Have I just missed this somewhere? Or is it something that valgrind > isn't really suited for? > > I've been looking for something that I could use to easily trace > program flow (trying to sort out a third party library and how it's > being used - I have source, but with callbacks and a data driven > architecture it's not really straightforward) and it just seemed that > valgrind would be able to do this. > > Thanks for any info (oh, btw: the README_DEVELOPERS document seems to > be missing from the valgrind-20030725 distribution.) If it is enough for you to only get the call-graph instead of a full trace (which makes not that much sense because you quickly can get unmanagable huge amounts of trace data), checkout the Calltree skin, together with KCachegrind visualization (kcachegrind.sf.net). The integrated cache simulator can be switched off with "--simulate-cache=no" for faster performance. Josef |
|
From: Ken W. <Ken...@ih...> - 2003-08-29 12:20:36
|
Have I just missed this somewhere? Or is it something that valgrind isn't really suited for? I've been looking for something that I could use to easily trace program flow (trying to sort out a third party library and how it's being used - I have source, but with callbacks and a data driven architecture it's not really straightforward) and it just seemed that valgrind would be able to do this. Thanks for any info (oh, btw: the README_DEVELOPERS document seems to be missing from the valgrind-20030725 distribution.) --=20 .--. Ken Weinert Ken...@ih...=20 |o_o | ||_/ | 303-858-6956 (V) 303-705-4258 (F)=20 // \ \ (| | ) GnuPG: 9274F1CE GnuPG available at http://www.gnupg.org/ /'\_ _/`\=20 \___)=3D(___/ 1D87 3720 BB77 4489 A928 79D6 F8EC DD76 9274 F1CE Truncation: the process of starting with an elephant and ending with a hose - Vitenka |
|
From: Nicholas N. <nj...@ca...> - 2003-08-29 07:31:23
|
On Fri, 29 Aug 2003, Tom Hughes wrote: > > I'm wondering if there is any way that valgrind can be dynamically turned on > > and off during execution; that is, instead of valgrind translating and > > instrumenting the executable right away, can it allow the program to execute > > on the real CPU until a macro is called from the program, at which point it > > could start the translation and instrumentation until some later point > > (another macro that VG will recognize) and return control to the real CPU and > > the uninstrumented code. > > If you did that, how would valgrind know what memory was initialised > whe you turned it on? Any changes made while it would off would not be > known about and it wouldn't be able to report errors properly when you > turned it back on. Yes, it doesn't seem possible with the Memcheck skin, because Memcheck's metadata (the A and V bits) depend on the entire execution history. It's the same with Addrcheck, Helgrind and Cachegrind. However, Michael also said: > I'm looking to turn valgrind into a kind of virtual machine monitor, > where only certain functions need to be instrumented. If said functions > behave badly, then control can return safely to the real CPU and the > side effects of the function undone. In which case the previous execution history might not matter. Unfortunately, I don't see how this could be made to work... switching from the real world to Valgrind-land seems exceedingly difficult. One example I think of immediately is signal handling -- if the program installed signal handlers before switching, the kernel would call these handlers without Valgrind having a chance to intercept and then the program would be half in Valgrind-land and half not, which would very quickly lead to disaster, I imagine. I'm sure there are other grand difficulties involved as well. If you only want to instrument certain functions, you could write a skin that does that. Then for most of the program you'd have the 5x or so slowdown you get with no instrumentation, and the instrumented functions would run more slowly. Accurately instrumenting only certain functions may require debug information to be present in your programs, however. Depends exactly what you want to do. Can you give more detail about what you want to do with this virtual machine monitor? That might help in identifying ways of achieving your goals. N |
|
From: Tom H. <th...@cy...> - 2003-08-29 06:14:07
|
In message <200...@co...>
"Michael E. Locasto" <me...@co...> wrote:
> I'm wondering if there is any way that valgrind can be dynamically turned on
> and off during execution; that is, instead of valgrind translating and
> instrumenting the executable right away, can it allow the program to execute
> on the real CPU until a macro is called from the program, at which point it
> could start the translation and instrumentation until some later point
> (another macro that VG will recognize) and return control to the real CPU and
> the uninstrumented code.
If you did that, how would valgrind know what memory was initialised
whe you turned it on? Any changes made while it would off would not be
known about and it wouldn't be able to report errors properly when you
turned it back on.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2003-08-29 06:12:50
|
In message <608...@pd...>
Brian Mosher <bm...@di...> wrote:
> I'm fairly new to valgrind and was wondering if there was a way to determine
> the actual memory address of the data that is being used in an
> un-initialized fashion.
>
> My error message is as follows:
>
> ==12355== Use of uninitialised value of size 4
> ==12355== at 0x4145D874: void Filter<float, float>(float*, float const*,
> float const*, float const*, int) (Filter/Filter.h:90)
> ==12355== by 0x4145D30A: _t_ErrCode FilterTmplt<float,
> float>(CBoundedBlock<float>*, CBoundedBlock<float> const*, unsigned char,
> unsigned char, unsigned char) (Filter/Filter.h:199)
> ==12355== by 0x4145CF4D: FilterThreshold(CBoundedBlock<float>*,
> CBoundedBlock<float> const*, unsigned char, unsigned char, unsigned char)
> (Filter/Filter.cpp:44)
That's only half the error - there should be a second half to the
error report that describes the address of the uninitialised data.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Brian M. <bm...@di...> - 2003-08-29 02:48:07
|
I'm fairly new to valgrind and was wondering if there was a way to determine the actual memory address of the data that is being used in an un-initialized fashion. My error message is as follows: ==12355== Use of uninitialised value of size 4 ==12355== at 0x4145D874: void Filter<float, float>(float*, float const*, float const*, float const*, int) (Filter/Filter.h:90) ==12355== by 0x4145D30A: _t_ErrCode FilterTmplt<float, float>(CBoundedBlock<float>*, CBoundedBlock<float> const*, unsigned char, unsigned char, unsigned char) (Filter/Filter.h:199) ==12355== by 0x4145CF4D: FilterThreshold(CBoundedBlock<float>*, CBoundedBlock<float> const*, unsigned char, unsigned char, unsigned char) (Filter/Filter.cpp:44) I see that the offending code is at address 0x4145D874. What I am missing is the memory address of the *data* that is being used. Is there any way to get valgrind to report the data address? I've looked in the docs, and tried a number of various switches to no avail. Sorry if I'm missing something obvious. Thanks in advance, --Brian (Valgrind is awesome, by the way.) |
|
From: Michael E. L. <me...@co...> - 2003-08-29 02:45:55
|
Hey all,
I'm wondering if there is any way that valgrind can be dynamically turned=
on=20
and off during execution; that is, instead of valgrind translating and=20
instrumenting the executable right away, can it allow the program to exec=
ute=20
on the real CPU until a macro is called from the program, at which point =
it=20
could start the translation and instrumentation until some later point=20
(another macro that VG will recognize) and return control to the real CPU=
and=20
the uninstrumented code.=20
I'm looking to turn valgrind into a kind of virtual machine monitor, wher=
e=20
only certain functions need to be instrumented. If said functions behave=20
badly, then control can return safely to the real CPU and the side effect=
s of=20
the function undone.
I played around with the idea of writing a skin to do this (much like the=
null=20
skin, however, I don't want to incur the cost of translating if the code=20
isn't going to be instrumented), but despite the good documentation on th=
e=20
website, I'm not sure if a skin is the proper solution; this seems more l=
ike=20
a fundamental change to the valgrind startup code. Is this possible?
Comments and suggestions are most welcome.
Cheers,
Michael
---------------------------------------------------------
For example,
// where the TURN_ON|OFF macros are defined
#include "valgrind.h"
int foo_process( char* data ){
// do some work that needs to be watched
}
int main(){
//...run, do some processing
VG_TURN_ON( skin_name ); /* turn valgrind & instrumentation on */
=09 foo_process( input_data ); /* invoke the code your interested in =
*/
VG_TURN_OFF( skin_name ); /* turn valgrind & instrumentation off */
//... keep on moving on
}
|