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
(4) |
3
(5) |
4
(2) |
|
5
(1) |
6
(3) |
7
(4) |
8
(4) |
9
(7) |
10
(2) |
11
(3) |
|
12
(4) |
13
(4) |
14
(8) |
15
(5) |
16
(13) |
17
(12) |
18
(2) |
|
19
(1) |
20
(12) |
21
(4) |
22
(13) |
23
(1) |
24
(1) |
25
|
|
26
|
27
(4) |
28
(3) |
29
(8) |
30
(6) |
|
|
|
From: Paul F. <pa...@fr...> - 2006-11-15 17:37:58
|
Hi
(I don't have access to the latest code, so I can't tell if it's been fix=
ed).
I just spotted the following:
m_main.c
case OverlapSupp:
return (ekind =3D OverlapErr);
I was scratching my head wondering why my Overlap suppressions were not w=
orking!
A+
Paul
|
|
From: Alex B. <ker...@be...> - 2006-11-15 16:11:27
|
Hi,
I have a program that seems to be behaving differently in valgrind
(latest SVN code) to being run normally. My program has a signal handler
which to handle integer overflow conditions. The code looks roughly
like:
void arithmeticSigHandler(int sigNum, siginfo_t *siginfo, void *stuff)
{
ucontext_t *uctx = (ucontext_t *)stuff;
mcontext_t *ctx = (mcontext_t *)&(uctx->uc_mcontext);
//
// Read the faulting instruction so we can check if the fault was
// a signed or unsigned divide.
//
unsigned char instOpcode = *((char*)ctx->gregs[REG_RIP]);
unsigned char instModRM = *((char*)(ctx->gregs[REG_RIP]+1));
fp fprintf(stderr,"rip 0x%lx: instOpcode = 0x%x, ModRM = 0x%x\n",
ctx->gregs[REG_RIP], instOpcode, instModRM);
if(instOpcode == 0xF7) // check its a divide
{
However under valgrind it fails the check and falls through to some
debug code for bad SIGFPE's. The run with the fprintf give the following
output:
Test 5
rip 0x702277f2: instOpcode = 0x8b, ModRM = 0x55
==15666==
==15666== Uninitialised byte(s) found during client check request
But attaching to gdb at the point it gets confused:
...
#15 0x00000000702dbb9f in arithmeticSigHandler (sigNum=8,
siginfo=0x2a960108c8, stuff=0x2a96010798)
#16 <signal handler called>
#17 0x00000000702277f5 in subjectInterpreter_sdiv ()
(gdb) frame 17
#17 0x00000000702277f5 in subjectInterpreter_sdiv ()
(gdb) x/1i $pc
0x702277f5 <subjectInterpreter_sdiv>: idiv %ebx
(gdb) x/5b $pc
0x702277f5 <subjectInterpreter_sdiv>: 0xf7 0xfb 0x89 0x45
0xf0
It looks like the pc the valgrind supplies is a few bytes off what the
core would indicate (and what would happen in real life).
(gdb) x/5b 0x702277f2
0x702277f2: 0x8b 0x55 0xe8 0xf7 0xfb
Any ideas what could be causing that?
I'm running valgrind with the following options:
/usr/local/bin/valgrind --leak-check=full
--vex-iropt-precise-memory-exns --smc-check=all --db-attach=yes
--db-command="/usr/local/bin/gdb -nw %f %p"
For completeness running outside of valgrind I get:
Test 5
rip 0x702277f5: instOpcode = 0xf7, ModRM = 0xfb
Which behaves as expected.
--
Alex, homepage: http://www.bennee.com/~alex/
Think big. Pollute the Mississippi.
|
|
From: Lou Sanchez-C. <lou...@xi...> - 2006-11-14 19:33:53
|
Hi,
Cerion Armour-Brown wrote:
>On Tuesday 14 November 2006 09:27, Pim Nijdam wrote:
>
>
>>Cerion Armour-Brown wrote:
>>
>>
>>>I assume you need to run under multiple versions of valgrind, else
>>>setting it once in the options dlg and saving the options would surely
>>>do?
>>>
>>>
>>You could make a script that sets the option in ~/.valkyrie/valkyrierc
>>before running Valkyrie. Of course if you've multiple different setting
>>(e.g. different suppression files as well) you might consider having
>>multiple configuration files and let your script do something like:copy
>>configuration_x to valkyrierc, run valkyrie, copy valkyrierc back to
>>configuration_x.
>>
>>
>
>Hmm.
>I agree the config file situation is less than adequate - we need to move to
>per-project config files a-la kdevelop, as opposed to one master config file.
>Anyone got any spare time?!
>
>
I ended up manually editing (despite the warning) the valkyrierc
file. Rather than having a multitude of valkyrierc files I would prefer
that command line options be able to supercede what's in the config
file. That way they can be used in scripts, specialized icons, etc.. I
might take that on after I finish the current project (suppression editor).
>C
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys - and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Valgrind-users mailing list
>Val...@li...
>https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
Cheers
Lou
|
|
From: Cerion Armour-B. <ce...@va...> - 2006-11-14 18:59:52
|
On Tuesday 14 November 2006 09:27, Pim Nijdam wrote: > Cerion Armour-Brown wrote: > > I assume you need to run under multiple versions of valgrind, else > > setting it once in the options dlg and saving the options would surely > > do? > > You could make a script that sets the option in ~/.valkyrie/valkyrierc > before running Valkyrie. Of course if you've multiple different setting > (e.g. different suppression files as well) you might consider having > multiple configuration files and let your script do something like:copy > configuration_x to valkyrierc, run valkyrie, copy valkyrierc back to > configuration_x. Hmm. I agree the config file situation is less than adequate - we need to move to per-project config files a-la kdevelop, as opposed to one master config file. Anyone got any spare time?! C |
|
From: Julian S. <js...@ac...> - 2006-11-14 15:48:34
|
> How do I know the address of the next instruction that would have executed > had the store not been inserted? Look at the IRStmt.IMark for the current instruction. That gives you the address and size of the current instruction, so add them. > Will the insertion of the store affect its value? Affect the value of what? > ps:The IRStmt_Exit has an IRExpr guard as its input. I assume the jump will > happen if it is >0. Is that right? Yes. In fact the guard is forced to have type Ity_I1 (a 1-bit integer) so the only possible values are 0 and 1. J |
|
From: Mohit T. <moh...@gm...> - 2006-11-14 13:49:10
|
> > > There is no direct way to do that in IR, since it isn't necessary for > the supported architectures (x86/amd64/ppc32/ppc64) and it seriously > complicates IR optimisation and backend code generation. > > However you can probably achieve what you want like this > > nc = compute negated condition; > IRStmt_Exit( nc, next_insn_address ) > IRStmt_Store > end of this IR block > > so the instruction after the conditional store is starts a new IR block. > > J How do I know the address of the next instruction that would have executed had the store not been inserted? Will the insertion of the store affect its value? ps:The IRStmt_Exit has an IRExpr guard as its input. I assume the jump will happen if it is >0. Is that right? Mohit ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Julian S. <js...@ac...> - 2006-11-14 11:46:07
|
On Tuesday 14 November 2006 09:56, Mohit Tiwari wrote:
> Hi,
>
> I wonder if there is a way to insert the equivalent of "if (tmp>100) {
> store(data,addr); }" into the client binary, without doing a CCALL. A way
> of
>
> maybe inserting the equivalent of following IRStmts:
> 1. Compute_condition;
> 2. JZERO address_offset; store(data,addr) --->
> 3. Store(data, addr) |
> 4. Proceed as usual <--- |
>
> I checked the older UInstrns, and they had a Jzero and Inceip instructions
> that would have been useful...but the IR doesn't seem to have it.
There is no direct way to do that in IR, since it isn't necessary for
the supported architectures (x86/amd64/ppc32/ppc64) and it seriously
complicates IR optimisation and backend code generation.
However you can probably achieve what you want like this
nc = compute negated condition;
IRStmt_Exit( nc, next_insn_address )
IRStmt_Store
end of this IR block
so the instruction after the conditional store is starts a new IR block.
J
|
|
From: Mohit T. <moh...@gm...> - 2006-11-14 09:56:47
|
Hi,
I wonder if there is a way to insert the equivalent of "if (tmp>100) {
store(data,addr); }" into the client binary, without doing a CCALL. A way of
maybe inserting the equivalent of following IRStmts:
1. Compute_condition;
2. JZERO address_offset; store(data,addr) --->
3. Store(data, addr) |
4. Proceed as usual <--- |
I checked the older UInstrns, and they had a Jzero and Inceip instructions
that would have been useful...but the IR doesn't seem to have it.
Thanks,
Mohit
|
|
From: Pim N. <pn...@ai...> - 2006-11-14 08:28:02
|
Cerion Armour-Brown wrote: > I assume you need to run under multiple versions of valgrind, else setting it > once in the options dlg and saving the options would surely do? You could make a script that sets the option in ~/.valkyrie/valkyrierc before running Valkyrie. Of course if you've multiple different setting (e.g. different suppression files as well) you might consider having multiple configuration files and let your script do something like:copy configuration_x to valkyrierc, run valkyrie, copy valkyrierc back to configuration_x. Pim -- This message has been scanned for viruses and is believed to be clean |
|
From: Cerion Armour-B. <ce...@op...> - 2006-11-13 22:01:57
|
I assume you need to run under multiple versions of valgrind, else setting it once in the options dlg and saving the options would surely do? Cerion On Friday 10 November 2006 08:49, Lou Sanchez/Viviana Bellifemine wrote: > Hi, > I've looked in the documentation and could not find a way to change > on the command line to Valkyrie the location of the Valgrind executable > to run. I can do it from the Options dialog, but it's kind of klunky > since you have to stop the running investigated application and then > restart it. Does anyone have a better solution? Thanks. > > Cheers > > Lou > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Olly B. <ol...@su...> - 2006-11-13 15:08:19
|
On 2006-11-13, Mattias Ståhlberg XX <mat...@er...> wrote:
> I'm trying to understand how to use the option --error-exitcode to make
> my testcases started from make stop when a memory leak is found.
I don't think leaks count as errors (at least not for these purposes).
Your best option might be to add this just before the test case exits:
if (RUNNING_ON_VALGRIND) {
VALGRIND_DO_LEAK_CHECK;
long vg_leaks = 0, vg_dubious = 0, vg_reachable = 0, dummy;
VALGRIND_COUNT_LEAKS(vg_leaks, vg_dubious, vg_reachable, dummy);
if (vg_leaks || vg_dubious || vg_reachable) exit(1);
}
You only want to test vg_dubious if you ever hold on to allocated blocks
only by a pointer which isn't to the start. Otherwise it just increases
the small chance that a garbage value will accidentally act as a
reference to a leaked block and hide a leak.
Cheers,
Olly
|
|
From:
<mat...@er...> - 2006-11-13 13:26:02
|
Hello Valgrind-Users, I'm trying to understand how to use the option --error-exitcode to make my testcases started from make stop when a memory leak is found. I have a test program written in C that leaks two portions of memory. I run it through valgrind with --error-exitcode=3D1. Valgrind reports the memory leaks, but the exit code is still zero. Am I doing something = wrong or did I misinterpret the meaning of --error-exitcode? I'm using valgrind 3.2.1 on a 64 bit machine running SUSE Linux = Enterprise Server 10. The output from valgrind (and my test program) is found below. Thanks and best regards, Mattias St=E5hlberg c-template/tests> valgrind --error-exitcode=3D1 ./check_hello =3D=3D3973=3D=3D Memcheck, a memory error detector. =3D=3D3973=3D=3D Copyright (C) 2002-2006, and GNU GPL'd, by Julian = Seward et al. =3D=3D3973=3D=3D Using LibVEX rev 1658, a library for dynamic binary = translation. =3D=3D3973=3D=3D Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks = LLP. =3D=3D3973=3D=3D Using valgrind-3.2.1, a dynamic binary instrumentation = framework. =3D=3D3973=3D=3D Copyright (C) 2000-2006, and GNU GPL'd, by Julian = Seward et al. =3D=3D3973=3D=3D For more details, rerun with: -v =3D=3D3973=3D=3D Running suite(s): Hello =3D=3D3974=3D=3D =3D=3D3974=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 = from 1) =3D=3D3974=3D=3D malloc/free: in use at exit: 16,720 bytes in 28 blocks. =3D=3D3974=3D=3D malloc/free: 34 allocs, 6 frees, 16,798 bytes = allocated. =3D=3D3974=3D=3D For counts of detected errors, rerun with: -v =3D=3D3974=3D=3D searching for pointers to 28 not-freed blocks. =3D=3D3974=3D=3D checked 58,280 bytes. =3D=3D3974=3D=3D =3D=3D3974=3D=3D LEAK SUMMARY: =3D=3D3974=3D=3D definitely lost: 16,016 bytes in 2 blocks. =3D=3D3974=3D=3D possibly lost: 0 bytes in 0 blocks. =3D=3D3974=3D=3D still reachable: 704 bytes in 26 blocks. =3D=3D3974=3D=3D suppressed: 0 bytes in 0 blocks. =3D=3D3974=3D=3D Use --leak-check=3Dfull to see details of leaked = memory. =3D=3D3975=3D=3D =3D=3D3975=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 = from 1) =3D=3D3975=3D=3D malloc/free: in use at exit: 757 bytes in 29 blocks. =3D=3D3975=3D=3D malloc/free: 48 allocs, 19 frees, 1,743 bytes = allocated. =3D=3D3975=3D=3D For counts of detected errors, rerun with: -v =3D=3D3975=3D=3D searching for pointers to 29 not-freed blocks. =3D=3D3975=3D=3D checked 58,340 bytes. =3D=3D3975=3D=3D =3D=3D3975=3D=3D LEAK SUMMARY: =3D=3D3975=3D=3D definitely lost: 0 bytes in 0 blocks. =3D=3D3975=3D=3D possibly lost: 0 bytes in 0 blocks. =3D=3D3975=3D=3D still reachable: 757 bytes in 29 blocks. =3D=3D3975=3D=3D suppressed: 0 bytes in 0 blocks. =3D=3D3975=3D=3D Reachable blocks (those to which a pointer was found) = are not shown. =3D=3D3975=3D=3D To see them, rerun with: --show-reachable=3Dyes 100%: Checks: 2, Failures: 0, Errors: 0 =3D=3D3973=3D=3D =3D=3D3973=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 = from 1) =3D=3D3973=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks. =3D=3D3973=3D=3D malloc/free: 60 allocs, 60 frees, 2,504 bytes = allocated. =3D=3D3973=3D=3D For counts of detected errors, rerun with: -v =3D=3D3973=3D=3D All heap blocks were freed -- no leaks are possible. c-template/tests> echo $? 0 c-template/tests> |
|
From: Tom H. <to...@co...> - 2006-11-12 23:46:55
|
In message <455...@hp...>
Francois-Xavier KOWALSKI <fra...@hp...> wrote:
> www.valgrind.org seems to be down. I tried to locate a bug-tracker on
> SourceForge -- as this ML is hosted on SourceForge -- but there does not
> seem to be any bugtracker for valgrind. Any direct URL to the bug-tracker?
http://bugs.kde.org/enter_valgrind_bug.cgi
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-11-12 23:44:50
|
> > Lovely... That's a jcxz instruction (jecxz with an address size
> > override prefix so it only considers sixteen bits of the register
> > instead of all thirty two).
> >
> > There is no code to spot address size override prefixed in valgrind
> > at the moment, so that instruction will fail.
The amd64 front end has this
case 0x67: pfx |= PFX_ASO; break;
so it is handleable. I'll get to it.
> www.valgrind.org seems to be down.
Yes. I guess apache bombed or something.
> I tried to locate a bug-tracker on
> SourceForge -- as this ML is hosted on SourceForge -- but there does not
> seem to be any bugtracker for valgrind. Any direct URL to the bug-tracker?
We use the KDE bug tracker. Go to bugs.kde.org and file a bug for the
'valgrind' component.
J
|
|
From: Francois-Xavier K. <fra...@hp...> - 2006-11-12 23:29:21
|
Tom Hughes wrote: > In message <455...@hp...> > Francois-Xavier KOWALSKI <fra...@hp...> wrote: > > >> Anyone interested in this opcode? This is object code compiled with no >> optimization support (-O0) using ICC 9.1.044 (the latest Intel C/C++ >> compiler for Linux). Machine in a Pentium4 (Prescott) with HT. >> >> vex x86->IR: unhandled instruction bytes: 0x67 0xE3 0x67 0xF >> > > Lovely... That's a jcxz instruction (jecxz with an address size > override prefix so it only considers sixteen bits of the register > instead of all thirty two). > > There is no code to spot address size override prefixed in valgrind > at the moment, so that instruction will fail. > > Can you raise a bug on the bug tracker for this please. > www.valgrind.org seems to be down. I tried to locate a bug-tracker on SourceForge -- as this ML is hosted on SourceForge -- but there does not seem to be any bugtracker for valgrind. Any direct URL to the bug-tracker? TIA -- Francois-Xavier "FiX" KOWALSKI /_ __ Tel:+33 (0)4 76 14 63 27 OpenCall Business Unit -- OCBU / //_/ Fax:+33 (0)4 76 14 51 62 Media-Processing Engineering / http://www.hp.com/go/opencall i n v e n t |
|
From: Julian S. <js...@ac...> - 2006-11-11 03:16:55
|
- Presumably you didn't just run ./configure but then did make and then make install, yes? - You sure there is no previous installation it might be conflicting with? What happens when you do /path/to/PREFIX/bin/valgrind -v -d date J On Saturday 11 November 2006 03:08, Susan Margulies wrote: > Hello, everyone! I'm sorry to bother you, but I have seem to be having > an issue running valgrind. I ran ./configure --prefix=PATH and it > created a binary valgrind as it should have. It also created a > bin/lib/valgrind/amd64-linux where there are lots of binaries. > > Here is the error that I get when I run: > > valgrind --leak-check=yes gc_heur > > valgrind: failed to start tool 'memcheck' for platform 'amd64-linux': > No such file or directory > > Does anyone have any advice? I'm sure that this is something small and > simple that will be fixed instantly with the right command. :) > > Thank you for your time! I appreciate it! > > Best, > Susan > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Susan M. <sma...@uc...> - 2006-11-11 03:09:45
|
Hello, everyone! I'm sorry to bother you, but I have seem to be having an issue running valgrind. I ran ./configure --prefix=PATH and it created a binary valgrind as it should have. It also created a bin/lib/valgrind/amd64-linux where there are lots of binaries. Here is the error that I get when I run: valgrind --leak-check=yes gc_heur valgrind: failed to start tool 'memcheck' for platform 'amd64-linux': No such file or directory Does anyone have any advice? I'm sure that this is something small and simple that will be fixed instantly with the right command. :) Thank you for your time! I appreciate it! Best, Susan |
|
From: Stephen T. <st...@to...> - 2006-11-10 19:42:40
|
I am in need of documentation or examples of how to initialize, use and obtain callbacks from vex. I have downloaded the code from CVS but the docs directory is empty. Stephen |
|
From: Lou Sanchez/V. B. <bel...@co...> - 2006-11-10 07:49:25
|
Hi,
I've looked in the documentation and could not find a way to change
on the command line to Valkyrie the location of the Valgrind executable
to run. I can do it from the Options dialog, but it's kind of klunky
since you have to stop the running investigated application and then
restart it. Does anyone have a better solution? Thanks.
Cheers
Lou
|
|
From: Bill T. <bt...@ix...> - 2006-11-09 16:01:17
|
The following suppression does not seem to work with v3.1.1 but does with v3.2.1. Is there a difference in how to use wild cards between the two versions? By the way, I am stuck using 3.1.1 due to customer requirements.
{
socketcall.sendmsg(msg.msg_iov[i])/sendmsg/_ZN11IT_ATLI2_*/*
Memcheck:Param
socketcall.sendmsg(msg.msg_iov[i])
fun:sendmsg
fun:*
}
|
|
From: Gheorghe P. <ghe...@gm...> - 2006-11-09 15:29:10
|
True, I am on a 64-bit machine. Thanks for clearing that out. On 11/9/06, Tom Hughes <to...@co...> wrote: > In message <809...@ma...> > "Gheorghe Postelnicu" <ghe...@gm...> wrote: > > > I just installed the latest version from the download page and upon > > running make check I receive some error messages (see below). The rest > > of the installation process went through flawlessly, but I thought I > > should report this. Any ideas? > > At a guess you're on a 64 bit machine and you haven't got a 32 bit > glibc-devel package installed - it is trying to compile a 32 bit > test case and failing as it can't find the run time startup code > for 32 bit programs. > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Gheorghe Postelnicu, PhD MGH, Harvard Medical School |
|
From: Tom H. <to...@co...> - 2006-11-09 15:22:47
|
In message <809...@ma...>
"Gheorghe Postelnicu" <ghe...@gm...> wrote:
> I just installed the latest version from the download page and upon
> running make check I receive some error messages (see below). The rest
> of the installation process went through flawlessly, but I thought I
> should report this. Any ideas?
At a guess you're on a 64 bit machine and you haven't got a 32 bit
glibc-devel package installed - it is trying to compile a 32 bit
test case and failing as it can't find the run time startup code
for 32 bit programs.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Harris, J. <Je...@ai...> - 2006-11-09 14:32:35
|
I have attached a patch against 3.2.0 for 860 type PPC CPUs. They have a cache line size of 16 which was causing a couple assertions. Valgrind and memcheck seem to work just fine on my application. I have not done any detailed testing with any cache line affecting CPU instructions. Jeff |
|
From: Greg H. <gr...@ho...> - 2006-11-09 14:13:07
|
Hi,
I have a suggestion for the --trace-children option.
I'd like to see each child get logged into a separate log file, kind of the way
that strace does.
at present, what i am seeing, is that all children go into the same log file,
possible overwritting each other's valgrind info (especially with threads :)
Perhaps I missed a command line option to separate the output into separate
files.
here is the command line i'm currently using.
valgrind --log-file=gyachi --show-reachable=yes --num-callers=100
--leak-check=yes --leak-resolution=high --error-limit=no --trace-children=yes
-v -v -v gyachi
all threads log to the same file, instead of different files with PID as th
eextension.
anything i'm missing ?
thx, and best rgds,
-Greg
+---------------------------------------------------------------------+
Please also check the log file at "/dev/null" for additional information.
(from /var/log/Xorg.setup.log)
| Greg Hosler gr...@ho... |
+---------------------------------------------------------------------+
|
|
From: Gheorghe P. <ghe...@gm...> - 2006-11-09 14:10:55
|
Hi, I just installed the latest version from the download page and upon running make check I receive some error messages (see below). The rest of the installation process went through flawlessly, but I thought I should report this. Any ideas? Thanks, make[5]: `writev' is up to date. make[5]: `zeropage' is up to date. make[5]: Leaving directory `/autofs/space/asterix_002/users/postelni/packages/valgrind/valgrind-3.2.1/memcheck/tests' make[4]: Leaving directory `/autofs/space/asterix_002/users/postelni/packages/valgrind/valgrind-3.2.1/memcheck/tests' Making check in x86 make[4]: Entering directory `/autofs/space/asterix_002/users/postelni/packages/valgrind/valgrind-3.2.1/memcheck/tests/x86' make scalar_exit_group scalar_fork scalar_supp scalar_vfork fpeflags pushfpopf pushpopmem scalar sse_memory tronical more_x86_fp fprem make[5]: Entering directory `/autofs/space/asterix_002/users/postelni/packages/valgrind/valgrind-3.2.1/memcheck/tests/x86' gcc -m32 -Winline -Wall -Wshadow -g -mmmx -msse -Wno-long-long -Wdeclaration-after-statement -o scalar_exit_group scalar_exit_group.o /usr/bin/ld: crt1.o: No such file: No such file or directory collect2: ld returned 1 exit status make[5]: *** [scalar_exit_group] Error 1 make[5]: Leaving directory `/autofs/space/asterix_002/users/postelni/packages/valgrind/valgrind-3.2.1/memcheck/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/autofs/space/asterix_002/users/postelni/packages/valgrind/valgrind-3.2.1/memcheck/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/autofs/space/asterix_002/users/postelni/packages/valgrind/valgrind-3.2.1/memcheck/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/autofs/space/asterix_002/users/postelni/packages/valgrind/valgrind-3.2.1/memcheck' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/autofs/space/asterix_002/users/postelni/packages/valgrind/valgrind-3.2.1' make: *** [check] Error 2 -- Gheorghe Postelnicu, PhD MGH, Harvard Medical School |