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
(14) |
2
(4) |
3
(12) |
|
4
(10) |
5
(5) |
6
(17) |
7
(3) |
8
(6) |
9
(4) |
10
|
|
11
(1) |
12
(8) |
13
(16) |
14
(14) |
15
(2) |
16
|
17
(3) |
|
18
(1) |
19
(6) |
20
(2) |
21
(5) |
22
(1) |
23
(2) |
24
(6) |
|
25
(2) |
26
(3) |
27
(2) |
28
(10) |
29
(5) |
30
(5) |
|
|
From: Mike M. <mi...@su...> - 2006-06-05 22:09:38
|
Yes, Nick, you've accurately summarized the problem. Too bad memcheck can't catch it, but you're right, the compiler did warn us, we just missed it. Thanks for the help. On 6/5/06, Nicholas Nethercote <nj...@cs...> wrote: > On Mon, 5 Jun 2006, Bob Rossi wrote: > > > OK, if we include > > #define _GNU_SOURCE /* ptsname_r() under Linux */ > > #include <sys/types.h> > > we get the prototype > > extern char *ptsname (int __fd) __attribute__ ((__nothrow__)); > > in the translation unit. > > > > If we include > > #include <sys/types.h> > > #define _GNU_SOURCE /* ptsname_r() under Linux */ > > we do not get the prototype in the translation unit. > > > > Then, we do this, > > char *name; > > if (!(name = ptsname(*masterfd))) > > > > In the case where the prototype is defined, it works fine and there > > is no crash. In the case where there is no prototype, we get this > > error. > > ../../../../cgdb/various/util/src/pseudo.c:304: warning: assignment > > makes pointer from integer without a cast > > > > That's because it thinks ptsname returns an int, and assigns it to a > > char*. This works when the sizeof(char*) == sizeof(int). However on this > > 64 amd machine, sizeof (char*)=8 sizeof (int)=4. This gives us the > > crash. > > > > Now, I'm wondering why valgrind reports no error on this circumstance. > > Would this be an improvement to memcheck? It took us quite some time to > > figure out the problem. > > Here's my guess as to what happened. The lower 4 bytes of the return > register (%rax, I think) got set to the return value. The upper 4 bytes got > left as whatever they were before; but importantly, those 4 bytes were > defined (ie. initialised). So the whole register is seen by Memcheck as > defined, because it is. You then used that value as a pointer, which was > bogus, but under Memcheck you got lucky/unlucky and the access through that > pointer hit addressable memory. Or possibly(?) Valgrind changes the way the > values go through the registers somewhat, and you luckily/unluckily ended up > with the correct value. > > The problem is that Memcheck does all its analysis at the byte-level. But > your problem here (assuming I've diagnosed it correctly) is that you > erroneously combined two 4-byte values into an 8-byte value which you then > used. As for whether Memcheck or another tool could detect this... it seems > like it would be hard, because multi-byte values get constructed from > single-byte or fewer-byte values all the time, and I can't think how to > distinguish the erroneous ones from the legitimate ones. > > So it's something that Memcheck can't detect. But the compiler can :) > > Nick > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Nicholas N. <nj...@cs...> - 2006-06-05 21:57:27
|
On Mon, 5 Jun 2006, Bob Rossi wrote: > OK, if we include > #define _GNU_SOURCE /* ptsname_r() under Linux */ > #include <sys/types.h> > we get the prototype > extern char *ptsname (int __fd) __attribute__ ((__nothrow__)); > in the translation unit. > > If we include > #include <sys/types.h> > #define _GNU_SOURCE /* ptsname_r() under Linux */ > we do not get the prototype in the translation unit. > > Then, we do this, > char *name; > if (!(name = ptsname(*masterfd))) > > In the case where the prototype is defined, it works fine and there > is no crash. In the case where there is no prototype, we get this > error. > ../../../../cgdb/various/util/src/pseudo.c:304: warning: assignment > makes pointer from integer without a cast > > That's because it thinks ptsname returns an int, and assigns it to a > char*. This works when the sizeof(char*) == sizeof(int). However on this > 64 amd machine, sizeof (char*)=8 sizeof (int)=4. This gives us the > crash. > > Now, I'm wondering why valgrind reports no error on this circumstance. > Would this be an improvement to memcheck? It took us quite some time to > figure out the problem. Here's my guess as to what happened. The lower 4 bytes of the return register (%rax, I think) got set to the return value. The upper 4 bytes got left as whatever they were before; but importantly, those 4 bytes were defined (ie. initialised). So the whole register is seen by Memcheck as defined, because it is. You then used that value as a pointer, which was bogus, but under Memcheck you got lucky/unlucky and the access through that pointer hit addressable memory. Or possibly(?) Valgrind changes the way the values go through the registers somewhat, and you luckily/unluckily ended up with the correct value. The problem is that Memcheck does all its analysis at the byte-level. But your problem here (assuming I've diagnosed it correctly) is that you erroneously combined two 4-byte values into an 8-byte value which you then used. As for whether Memcheck or another tool could detect this... it seems like it would be hard, because multi-byte values get constructed from single-byte or fewer-byte values all the time, and I can't think how to distinguish the erroneous ones from the legitimate ones. So it's something that Memcheck can't detect. But the compiler can :) Nick |
|
From: Bob R. <bob...@co...> - 2006-06-05 20:24:44
|
On Mon, Jun 05, 2006 at 08:25:54AM +1000, Nicholas Nethercote wrote:
> On Sun, 4 Jun 2006, Bob Rossi wrote:
>
> >> Before the experts answer you, it sounds to me like maybe you're passing
> >> around some un-initialized value which happens to have the right value
> >> (or just a "better" value) when running under Valgrind.
> >
> > I thought valgrind would discover if unintialized values are being used
> > though. Isn't that true?
>
> In general, yes. But the execution environment under Valgrind is different
> to that natively -- memory is laid out in different ways, etc. Very
> occasionally this changes program behaviour; but when it does it's usually
> because the program is buggy, eg. it's got a wild memory read/write that may
> hit addressible, initialised memory uner Valgrind but not natively. I
> imagine something like that is happening here. It's unfortunate for the
> poor user because Memcheck then can't detect the problem.
OK, if we include
#define _GNU_SOURCE /* ptsname_r() under Linux */
#include <sys/types.h>
we get the prototype
extern char *ptsname (int __fd) __attribute__ ((__nothrow__));
in the translation unit.
If we include
#include <sys/types.h>
#define _GNU_SOURCE /* ptsname_r() under Linux */
we do not get the prototype in the translation unit.
Then, we do this,
char *name;
if (!(name = ptsname(*masterfd)))
In the case where the prototype is defined, it works fine and there
is no crash. In the case where there is no prototype, we get this
error.
../../../../cgdb/various/util/src/pseudo.c:304: warning: assignment
makes pointer from integer without a cast
That's because it thinks ptsname returns an int, and assigns it to a
char*. This works when the sizeof(char*) == sizeof(int). However on this
64 amd machine, sizeof (char*)=8 sizeof (int)=4. This gives us the
crash.
Now, I'm wondering why valgrind reports no error on this circumstance.
Would this be an improvement to memcheck? It took us quite some time to
figure out the problem.
Thanks,
Bob Rossi
|
|
From: Eric L. <ew...@an...> - 2006-06-05 18:56:31
|
Thanks for all the useful advice! Really appreciate it. I hope it's not asking too much but i have a few more questions. I'm gonna pass my own instrumentation function into LibVEX_Translate to obtain a handle to the IR. I actually want to be able to pass in an entire binary, and get back the IRBB's, but VEX, as far as i can see, only translates each BB to IR. Is there a module that parses binaries to BB's that I can use? I'm guessing there's something built into coregrind that does that but can I use it without the rest of coregrind, i.e. call it directly somehow? Thanks again! Eric > On Saturday 03 June 2006 07:33, Nicholas Nethercote wrote: >> On Sat, 3 Jun 2006, Eric Li wrote: >>> But what I want is to use VEX as a library to generate IR and then >>> use that IR in my own project. Initially, I thought VEX did just that >>> and handed the IR over to the tools for further processing, but now >>> it's clear to me that it only lets you define the instrumentation >>> functions. >> >> "Defining the instrumentation functions" is exactly equivalent to >> "handing over the IR for further processing". The instrumentation >> function is given each BB's IR and can then do anything it wants to it >> (although if the end result isn't functionally equivalent the program's >> behaviour will be changed). > > One question is: do you really want to ship bits of IR off outside the > Valgrind framework? Usually people want to mess with the IR and then run > the results, which is precisely what the whole framework (Valgrind) exists > for. It provides loads of useful infrastructure. I guess you could send > the IR to an external tool for some kind of offline analysis, but once > outside the Valgrind infrastructure it will be difficult to run the > results. > >>> Would it be a fairly involved endeavor to take apart VEX and extract >>> just the parts that generate the IR? >> >> AIUI that's really all Vex does. It has a couple of minor >> Valgrind-specific hooks, but it should be usable standalone. > > Yes, it's very self-contained. VEX/test_main.c uses the main function > (LibVEX_Translate) to deal with single BBs. VEX/switchback/switchback.c, > despite being somewhat broken, is a simple dynamic-translation based > program-runner based around Vex, in one file. (Both of these are for > testing/debugging it.) > > J > > |
|
From: Nicholas N. <nj...@cs...> - 2006-06-04 22:26:11
|
On Sun, 4 Jun 2006, Bob Rossi wrote: >> Before the experts answer you, it sounds to me like maybe you're passing >> around some un-initialized value which happens to have the right value >> (or just a "better" value) when running under Valgrind. > > I thought valgrind would discover if unintialized values are being used > though. Isn't that true? In general, yes. But the execution environment under Valgrind is different to that natively -- memory is laid out in different ways, etc. Very occasionally this changes program behaviour; but when it does it's usually because the program is buggy, eg. it's got a wild memory read/write that may hit addressible, initialised memory uner Valgrind but not natively. I imagine something like that is happening here. It's unfortunate for the poor user because Memcheck then can't detect the problem. I heard of one person who chose to always run a program under Valgrind because it crashed natively but not under Valgrind! (I think Memcheck must have issued warnings, but maybe he didn't care and just used --tool=none.) Nick |
|
From: Nicholas N. <nj...@cs...> - 2006-06-04 22:11:13
|
On Sun, 4 Jun 2006, Dmitry Baryshkov wrote: >>> Tell me please, if I wish to get and examine syscall attributes from >>> the valgrind tool, how should I do that? >> >> What do you mean by "attributes" exactly? > > I'm sorry, I meant arguments. If you just want to see them, you can use the standard Unix 'strace' utility. Or if you run programs under Valgrind with the --trace-syscalls=yes you get a similar, but less pretty, result. If you want to do something more involved, you can wrap system calls from a Valgrind tool. You need to register pre-syscall and post-syscall handler functions with VG_(need_syscall_wrappers)(); see include/pub_tool_tooliface.h. However, those aren't great, because they only get passed the syscall number. You then have to extract the arguments manually from the registers or wherever, and the location of the arguments varies across platforms, and its not even consistent within platforms. This is possible but tedious; Valgrind does it internally for determing which registers and To see how to do it, look at the PRE() and POST() macros in coregrind/m_syswrap/syswrap-*.c. Actually, a tool can also use VG_(track_pre_reg_read)() and VG_(track_pre_mem_read)() to register handlers that get told when registers and memory are read (in some circumstances). When the "CorePart" argument to these handlers is equal to Vg_CoreSysCall, you'll know the register/memory is being read because it's a system call argument. This might be helpful, although it again doesn't tell you directly the arguments. Nick |
|
From: Tom H. <to...@co...> - 2006-06-04 17:19:22
|
In message <bc6...@ma...>
"Dmitry Baryshkov" <dba...@gm...> wrote:
> 2006/6/4, Tom Hughes <to...@co...>:
>
> > In message <bc6...@ma...>
> > "Dmitry Baryshkov" <dba...@gm...> wrote:
> >
> > > Tell me please, if I wish to get and examine syscall attributes from
> > > the valgrind tool, how should I do that?
> >
> > What do you mean by "attributes" exactly?
>
> I'm sorry, I meant arguments.
So you're writing a tool and you want it to be able to spot system calls
and examine the arguments?
I don't think there is a simple way of doing that - there isn't any tool
function that is called by the core when a system call is taken as far
as I know.
I think you would have to instrument the code which probably also means
knowing which registers the system call arguments will be in for each
of the supported platforms.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Bob R. <bob...@co...> - 2006-06-04 17:15:57
|
On Sun, Jun 04, 2006 at 07:56:27AM +0300, Yeshurun, Meir wrote: > > Before the experts answer you, it sounds to me like maybe you're passing > around some un-initialized value which happens to have the right value > (or just a "better" value) when running under Valgrind. I thought valgrind would discover if unintialized values are being used though. Isn't that true? Bob Rossi |
|
From: Dmitry B. <dba...@gm...> - 2006-06-04 15:21:50
|
Hello, 2006/6/4, Tom Hughes <to...@co...>: > In message <bc6...@ma...> > "Dmitry Baryshkov" <dba...@gm...> wrote: > > > Tell me please, if I wish to get and examine syscall attributes from > > the valgrind tool, how should I do that? > > What do you mean by "attributes" exactly? I'm sorry, I meant arguments. -- With best wishes Dmitry Baryshkov |
|
From: Tom H. <to...@co...> - 2006-06-04 14:50:15
|
In message <bc6...@ma...>
"Dmitry Baryshkov" <dba...@gm...> wrote:
> Tell me please, if I wish to get and examine syscall attributes from
> the valgrind tool, how should I do that?
What do you mean by "attributes" exactly?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dmitry B. <dba...@gm...> - 2006-06-04 14:46:51
|
Hello, Tell me please, if I wish to get and examine syscall attributes from the valgrind tool, how should I do that? -- With best wishes Dmitry Baryshkov |
|
From: Mike M. <mi...@su...> - 2006-06-04 08:49:12
|
Meir, that's what I thought at first, too. What's interesting though, is the function ptsname() is supposed to return a pointer to a statically allocated buffer, or NULL on failure. It's hard for me to imagine a possible case where that function would return a bad pointer. I even opened up the code for glibc-2.3.5 to see how it's implemented and it's a simple one liner (call to ptsname_r). Thanks, Mike On 6/4/06, Yeshurun, Meir <mei...@in...> wrote: > > Before the experts answer you, it sounds to me like maybe you're passing > around some un-initialized value which happens to have the right value > (or just a "better" value) when running under Valgrind. > > Thanks, > Meir > > -----Original Message----- > From: val...@li... > [mailto:val...@li...] On Behalf Of Mike > Mueller > Sent: Sunday, June 04, 2006 6:29 AM > To: val...@li... > Cc: Bob Rossi > Subject: [Valgrind-users] Segfault not caught by valgrind > > I have a weird situation. I'll try to describe it as completely as > possible: > > I have a program that does not crash, and when run through valgrind, 0 > errors are reported. Someone else patched it to get it to recompile > on FreeBSD by moving a single include (sys/types.h) from the bottom to > the top of the includes list. Now the program segfaults on my AMD64 > computer (but not on any other computers, as far as I can tell, > including x86, ppc). > > Now, I debug it in gdb and I find the line where it's crashing. It's > a call to ptsname that's returning garbage instead of a valid pointer > to a string (or NULL, the failure case). Can't figure out why ptsname > is returning garbage unless there's a weird memory corruption or the > system library is buggy on amd64. > > However, when I run the program through valgrind (using the memcheck > tool), it does NOT crash and valgrind reports 0 errors. > > One last bit, if I call ptsname_r instead of ptsname, there is no > segfault. > > Have you ever seen anything like this? > > Thanks! > Mike > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Yeshurun, M. <mei...@in...> - 2006-06-04 04:56:41
|
Before the experts answer you, it sounds to me like maybe you're passing around some un-initialized value which happens to have the right value (or just a "better" value) when running under Valgrind. Thanks, Meir -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Mike Mueller Sent: Sunday, June 04, 2006 6:29 AM To: val...@li... Cc: Bob Rossi Subject: [Valgrind-users] Segfault not caught by valgrind I have a weird situation. I'll try to describe it as completely as possible: I have a program that does not crash, and when run through valgrind, 0 errors are reported. Someone else patched it to get it to recompile on FreeBSD by moving a single include (sys/types.h) from the bottom to the top of the includes list. Now the program segfaults on my AMD64 computer (but not on any other computers, as far as I can tell, including x86, ppc). Now, I debug it in gdb and I find the line where it's crashing. It's a call to ptsname that's returning garbage instead of a valid pointer to a string (or NULL, the failure case). Can't figure out why ptsname is returning garbage unless there's a weird memory corruption or the system library is buggy on amd64. However, when I run the program through valgrind (using the memcheck tool), it does NOT crash and valgrind reports 0 errors. One last bit, if I call ptsname_r instead of ptsname, there is no segfault. Have you ever seen anything like this? Thanks! Mike _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Mike M. <mi...@su...> - 2006-06-04 03:28:51
|
I have a weird situation. I'll try to describe it as completely as possible: I have a program that does not crash, and when run through valgrind, 0 errors are reported. Someone else patched it to get it to recompile on FreeBSD by moving a single include (sys/types.h) from the bottom to the top of the includes list. Now the program segfaults on my AMD64 computer (but not on any other computers, as far as I can tell, including x86, ppc). Now, I debug it in gdb and I find the line where it's crashing. It's a call to ptsname that's returning garbage instead of a valid pointer to a string (or NULL, the failure case). Can't figure out why ptsname is returning garbage unless there's a weird memory corruption or the system library is buggy on amd64. However, when I run the program through valgrind (using the memcheck tool), it does NOT crash and valgrind reports 0 errors. One last bit, if I call ptsname_r instead of ptsname, there is no segfault. Have you ever seen anything like this? Thanks! Mike |
|
From: wwp <sub...@fr...> - 2006-06-03 12:46:58
|
Hello Michael, On Sat, 3 Jun 2006 14:36:08 +0200 "Michael Smith" <ms...@xi...> wrote: > On 6/3/06, wwp <sub...@fr...> wrote: >=20 > > Well, it seems to work! At least it doesn't get Killed at startup ;-). > > Thanks a ton! > > > > Is there any link I could follow to know why 3.1.x don't work with my > > kernel (to feed a thread on fedora users mailing-list, for the archives= )? >=20 > See the thread starting here: > http://sourceforge.net/mailarchive/message.php?msg_id=3D14946071 I could also see (NEWS file helps) that it was bug 117290. I'll unsubscribe now, thanks to all. Regards, --=20 wwp |
|
From: Julian S. <js...@ac...> - 2006-06-03 12:46:51
|
On Saturday 03 June 2006 13:36, Michael Smith wrote: > On 6/3/06, wwp <sub...@fr...> wrote: > > Well, it seems to work! At least it doesn't get Killed at startup ;-). > > Thanks a ton! > > > > Is there any link I could follow to know why 3.1.x don't work with my > > kernel (to feed a thread on fedora users mailing-list, for the archives)? > > See the thread starting here: > http://sourceforge.net/mailarchive/message.php?msg_id=14946071 We tracked this bug as #117290. http://bugs.kde.org/117290 should make the problem clear. J |
|
From: Michael S. <ms...@xi...> - 2006-06-03 12:36:18
|
On 6/3/06, wwp <sub...@fr...> wrote: > Well, it seems to work! At least it doesn't get Killed at startup ;-). Thanks > a ton! > > Is there any link I could follow to know why 3.1.x don't work with my kernel > (to feed a thread on fedora users mailing-list, for the archives)? See the thread starting here: http://sourceforge.net/mailarchive/message.php?msg_id=14946071 Mike |
|
From: wwp <sub...@fr...> - 2006-06-03 12:30:58
|
Hello Julian,
On Sat, 3 Jun 2006 13:03:04 +0100 Julian Seward <js...@ac...> wrote:
>=20
> > execve("/usr/lib/valgrind/x86-linux/memcheck", ["valgrind", "--help"], =
[/*
> > 41 vars */]) =3D 0 +++ killed by SIGKILL +++
>=20
> I believe this will be fixed in 3.2.0. Try the release candidate and
> see if it works:
>=20
> http://www.valgrind.org/downloads/valgrind-3.2.0rc1.tar.bz2
> (MD5 =3D 200bdc9bfb3a6b4f74c797b12a91a402)
Well, it seems to work! At least it doesn't get Killed at startup ;-). Than=
ks
a ton!
Is there any link I could follow to know why 3.1.x don't work with my kernel
(to feed a thread on fedora users mailing-list, for the archives)?
Regards,
--=20
wwp
|
|
From: Julian S. <js...@ac...> - 2006-06-03 12:03:24
|
> execve("/usr/lib/valgrind/x86-linux/memcheck", ["valgrind", "--help"], [/*
> 41 vars */]) = 0 +++ killed by SIGKILL +++
I believe this will be fixed in 3.2.0. Try the release candidate and
see if it works:
http://www.valgrind.org/downloads/valgrind-3.2.0rc1.tar.bz2
(MD5 = 200bdc9bfb3a6b4f74c797b12a91a402)
J
|
|
From: Julian S. <js...@ac...> - 2006-06-03 11:46:44
|
On Saturday 03 June 2006 07:33, Nicholas Nethercote wrote: > On Sat, 3 Jun 2006, Eric Li wrote: > > But what I want is to use VEX as a library to generate IR and then use > > that IR in my own project. Initially, I thought VEX did just that and > > handed the IR over to the tools for further processing, but now it's > > clear to me that it only lets you define the instrumentation functions. > > "Defining the instrumentation functions" is exactly equivalent to "handing > over the IR for further processing". The instrumentation function is given > each BB's IR and can then do anything it wants to it (although if the end > result isn't functionally equivalent the program's behaviour will be > changed). One question is: do you really want to ship bits of IR off outside the Valgrind framework? Usually people want to mess with the IR and then run the results, which is precisely what the whole framework (Valgrind) exists for. It provides loads of useful infrastructure. I guess you could send the IR to an external tool for some kind of offline analysis, but once outside the Valgrind infrastructure it will be difficult to run the results. > > Would it be a fairly involved endeavor to take apart VEX and extract just > > the parts that generate the IR? > > AIUI that's really all Vex does. It has a couple of minor > Valgrind-specific hooks, but it should be usable standalone. Yes, it's very self-contained. VEX/test_main.c uses the main function (LibVEX_Translate) to deal with single BBs. VEX/switchback/switchback.c, despite being somewhat broken, is a simple dynamic-translation based program-runner based around Vex, in one file. (Both of these are for testing/debugging it.) J |
|
From: wwp <sub...@fr...> - 2006-06-03 09:05:21
|
Hi there,
I'm running valgrind on a Fedora Core 5 box, no problem w/ 3.1.1 from the
sources or the FC5 valgrind-3.1.0-2 package, if only use the Fedora kernels. I
recently set up a custom kernel, which config is stripped down from the
2.6.16-1.2122_FC5's one (get rid of tons of unnecessary stuff, best fit my
hardware).
Unfortunately, when I use this custom kernel, running valgrind is impossible
(whatever command-line I try), I get:
$ valgrind --help
Killed
With root or non-root, still the same. I tried using strace, but can get any
clue from the output:
$ strace valgrind --help
execve("/usr/bin/valgrind", ["valgrind", "--help"], [/* 40 vars */]) = 0
brk(0) = 0x9bd7000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa7f76000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/tls/i686/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/tls/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/i686/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=121122, ...}) = 0
mmap2(NULL, 121122, PROT_READ, MAP_PRIVATE, 4, 0) = 0xa7f58000
close(4) = 0
open("/lib/libc.so.6", O_RDONLY) = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0J\330c\000"..., 512) = 512
fstat64(4, {st_mode=S_IFREG|0755, st_size=1532536, ...}) = 0
mmap2(0x628000, 1254780, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x628000
mmap2(0x755000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x12d) = 0x755000
mmap2(0x758000, 9596, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x758000
close(4) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa7f57000
set_thread_area({entry_number:-1 -> 6, base_addr:0xa7f576c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x755000, 8192, PROT_READ) = 0
mprotect(0x624000, 4096, PROT_READ) = 0
munmap(0xa7f58000, 121122) = 0
readlink("/proc/self/exe", "/usr/bin/valgrind", 4096) = 17
brk(0) = 0x9bd7000
brk(0x9bf8000) = 0x9bf8000
execve("/usr/lib/valgrind/x86-linux/memcheck", ["valgrind", "--help"], [/* 41 vars */]) = 0
+++ killed by SIGKILL +++
Process 21593 detached
Are there any kernel setting that might explain this problem? (I've attached
my kernel config)
Regards,
--
wwp
|
|
From: Nicholas N. <nj...@cs...> - 2006-06-03 06:44:59
|
On Sat, 3 Jun 2006, Eric Li wrote: > But what I want is to use VEX as a library to generate IR and then use > that IR in my own project. Initially, I thought VEX did just that and > handed the IR over to the tools for further processing, but now it's clear > to me that it only lets you define the instrumentation functions. "Defining the instrumentation functions" is exactly equivalent to "handing over the IR for further processing". The instrumentation function is given each BB's IR and can then do anything it wants to it (although if the end result isn't functionally equivalent the program's behaviour will be changed). > Would it be a fairly involved endeavor to take apart VEX and extract just > the parts that generate the IR? AIUI that's really all Vex does. It has a couple of minor Valgrind-specific hooks, but it should be usable standalone. Nick |
|
From: Eric L. <ew...@an...> - 2006-06-03 05:02:28
|
>> I've looked into VEX's exported interface and I only see >> LibVEX_Translate which does all the steps (bb to ir, optimize, >> instrument, etc.) of translating from the guest bytes to the host bytes >> but I only want the IR that it spits out in the middle, > > That much at least is easy enough. It hands the optimised, > uninstrumented IR to the tool's primary instrumentation function; you can > print it out or whatever at that point. > >> preferably wrapped in some kinda nice clean data structure. > > Personally I think the IR types are about as clean as you're going to get. > I've found them pleasant to work with over the past couple of years. Yea you're right, the IR data structures are easy enough to understand and use after I looked into them some more. But what I want is to use VEX as a library to generate IR and then use that IR in my own project. Initially, I thought VEX did just that and handed the IR over to the tools for further processing, but now it's clear to me that it only lets you define the instrumentation functions. Would it be a fairly involved endeavor to take apart VEX and extract just the parts that generate the IR? e.g. make calls to bb_to_IR? I mean does VEX have sub modules that would make that easier? or would I have to first understand the whole thing, then change and recompile it? Thanks, Eric > > J > > |
|
From: Behdad E. <be...@cs...> - 2006-06-03 01:56:50
|
On Fri, 2 Jun 2006, Nicholas Nethercote wrote: > On Fri, 2 Jun 2006, Behdad Esfahbod wrote: > > >> Behdad, I can think of three possible ways of incorporating valgrind.h: > >> > >> 1. copying it directly into a C file (clearly silly) > >> 2. making a local copy in your project and #include'ing that > >> 3. #include'ing the installed copy from $INSTALL/include > >> > >> Number 3 is the intended method. Are you doing number 2? It's not clear to > >> me because if you do number 3 I don't see why you should have problems with > >> version mismatches between valgrind.h and the Valgrind program. > > > > Ah, ok. Yes, I was doing number 2, and the gslice maintainer had > > my same reading of "for inclusion into client (your!) code". > > It turns out the manual recommends #2. Hmm. And #2 is a lot easier maintenance-wise, fewer dependencies on client package, even if it's a soft dependency. > > BTW, I'm willing to work on a patch to make MALLOCLIKE inside > > malloc'ed block work, should you tell me what kind of approach > > you prefer. > > My IGNORE_HEAP_BLOCK approach is flawed because it didn't handle freeing of > the superblock. One way is to add a FAKE_MALLOC(mem) that should be called right before the free() call to create a block entry (with zero length). > You mentioned having a valgrind.h versioning system to avoid the problem of > a Valgrind possibly having MALLOCLIKE/FREELIKE but not IGNORE_*. Better I > think would be another request SUPPORTS_IGNORE_REQUESTS. You could query > that first. Version numbers are a pain, because they're arbitrary, and it's > easy to forget to update them. (We've found that with the internal > core/tool versioning system we have.) The problem with a SUPPORTS_IGNORE_REQUESTS is that the approach doesn't scale well. The version number on the other hand works pretty well, assuming that valgrind doesn't break backwards compatibility. Then one can simply for the minimum version they require, instead of asking for a new SUPPORTS_* hint to be added to the next version. As for updating them, I'm not suggesting a new interface version, just the valgrind version, and that's handled automatically by the build system. > Nick --behdad http://behdad.org/ "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill" -- Dan Bern, "New American Language" |
|
From: Nicholas N. <nj...@cs...> - 2006-06-03 01:04:25
|
On Fri, 2 Jun 2006, Behdad Esfahbod wrote: >> Behdad, I can think of three possible ways of incorporating valgrind.h: >> >> 1. copying it directly into a C file (clearly silly) >> 2. making a local copy in your project and #include'ing that >> 3. #include'ing the installed copy from $INSTALL/include >> >> Number 3 is the intended method. Are you doing number 2? It's not clear to >> me because if you do number 3 I don't see why you should have problems with >> version mismatches between valgrind.h and the Valgrind program. > > Ah, ok. Yes, I was doing number 2, and the gslice maintainer had > my same reading of "for inclusion into client (your!) code". It turns out the manual recommends #2. Hmm. > BTW, I'm willing to work on a patch to make MALLOCLIKE inside > malloc'ed block work, should you tell me what kind of approach > you prefer. My IGNORE_HEAP_BLOCK approach is flawed because it didn't handle freeing of the superblock. One possibility would be to introduce IGNORE_NEXT_MALLOC and IGNORE_NEXT_FREE requests, which would do the obvious thing. They're simple (no arguments!) which is good, but they're stateful, which is not so nice. You mentioned having a valgrind.h versioning system to avoid the problem of a Valgrind possibly having MALLOCLIKE/FREELIKE but not IGNORE_*. Better I think would be another request SUPPORTS_IGNORE_REQUESTS. You could query that first. Version numbers are a pain, because they're arbitrary, and it's easy to forget to update them. (We've found that with the internal core/tool versioning system we have.) Nick |