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
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(6) |
2
(16) |
3
(3) |
4
(11) |
5
(2) |
|
6
(4) |
7
(11) |
8
(4) |
9
(6) |
10
(25) |
11
(10) |
12
(1) |
|
13
(2) |
14
(6) |
15
(16) |
16
(19) |
17
(16) |
18
(5) |
19
|
|
20
(4) |
21
(5) |
22
(21) |
23
(4) |
24
(14) |
25
(3) |
26
(9) |
|
27
(3) |
28
(13) |
29
(6) |
30
(16) |
|
|
|
|
From: Bastien C. <ba...@ch...> - 2003-04-30 21:35:12
|
On Wednesday 30 April 2003 22:56, Andr=E9s Rold=E1n wrote: > Hi, this is just a stupid question. > I'd want to know how can I access the valgrind cvs repository Does this help? http://sourceforge.net/cvs/?group_id=3D46268 Paragraph "Anonymous CVS Access" Salut, Bastien =2D-=20 -- The universe has its own cure for stupidity. -- -- Unfortunately, it doesn't always apply it. -- |
|
From: Vimal R. <vim...@ya...> - 2003-04-30 20:56:27
|
I'm sorry, I did'nt pay attention to the x86 part of the message. Shade only works for Solaris. Sorry abt that. -vimal --- Vimal Reddy <vim...@ya...> wrote: > I used Sun's shade. It's pretty good and also has the option where you can > choose to trace annulled (squashed) instructions. Which I guess would be the > same as the number of instructions issued (?). > The standard download also comes with a program (icount.c) that you can > easily > compile and run. > > Hope that helps. > > Thanks, > Vimal > > > --- Nicholas Nethercote <nj...@ca...> wrote: > > On 29 Apr 2003, David Brumley wrote: > > > > > Is it possible to use valgrind to get a total number of x86 assembly > > > instructions issued? Specifically, I'm trying to see how many assembly > > > instructions are issued for a given input into a crypto library. I've > > > looked and used profiling tools such as vtune and got total number of > > > instructions retired, but that's not quite what I'm interested in. I > > > want the total number of assembly instructions given to the processor... > > > > Lackey and Cachegrind (Valgrind skins, use --skin=lackey or > > --skin=cachegrind in any version later than 1.0.4) both measure x86 > > instructions retired (I think? I guess so) but not the number issued. > > > > > If not valgrind, does anyone have any suggestions? I can't find any > > > good execution tracing tools for x86 and linux.... > > > > You want Rabbit: www.scl.ameslab.gov/Projects/Rabbit/. I've used it lots, > > it's very good, gives you access to all your machine's performance > > counters. I have an Athlon, I know it gives you both instructions issued > > and retired, I think the Pentium counters probably give you those two. > > > > Or if you have a P4, Brink+Abyss: > > www.eg.bucknell.edu/~bsprunt/emon/brink_abyss/brink_abyss.shtm. I haven't > > tried it, but it looks very powerful. > > > > N > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > ===== > Vimal Reddy > Graduate Student, ECE > North Carolina State University > Raleigh, NC > Ph: (919) 836-8254 Web: http://www4.ncsu.edu/~vkreddy > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users ===== Vimal Reddy Graduate Student, ECE North Carolina State University Raleigh, NC Ph: (919) 836-8254 Web: http://www4.ncsu.edu/~vkreddy __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com |
|
From: <ar...@fl...> - 2003-04-30 20:54:01
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, this is just a stupid question. I'd want to know how can I access the valgrind cvs repository Thanks in advance =2D --=20 Andres Roldan, CSO Fluidsignal Group =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+sDiY2OByS7KTlusRAonzAJ9Y9zMiwTERg2092FYdSGtMZqctmQCfR1UF ZKoHcLqnbHneq2Em+0aIZgU=3D =3DakVf =2D----END PGP SIGNATURE----- |
|
From: John R.
|
David Brumley wrote: > [snip] > I've used vtune to get instructions retired, but that is sort of on the > "opposite" end of the processor that I'm interested in. [snip] > For the paper, I'd like to compare instructions > issued vs. instructions retired for the two programs. On the P4, those > two may not be the same for a number of weird P4 reasons (as I > understand talking to P4 experts). [snip] > I've tried valgrind with --single-step=yes, and see a couple of > different things that I think *may* be the instructions issued, like > "translate: new" in the output, but I'm not sure. Is this instructions > issued? All x86 implementations beginning with the Intel PentiumPro [ca.1995] have speculative, out-of-order execution, including along false conditional control paths (and even false _un_conditional control paths). Speculation is influenced by code alignment, icache and dcache hits/misses, interrupts and task switches, CPU temperature, etc. "Instructions issued" is almost meaningless for the hardware; certainly no software could ever compute it. -- John Reiser, jreiser@BitWagon.com |
|
From: Nicholas N. <nj...@ca...> - 2003-04-30 20:29:46
|
On Wed, 30 Apr 2003, Xiang Yan wrote: > 1. there is a malloc(24) (// any constant) crashs the app outside > valgrind, in valgrind however, it's just fine :( . any more clues on > this? It's possible your program corrupts some state used by the normal malloc(), but a different malloc() (such as Valgrind's) doesn't get corrupted. If you can find a different malloc() implementation and link with that (even dynamically with the LD_PRELOAD variable -- see the 'ld.so' man page for details) you might get a different result to the normal malloc(), which would confirm (I think?) this hypothesis. N |
|
From: Nicholas N. <nj...@ca...> - 2003-04-30 20:24:00
|
On Sun, 27 Apr 2003, Josef Weidendorfer wrote: > > > Nick, we should add a implementation of getcwd() to V, and use absolute > > > file paths. But this still doesn't work with chroot() programs :-( Done: Cachegrind now uses getcwd() at startup and just dumps cachegrind.out.<pid> in that directory at the end. Should fix the problems. I just committed it to the CVS HEAD. N |
|
From: Nicholas N. <nj...@ca...> - 2003-04-30 19:34:25
|
On Wed, 30 Apr 2003, Xiang Yan wrote: > 2. I have two errors in following oci call: > ==13548== Thread 4: > ==13548== Invalid write of size 4 > ==13548== at 0x81FFE55: kpughndl0 (in..) > ==13548== by 0x82071A3: kpughndl (in ..) > ==13548== by 0x81DBFBA: kpubndp0 (in ..) > ==13548== by 0x8077F74: OCIBindByPos (in .. /* &pocibind[0,1..n-1] as a param of this call*/ ) > ==13548== Address 0x41B6BA44 is 8 bytes after a block of size 4 alloc'd > ==13548== at 0x400485EC: __builtin_vec_new (vg_clientfuncs.c:156) > ==13548== by 0x8062AE8: myapp::prepareparams(void) (myapp.cpp:1270 /* OCIBind **pocibind = new OCIBind*[n]; */) > ... > Can I have more insight on "Address 0x41B6BA44 is 8 bytes after a block > of size 4 alloc'd" ? Your function kpughndl0() accesses the address 0x41B6BA44 which is invalid -- not addressible. However, it comes only 8 bytes after the end of a valid block allocated with new[] in myapp::prepareparams(), so there's a good chance that you've overrun the end of the block. N |
|
From: Nicholas N. <nj...@ca...> - 2003-04-30 19:31:31
|
On 30 Apr 2003, David Brumley wrote: > > You want Rabbit: www.scl.ameslab.gov/Projects/Rabbit/. > > Thanks, i was aware of those two, but the major drawback for either is > the need to recompile the source. You don't need to recompile the source with Rabbit. You can insert calls to Rabbit's library if you want to time parts of the program, but you can just run the program 'rabbit' (which comes from rabbit.c). By default it uses sampling to get estimates of all the events your processor can measure, but if you use the --events option it only measures a small number (on the Athlon it's 4) of events exactly. N |
|
From: David B. <dbr...@st...> - 2003-04-30 18:33:34
|
> > Lackey and Cachegrind (Valgrind skins, use --skin=lackey or > --skin=cachegrind in any version later than 1.0.4) both measure x86 > instructions retired (I think? I guess so) but not the number issued. > > > If not valgrind, does anyone have any suggestions? I can't find any > > good execution tracing tools for x86 and linux.... > > You want Rabbit: www.scl.ameslab.gov/Projects/Rabbit/. I've used it lots, > it's very good, gives you access to all your machine's performance > counters. I have an Athlon, I know it gives you both instructions issued > and retired, I think the Pentium counters probably give you those two. > > Or if you have a P4, Brink+Abyss: > www.eg.bucknell.edu/~bsprunt/emon/brink_abyss/brink_abyss.shtm. I haven't > tried it, but it looks very powerful. Thanks, i was aware of those two, but the major drawback for either is the need to recompile the source. I've used vtune to get instructions retired, but that is sort of on the "opposite" end of the processor that I'm interested in. To give you an idea why i'm asking, here's a short explanation. I'm developing timing attacks against OpenSSL (http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html). The timing characteristics we need are about 1% of the total execution time (measured in cycles). I've noticed that a small change in the source, say one extra mov instruction, will change the function offsets (say program A without the extra instruction vs. program B with the extra instruction). This alignment difference can skew the execution profile by 1% or a little more, changing the timing attack characteristics (unfortunately for security people it still works). Most notably, what algorithmically should result in say a negative timing difference when a bit of the key=0 can become a positive timing difference, showing that the P4's internal optimizations such as branch predictions, etc. can influence the results. For the paper, I'd like to compare instructions issued vs. instructions retired for the two programs. On the P4, those two may not be the same for a number of weird P4 reasons (as I understand talking to P4 experts). (And yes, I've verified the change isn't due to a bug in the program by inspecting the assembly output and checking for memory problems. In the end, I'm hoping to show simpler processors aren't affected by such small changes in the source, like the Pentium 2) So, I can't recompile my two test programs easily, since any change by adding libraries or external function calls changes the attack characteristic itself, as explained above. (I'm surprised that this isn't obviated on the websites for Rabbit and the like...inserting the code to measure timing can change the timing). I've tried valgrind with --single-step=yes, and see a couple of different things that I think *may* be the instructions issued, like "translate: new" in the output, but I'm not sure. Is this instructions issued? Thanks for everyone's help! -david |
|
From: Vimal R. <vim...@ya...> - 2003-04-30 18:00:43
|
I used Sun's shade. It's pretty good and also has the option where you can choose to trace annulled (squashed) instructions. Which I guess would be the same as the number of instructions issued (?). The standard download also comes with a program (icount.c) that you can easily compile and run. Hope that helps. Thanks, Vimal --- Nicholas Nethercote <nj...@ca...> wrote: > On 29 Apr 2003, David Brumley wrote: > > > Is it possible to use valgrind to get a total number of x86 assembly > > instructions issued? Specifically, I'm trying to see how many assembly > > instructions are issued for a given input into a crypto library. I've > > looked and used profiling tools such as vtune and got total number of > > instructions retired, but that's not quite what I'm interested in. I > > want the total number of assembly instructions given to the processor... > > Lackey and Cachegrind (Valgrind skins, use --skin=lackey or > --skin=cachegrind in any version later than 1.0.4) both measure x86 > instructions retired (I think? I guess so) but not the number issued. > > > If not valgrind, does anyone have any suggestions? I can't find any > > good execution tracing tools for x86 and linux.... > > You want Rabbit: www.scl.ameslab.gov/Projects/Rabbit/. I've used it lots, > it's very good, gives you access to all your machine's performance > counters. I have an Athlon, I know it gives you both instructions issued > and retired, I think the Pentium counters probably give you those two. > > Or if you have a P4, Brink+Abyss: > www.eg.bucknell.edu/~bsprunt/emon/brink_abyss/brink_abyss.shtm. I haven't > tried it, but it looks very powerful. > > N > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users ===== Vimal Reddy Graduate Student, ECE North Carolina State University Raleigh, NC Ph: (919) 836-8254 Web: http://www4.ncsu.edu/~vkreddy __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com |
|
From: Xiang Y. <xy...@pr...> - 2003-04-30 17:15:39
|
Hello, redhat linux ads/glibc 2.2.4/gcc2.96/pthread I'm using Oracle call interface apis in my app which is hard for me to = trace. I have two questions: 1. there is a malloc(24) (// any constant) crashs the app outside = valgrind, in valgrind however, it's just fine=20 :( . any more clues on this? =20 2. I have two errors in following oci call: =3D=3D13548=3D=3D Thread 4: =3D=3D13548=3D=3D Invalid write of size 4 =3D=3D13548=3D=3D at 0x81FFE55: kpughndl0 (in..) =3D=3D13548=3D=3D by 0x82071A3: kpughndl (in ..) =3D=3D13548=3D=3D by 0x81DBFBA: kpubndp0 (in ..) =3D=3D13548=3D=3D by 0x8077F74: OCIBindByPos (in .. /* = &pocibind[0,1..n-1] as a param of this call*/ ) =3D=3D13548=3D=3D Address 0x41B6BA44 is 8 bytes after a block of size = 4 alloc'd =3D=3D13548=3D=3D at 0x400485EC: __builtin_vec_new = (vg_clientfuncs.c:156) =3D=3D13548=3D=3D by 0x8062AE8: myapp::prepareparams(void) = (myapp.cpp:1270 /* OCIBind **pocibind =3D new OCIBind*[n]; */) ... Can I have more insight on "Address 0x41B6BA44 is 8 bytes after a block = of size 4 alloc'd" ? TIA |
|
From: Tom H. <th...@cy...> - 2003-04-30 07:36:51
|
In message <Pin...@ho...>
Dag Wieers <da...@wi...> wrote:
> PS These packages still have a problem with some private GLIBC symbols
> that are in the dependencies of the package. I can't seem to fix this by
> doing:
>
> %define __find_provides() /usr/lib/rpm/find-provides %* | grep -v '^libpthread.so'
> %define __find_requires() /usr/lib/rpm/find-requires %* | grep -v 'libc.so.6(GLIBC_PRIVATE)'
>
> So unless I find a clean way of doing this, you might have to install with
> --nodeps on some RH's (RH80 and RH73 afaik).
What I do is to add this to the spec file:
%define __find_requires %{_sourcedir}/valgrind-find-requires
along with a declaration of an extra source file:
Source1: valgrind-find-requires
The valgrind-find-requires file in my SOURCES directory then looks
like this:
#!/bin/sh
/usr/lib/rpm/find-requires "$@" | grep -v GLIBC_PRIVATE
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2003-04-30 07:34:09
|
In message <105...@ma...>
Stephane Donze <ste...@ex...> wrote:
> is it possible to patch the syscall wrappers so that they accept legal
> NULL values in their parameters ? I tried to find out how to do that,
> but I think I need some help to understant the many levels of
> indirections in the wrapper invocation.
This should do the trick:
--- valgrind-20030428/coregrind/vg_syscalls.c.accept 2003-04-30 08:31:09.000000000 +0100
+++ valgrind-20030428/coregrind/vg_syscalls.c 2003-04-30 08:32:02.000000000 +0100
@@ -2949,12 +2949,14 @@
{
Addr addr_p = ((UInt*)arg2)[1];
Addr addrlen_p = ((UInt*)arg2)[2];
- buf_and_len_pre_check ( tst, addr_p, addrlen_p,
- "socketcall.accept(addr)",
- "socketcall.accept(addrlen_in)" );
- KERNEL_DO_SYSCALL(tid,res);
- buf_and_len_post_check ( tst, res, addr_p, addrlen_p,
- "socketcall.accept(addrlen_out)" );
+ if (addr_p)
+ buf_and_len_pre_check ( tst, addr_p, addrlen_p,
+ "socketcall.accept(addr)",
+ "socketcall.accept(addrlen_in)" );
+ KERNEL_DO_SYSCALL(tid,res);
+ if (addr_p)
+ buf_and_len_post_check ( tst, res, addr_p, addrlen_p,
+ "socketcall.accept(addrlen_out)" );
}
break;
}
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-30 07:29:16
|
On 29 Apr 2003, David Brumley wrote: > Is it possible to use valgrind to get a total number of x86 assembly > instructions issued? Specifically, I'm trying to see how many assembly > instructions are issued for a given input into a crypto library. I've > looked and used profiling tools such as vtune and got total number of > instructions retired, but that's not quite what I'm interested in. I > want the total number of assembly instructions given to the processor... Lackey and Cachegrind (Valgrind skins, use --skin=lackey or --skin=cachegrind in any version later than 1.0.4) both measure x86 instructions retired (I think? I guess so) but not the number issued. > If not valgrind, does anyone have any suggestions? I can't find any > good execution tracing tools for x86 and linux.... You want Rabbit: www.scl.ameslab.gov/Projects/Rabbit/. I've used it lots, it's very good, gives you access to all your machine's performance counters. I have an Athlon, I know it gives you both instructions issued and retired, I think the Pentium counters probably give you those two. Or if you have a P4, Brink+Abyss: www.eg.bucknell.edu/~bsprunt/emon/brink_abyss/brink_abyss.shtm. I haven't tried it, but it looks very powerful. N |
|
From: Stephane D. <ste...@ex...> - 2003-04-30 07:13:57
|
Hello,
when using the following system call (which is legal, according to the
accept(2) man page), valgrind 1.9.5 complains about the parameters being
NULL:
for (;;) {
fd = accept(server, NULL, NULL);
if (fd != -1) {
/* Success. */
break;
}
==32217== Syscall param socketcall.accept(addrlen_in) contains
uninitialised or
unaddressable byte(s)
==32217== at 0x4073ADE6: __libc_accept (in /lib/i686/libc-2.3.1.so)
==32217== by 0x401755B9: accept (vg_intercept.c:142)
==32217== by 0x8049B10: (within /tmp/test)
==32217== Address 0x0 is not stack'd, malloc'd or free'd
==32217==
==32217== Syscall param socketcall.accept(addrlen_out) contains
uninitialised or
unaddressable byte(s)
==32217== at 0x4073ADE6: __libc_accept (in /lib/i686/libc-2.3.1.so)
==32217== by 0x401755B9: accept (vg_intercept.c:142)
==32217== by 0x8049B10: (within /tmp/test)
==32217== Address 0x0 is not stack'd, malloc'd or free'd
is it possible to patch the syscall wrappers so that they accept legal
NULL values in their parameters ? I tried to find out how to do that,
but I think I need some help to understant the many levels of
indirections in the wrapper invocation.
Thanks in advance
Stephane Donze
|
|
From: David B. <dbr...@st...> - 2003-04-30 00:59:56
|
Hi! Is it possible to use valgrind to get a total number of x86 assembly instructions issued? Specifically, I'm trying to see how many assembly instructions are issued for a given input into a crypto library. I've looked and used profiling tools such as vtune and got total number of instructions retired, but that's not quite what I'm interested in. I want the total number of assembly instructions given to the processor... If not valgrind, does anyone have any suggestions? I can't find any good execution tracing tools for x86 and linux.... thanks for any help! david |