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
(9) |
2
(5) |
3
(1) |
4
(4) |
5
|
6
(8) |
7
(12) |
|
8
(6) |
9
(10) |
10
(6) |
11
(8) |
12
(12) |
13
(5) |
14
(1) |
|
15
(1) |
16
(12) |
17
(9) |
18
(4) |
19
(8) |
20
(4) |
21
(1) |
|
22
|
23
(4) |
24
(12) |
25
(13) |
26
(16) |
27
(4) |
28
(2) |
|
29
(1) |
30
(4) |
31
(9) |
|
|
|
|
|
From: Michael E L. <me...@co...> - 2006-01-07 22:09:13
|
> this IR block. So if N=0, vex will never chase across such a branch, > which means the IR really does represent a straight line piece of > code. This simplifies the problem of finding calls/returns. Thank you for the explanation. I'm by no means ruling out errors in my instrumentation code, so this sort of analysis should help isolate and identify them. > You might also want to play with --vex-guest-max-insns. Setting > this to 1 will trash performance, but give you a simpler baseline > scenario in which each insn is translated into its own IR block. Very cool, thanks. Cheers, Michael |
|
From: Julian S. <js...@ac...> - 2006-01-07 21:24:10
|
> > Try running with --vex-guest-chase-thresh=0 to disable this; does that > > change the results? > > Yes, it does, but not for the better. Leaving that out, a function that I > know is called 5 times is correctly detected 5 times by the > instrumentation, but when this parameter is set as above, that value jumps > to 224 :) > > vex-guest-chase-thresh #of times seeing foo() > ------------------------------------------------- > not included 5 (correct) > 0 224 > 1 1 > 2 5 > 3 5 > 4 5 > 10 5 > > What is the effect of the value of vex-guest-chase-thresh ? > coregrind/m_main.c indicates a range of 0 to 99 but no further info. That's strange. You should investigate. --vex-guest-chase-thresh=N (where the default N = 10, iirc) controls the extent to which vex will continue disassembling across unconditional branches and call instructions. When it sees such an instruction, it will continue disassembling into the current IR block (at the target of the insn, of course) providing that no more than N instructions have already been disassembled into this IR block. So if N=0, vex will never chase across such a branch, which means the IR really does represent a straight line piece of code. This simplifies the problem of finding calls/returns. Recent callgrinds - the one released with 3.1.0, at least (0.10.1?) forces this value to zero at startup for just such reasons. You might also want to play with --vex-guest-max-insns. Setting this to 1 will trash performance, but give you a simpler baseline scenario in which each insn is translated into its own IR block. J |
|
From: Michael E L. <me...@co...> - 2006-01-07 21:12:02
|
On Sat, 7 Jan 2006, Nicholas Nethercote wrote: > Tracking function entry/exit is in general very difficult, much more so than > you might expect. Agreed. ;) > Josef Weidendorfer's Callgrind tool does a good job, in the Valgrind source > tree there's a file called docs/internals/tracking-fn-entry-exit.txt > which describes the hoops it has to jump through. Thanks for the pointer to this documenation. I had initially looked at adapting Callgrind for my purposes, but figured it would be easier to begin with one of the more basic tools and take a stab at the straightforward way first. I suppose I can revisit it. Cheers, Michael |
|
From: Michael E L. <me...@co...> - 2006-01-07 21:04:07
|
On Sat, 7 Jan 2006, Julian Seward wrote: > 100% coverage is difficult due to the presence of tail calls and > the games the dynamic linker plays, but something like this should > pick up most of them. Yes...I think these sorts of things are actually the cause of the discrepancies I'm seeing. > I suspect your tool might be missing calls rather than returns. Vex > will chase across call instructions under the right circumstances - > in other words, you might get a single block containing the start > of main and the start of a(). Thanks for clarifying exactly what "BB chasing" was...also, thanks for the hints about trace-flags, etc. I've basically copied the machinary in Lackey for detecting calls, and for many functions, the results (i.e., the reported number of times it is called) seem to be correct. In any event, I will look at what Vex is seeing in more detail. > Try running with --vex-guest-chase-thresh=0 to disable this; does that > change the results? Yes, it does, but not for the better. Leaving that out, a function that I know is called 5 times is correctly detected 5 times by the instrumentation, but when this parameter is set as above, that value jumps to 224 :) vex-guest-chase-thresh #of times seeing foo() ------------------------------------------------- not included 5 (correct) 0 224 1 1 2 5 3 5 4 5 10 5 What is the effect of the value of vex-guest-chase-thresh ? coregrind/m_main.c indicates a range of 0 to 99 but no further info. > writing architecture-dependent tools -- the point of the IR is to enable > tools to be decoupled from the underlying architecture. Fair enough. I had seen that assertion made on the list recently and just wanted to confirm it was indeed the case. Cheers, Michael |
|
From: Ron K. <ro...@ko...> - 2006-01-07 19:49:08
|
Hi,
I'm having trouble with pthreads even with the simplest program. I'm using
valgrind 3.1.0 on debian sarge using linux-2.4.26.
Even this simple "textbook" program causes problems:
#include <pthread.h>
void * threadhandler(void * ptr) {
sleep(2);
pthread_exit(0);
}
int main() {
pthread_t thread;
pthread_create(&thread, NULL, &threadhandler, NULL);
pthread_join(thread, NULL);
return 0;
}
I compile it like this: gcc -lpthread -ggdb ./main.c
The errors that this tiny program cause in valgrind are appended to the
bottom of this message. I don't have a clue what the problem could be. I saw
that valgrind has good pthread support, and I've searched google but I just
can't seem to find anyone with the same problem. Does anybody have any clue
what could be going on?
Thank you,
Ron Korving
==17229== Memcheck, a memory error detector.
==17229== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==17229== Using LibVEX rev 1471, a library for dynamic binary translation.
==17229== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==17229== Using valgrind-3.1.0, a dynamic binary instrumentation framework.
==17229== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==17229== For more details, rerun with: -v
==17229==
==17229== Syscall param write(buf) points to uninitialised byte(s)
==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so)
==17229== by 0x402DC6A: pthread_create@@GLIBC_2.1 (in
/lib/libpthread-0.10.so)
==17229== by 0x80484D4: main (main.c:13)
==17229== Address 0xBEFFF8B0 is on thread 1's stack
==17229==
==17229== Syscall param write(buf) points to uninitialised byte(s)
==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so)
==17229== by 0x80484D4: main (main.c:13)
==17229== Address 0xBEFFF9AC is on thread 1's stack
==17229==
==17229== Syscall param write(buf) points to uninitialised byte(s)
==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so)
==17229== by 0x80484E7: main (main.c:15)
==17229== Address 0xBEFFF9A4 is on thread 1's stack
==17229==
==17229== Syscall param write(buf) points to uninitialised byte(s)
==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so)
==17229== by 0x40A2B61: exit (in /lib/libc-2.3.2.so)
==17229== by 0x408CE3D: __libc_start_main (in /lib/libc-2.3.2.so)
==17229== Address 0xBEFFF99C is on thread 1's stack
==17229==
==17229== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 13 from 1)
==17229== malloc/free: in use at exit: 8,160 bytes in 1 blocks.
==17229== malloc/free: 1 allocs, 0 frees, 8,160 bytes allocated.
==17229== For counts of detected errors, rerun with: -v
==17229== searching for pointers to 1 not-freed blocks.
==17229== checked 353,728 bytes.
==17229==
==17229== LEAK SUMMARY:
==17229== definitely lost: 8,160 bytes in 1 blocks.
==17229== possibly lost: 0 bytes in 0 blocks.
==17229== still reachable: 0 bytes in 0 blocks.
==17229== suppressed: 0 bytes in 0 blocks.
==17229== Use --leak-check=full to see details of leaked memory.
|
|
From: Ron K. <ro...@ko...> - 2006-01-07 18:41:03
|
Hi,
I'm having trouble with pthreads even with the simplest program. I'm using
valgrind 3.1.0 on debian sarge using linux-2.4.26.
Even this simple "textbook" program causes problems:
#include <pthread.h>
void * threadhandler(void * ptr) {
sleep(2);
pthread_exit(0);
}
int main() {
pthread_t thread;
pthread_create(&thread, NULL, &threadhandler, NULL);
pthread_join(thread, NULL);
return 0;
}
I compile it like this: gcc -lpthread -ggdb ./main.c
The errors that this tiny program cause in valgrind are appended to the
bottom of this message. I don't have a clue what the problem could be. I saw
that valgrind has good pthread support, and I've searched google but I just
can't seem to find anyone with the same problem. Does anybody have any clue
what could be going on?
Thank you,
Ron Korving
==17229== Memcheck, a memory error detector.
==17229== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==17229== Using LibVEX rev 1471, a library for dynamic binary translation.
==17229== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==17229== Using valgrind-3.1.0, a dynamic binary instrumentation framework.
==17229== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==17229== For more details, rerun with: -v
==17229==
==17229== Syscall param write(buf) points to uninitialised byte(s)
==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so)
==17229== by 0x402DC6A: pthread_create@@GLIBC_2.1 (in
/lib/libpthread-0.10.so)
==17229== by 0x80484D4: main (main.c:13)
==17229== Address 0xBEFFF8B0 is on thread 1's stack
==17229==
==17229== Syscall param write(buf) points to uninitialised byte(s)
==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so)
==17229== by 0x80484D4: main (main.c:13)
==17229== Address 0xBEFFF9AC is on thread 1's stack
==17229==
==17229== Syscall param write(buf) points to uninitialised byte(s)
==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so)
==17229== by 0x80484E7: main (main.c:15)
==17229== Address 0xBEFFF9A4 is on thread 1's stack
==17229==
==17229== Syscall param write(buf) points to uninitialised byte(s)
==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so)
==17229== by 0x40A2B61: exit (in /lib/libc-2.3.2.so)
==17229== by 0x408CE3D: __libc_start_main (in /lib/libc-2.3.2.so)
==17229== Address 0xBEFFF99C is on thread 1's stack
==17229==
==17229== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 13 from 1)
==17229== malloc/free: in use at exit: 8,160 bytes in 1 blocks.
==17229== malloc/free: 1 allocs, 0 frees, 8,160 bytes allocated.
==17229== For counts of detected errors, rerun with: -v
==17229== searching for pointers to 1 not-freed blocks.
==17229== checked 353,728 bytes.
==17229==
==17229== LEAK SUMMARY:
==17229== definitely lost: 8,160 bytes in 1 blocks.
==17229== possibly lost: 0 bytes in 0 blocks.
==17229== still reachable: 0 bytes in 0 blocks.
==17229== suppressed: 0 bytes in 0 blocks.
==17229== Use --leak-check=full to see details of leaked memory.
|
|
From: Nicholas N. <nj...@cs...> - 2006-01-07 18:21:19
|
On Fri, 6 Jan 2006, Michael E Locasto wrote: > A tool I'm constructing needs to be able to detect returns from a function. Tracking function entry/exit is in general very difficult, much more so than you might expect. Josef Weidendorfer's Callgrind tool does a good job, in the Valgrind source tree there's a file called docs/internals/tracking-fn-entry-exit.txt which describes the hoops it has to jump through. Nick |
|
From: Julian S. <js...@ac...> - 2006-01-07 12:46:57
|
On Saturday 07 January 2006 10:47, Leung Ngai-Hang Zachary wrote:
> Hi
>
> I'm trying to record instruction reads as well as data reads and writes.
> Lackey and Cachegrind contain code that does this, so I was looking
> through it. I would like to print to screen the address of every
> instruction read by the CPU, but I can't figure out how to make an IRExpr*
> from an Addr64. How do I do that? I've attached the relevant parts of
> my code below.
>
> Zac
>
> st = bb_in->stmts[i];
>
> switch (st->tag) {
> case Ist_IMark:
> cia = (Addr) st->Ist.IMark.addr;
> addr_expr = mkIRExpr_HWord( sizeofIRType( cia ) );
> // addr_expr = mkIRExpr_HWord( sizeofIRType(
> st->Ist.IMark.addr ) );
> argv = mkIRExprVec_1( addr_expr );
> di = unsafeIRDirty_0_N( /*regparms*/1,
> "trace_ins_read",
> VG_(fnptr_to_fnentry)( trace_ins_read
> ),
> argv );
> addStmtToIRBB( bb, IRStmt_Dirty(di) );
What you want is probably
addr_expr = mkIRExpr_HWord( st->Ist.IMark.addr );
Does that work?
J
|
|
From: Julian S. <js...@ac...> - 2006-01-07 12:45:01
|
On Friday 06 January 2006 23:18, Tom Schutter wrote:
> Rob Latham wrote:
> > On Fri, Jan 06, 2006 at 10:07:25PM +0000, Julian Seward wrote:
> >>>I'm seeing this message with valgrind 3.1.0.
> >>
> >>Last I heard (if I remember correctly) this was caused by a bug in
> >>the CFI info attached to glibc.so or ld.so in SuSE 9.3. Is this
> >>on SuSE 9.3 on a low-end x86?
> >
> > I'm seeing this on debian's libc6-2.3.2.ds1-22 on an elderly (3+
> > years) but not really low-end x86.
> >
> > Seems like a harmless error. Just wasn't sure if you wanted more
> > information about it or not.
> >
> > =3D=3Drob
>
> valgrind 3.1.0 just hit Debian testing a few days ago, and I am now
> seeing this as well. I was planning on trying on running the tarball
> version of valgrind rather than the Debian packaged version to see
> if it made a difference, but I haven't gotten to that yet.
Here's an excerpt from SuSE-9.3 related email:
--11932-- DWARF2 CFI reader: unhandled CFI instruction 0:50
These appear in both /lib/tls/libc.so.6 and /lib/tls/libpthread.so.0.
I could not find what these were by looking in the DWARF3 spec.
=20
So I asked readelf to read the call-frame-info and it has no idea
either:
=20
sewardj@nemesis:~/VgHACKED/trunk$ readelf
--debug-dump=3Dframes /lib/tls/libc.so.6 > /dev/null
readelf: Warning: unsupported or unknown DW_CFA_50
readelf: Warning: unsupported or unknown DW_CFA_50
=46rom this I was convinced that the CFA info from the libraries itself
was bad, since readelf was also complaining about it. What do you get
if you try the same on Debian testing?
In any case it's a pretty harmless problem except for the fact that it
causes V to fail all its regression tests. One easy fix/kludge you
might want to consider is to comment out the line that prints that=20
message. I think it's in coregrind/m_debuginfo/dwarf.c.
J
|
|
From: Julian S. <js...@ac...> - 2006-01-07 12:37:13
|
> Is there a more straightforward way to notice a return from a function?
It sounds like a reasonable first approach. Note in general getting
100% coverage is difficult due to the presence of tail calls and
the games the dynamic linker plays, but something like this should
pick up most of them.
> For example, the results are often "off by one": given this program:
>
> int a(){return 5;}
>
> int main()
> {
> int x = a();
> return 0;
> }
I suspect your tool might be missing calls rather than returns. Vex
will chase across call instructions under the right circumstances -
in other words, you might get a single block containing the start
of main and the start of a().
Try running with --vex-guest-chase-thresh=0 to disable this; does that
change the results?
Make friends with --trace-flags= and --trace-notbelow= and 'objdump -d
my_executable' so you figure out how your program is getting mangled
by vex. Useful --trace-flags= values are 10000000 and 10001000.
> I'm under the impression that tools do not have access to the original
> instruction stream, and thus I can't simply look for leave/ret
> combinations.
True. Putting the original instruction stream in would lead to people
writing architecture-dependent tools -- the point of the IR is to enable
tools to be decoupled from the underlying architecture.
J
|
|
From: Leung Ngai-H. Z. <leu...@co...> - 2006-01-07 10:47:57
|
Hi
I'm trying to record instruction reads as well as data reads and writes.
Lackey and Cachegrind contain code that does this, so I was looking
through it. I would like to print to screen the address of every
instruction read by the CPU, but I can't figure out how to make an IRExpr*
from an Addr64. How do I do that? I've attached the relevant parts of
my code below.
Zac
st = bb_in->stmts[i];
switch (st->tag) {
case Ist_IMark:
cia = (Addr) st->Ist.IMark.addr;
addr_expr = mkIRExpr_HWord( sizeofIRType( cia ) );
// addr_expr = mkIRExpr_HWord( sizeofIRType(
st->Ist.IMark.addr ) );
argv = mkIRExprVec_1( addr_expr );
di = unsafeIRDirty_0_N( /*regparms*/1,
"trace_ins_read",
VG_(fnptr_to_fnentry)( trace_ins_read
),
argv );
addStmtToIRBB( bb, IRStmt_Dirty(di) );
|
|
From: Tom S. <to...@pl...> - 2006-01-07 00:45:01
|
Rob Latham wrote: > On Fri, Jan 06, 2006 at 10:07:25PM +0000, Julian Seward wrote: > >>>I'm seeing this message with valgrind 3.1.0. >> >>Last I heard (if I remember correctly) this was caused by a bug in >>the CFI info attached to glibc.so or ld.so in SuSE 9.3. Is this >>on SuSE 9.3 on a low-end x86? > > > I'm seeing this on debian's libc6-2.3.2.ds1-22 on an elderly (3+ > years) but not really low-end x86. > > Seems like a harmless error. Just wasn't sure if you wanted more > information about it or not. > > ==rob > valgrind 3.1.0 just hit Debian testing a few days ago, and I am now seeing this as well. I was planning on trying on running the tarball version of valgrind rather than the Debian packaged version to see if it made a difference, but I haven't gotten to that yet. $ dpkg -l valgrind libc6 gcc-3.3 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii gcc-3.3 3.3.6-10 The GNU C compiler ii libc6 2.3.5-8 GNU C Library: Shared libraries and ii valgrind 3.1.0-2 A memory debugger and profiler -- Tom Schutter (mailto:to...@pl...) Platte River Associates, Inc. (http://www.platte.com) |
|
From: Michael E L. <me...@co...> - 2006-01-06 23:00:50
|
A tool I'm constructing needs to be able to detect returns from a
function. Detecting entry into a function is easy; I simply extended
the mechanism present in Lackey:
During each BB, copy the IR preamble, then for the rest of the
statements, switch on the tag and use VG_(get_fnname_if_entry) to see
if it is the first statement in a function. Add instrumentation
recording this fact.
The difficulty I'm having is detecting when a particular BB represents
a return from a function. After iterating through all the statements
in the BB, I examine the bb->jumpkind to see if it is Ijk_Ret. If it
is, I look at the first non-preamble statement in the BB and call
VG_(get_fnname)() using the Ist.IMark.addr of that statement as the
first argument. I add instrumentation recording the fact that this
function was returned from. The results are not what I expect (I can
forward details and a sample run if necessary, see below for the most
noticeable problem).
Is there a more straightforward way to notice a return from a function?
I'm under the impression that tools do not have access to the original
instruction stream, and thus I can't simply look for leave/ret
combinations.
Cheers,
Michael
For example, the results are often "off by one": given this program:
int a(){return 5;}
int main()
{
int x = a();
return 0;
}
my tool sees the return value of 'main' as 5 (rather than for a).
|
|
From: Rob L. <ro...@te...> - 2006-01-06 22:18:25
|
On Fri, Jan 06, 2006 at 10:07:25PM +0000, Julian Seward wrote: > > I'm seeing this message with valgrind 3.1.0. > > Last I heard (if I remember correctly) this was caused by a bug in > the CFI info attached to glibc.so or ld.so in SuSE 9.3. Is this > on SuSE 9.3 on a low-end x86? I'm seeing this on debian's libc6-2.3.2.ds1-22 on an elderly (3+ years) but not really low-end x86. Seems like a harmless error. Just wasn't sure if you wanted more information about it or not. ==rob -- Rob Latham Chicago, IL USA |
|
From: Julian S. <js...@ac...> - 2006-01-06 22:07:33
|
On Friday 06 January 2006 21:59, Rob Latham wrote:
> On Fri, Jul 01, 2005 at 09:45:39AM +0100, Julian Seward wrote:
> > > DWARF2 CFI reader: unhandled CFI instruction 0:50
> > > DWARF2 CFI reader: unhandled CFI instruction 0:50
> >
> > This would be easy enough to fix if only I had a clue what CFI
> > instruction #50 (0x32) is. Neither the DWARF3 spec nor the gdb-6.3
> > sources ("the ultimate reference" :-) mention it. I suspect
> > it's some GNUish extension.
> >
> > Could you email me the executable itself (closeall, I mean) and
> > I'll prod it with readelf and see what happens.
>
> I'm seeing this message with valgrind 3.1.0.
Last I heard (if I remember correctly) this was caused by a bug in
the CFI info attached to glibc.so or ld.so in SuSE 9.3. Is this
on SuSE 9.3 on a low-end x86?
J
|
|
From: Rob L. <ro...@te...> - 2006-01-06 21:59:31
|
On Fri, Jul 01, 2005 at 09:45:39AM +0100, Julian Seward wrote:
>
> > DWARF2 CFI reader: unhandled CFI instruction 0:50
> > DWARF2 CFI reader: unhandled CFI instruction 0:50
>
> This would be easy enough to fix if only I had a clue what CFI
> instruction #50 (0x32) is. Neither the DWARF3 spec nor the gdb-6.3
> sources ("the ultimate reference" :-) mention it. I suspect
> it's some GNUish extension.
>
> Could you email me the executable itself (closeall, I mean) and
> I'll prod it with readelf and see what happens.
I'm seeing this message with valgrind 3.1.0. I've got a small
executable that gives this message and the source code (for what it's
worth).
http://terizla.org/~robl/tmp/try
http://terizla.org/~robl/tmp/try.c
==rob
--
Rob Latham Chicago, IL USA
|
|
From: Nicholas N. <nj...@cs...> - 2006-01-06 16:36:37
|
On Fri, 6 Jan 2006, Leung Ngai-Hang Zachary wrote: > I'm writing a small tool for Valgrind, and I was wondering how I could > compile only my tool and not all of Valgrind. Thanks! Change the TOOLS variable in the top level Makefile.am file so it only includes your tool's name, then rerun autogen.sh/configure/make. Valgrind's core will still be built, but you need that. Nick |
|
From: Leung Ngai-H. Z. <leu...@co...> - 2006-01-06 13:20:09
|
Hi I'm writing a small tool for Valgrind, and I was wondering how I could compile only my tool and not all of Valgrind. Thanks! Zac |
|
From: Paul P. <ppl...@gm...> - 2006-01-06 04:59:22
|
T24gMS81LzA2LCDC3r2hIDxsdW9qaWFuQGNvcnN3b3JrLmNvbT4gd3JvdGU6Cgo+IElzIGl0IHBv c3NpYmxlIHRvIHBvcnQgdmFsZ3JpbmQgdG8gQ3lnd2luID8KCkZyb206CiAgaHR0cDovL3d3dy52 YWxncmluZC5vcmcvaW5mby9wbGF0Zm9ybXMuaHRtbAoKICBJbiBwYXJ0aWN1bGFyIFdpbmRvd3Mg aXMgbm90IHVuZGVyIGNvbnNpZGVyYXRpb24gaGVyZSBiZWNhdXNlCnBvcnRpbmcgdG8gaXQgd291 bGQgcmVxdWlyZSBzbyBtYW55IGNoYW5nZXMgaXQgd291bGQgYWxtb3N0IGJlIGEKc2VwYXJhdGUg cHJvamVjdC4gIEFsc28sIG5vbi1vcGVuLXNvdXJjZSBPU2VzIGFyZSBkaWZmaWN1bHQgdG8gZGVh bAp3aXRoOyAgYmVpbmcgYWJsZSB0byBzZWUgdGhlIE9TIGFuZCBhc3NvY2lhdGVkIChsaWJjKSBz b3VyY2UgY29kZQptYWtlcyB0aGluZ3MgbXVjaCBlYXNpZXIuCg== |
|
From: <lu...@co...> - 2006-01-06 03:26:16
|
SXMgaXQgcG9zc2libGUgdG8gcG9ydCB2YWxncmluZCB0byBDeWd3aW4gPw0KDQpqYWNreS4NCg0K |
|
From: Annamalai G.
|
Hi All, I am trying to use valgrind to test our DataBlitz (DBZ) main memory database. When I run DBZ individually, it is working fine. But when I run it via valgrind it is failing when trying to do mmap. The reported error is always "Interrupted System Call". Any help much appreciated. I am running it on Red Hat Linux release 9 (Shrike). Here is a valgrind output. Any help much appreciated. ==7595== Memcheck, a memory error detector. ==7595== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==7595== Using LibVEX rev 1367, a library for dynamic binary translation. ==7595== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==7595== Using valgrind-3.0.1, a dynamic binary instrumentation framework. ==7595== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. --7595-- Valgrind library directory: /home/prabhakt/local/lib/valgrind --7595-- Command line --7595-- datablitz --7595-- CREAT --7595-- TRUNC --7595-- Startup, with flags: --7595-- --memcheck:leak-check=yes --7595-- --vex-iropt-precise-memory-exns=yes --7595-- --trace-signals=yes --7595-- -v --7595-- -- --7595-- Contents of /proc/version: --7595-- Linux version 2.4.20-8 (bhc...@po...) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Thu Mar 13 17:54:28 EST 2003 --7595-- Reading syms from /home2/prabhakt/anna/MSQL/bin/datablitz_joint (0x8048000) --7595-- Reading syms from /lib/ld-2.3.2.so (0x1B8E4000) --7595-- Reading syms from /home2/prabhakt/local/lib/valgrind/stage2 (0xB0000000) --7595-- Max kernel-supported signal is 64 --7595-- Reading suppressions file: /home/prabhakt/local/lib/valgrind/default.supp ==7595== --7595-- signal 11 arrived ... si_code=1, EIP=0x1B8E94EA, eip=0xB1443C46 --7595-- SIGSEGV: si_code=1 faultaddr=0x52BFDF88 tid=1 ESP=0x52BFDF80 seg=0x52BFE000-0x52C00000 fl=30 shad=0x52D00000-0xB0000000 --7595-- -> extended stack base to 0x52BFD000 --7595-- Reading syms from /home2/prabhakt/local/lib/valgrind/vg_preload_core.so (0x1B8FB000) --7595-- Reading syms from /home2/prabhakt/local/lib/valgrind/vgpreload_memcheck.so (0x1B8FD000) --7595-- REDIR: 0x1B8F54A0 (index) redirected to 0x1B9002EC (index) --7595-- REDIR: 0x1B8F5640 (strlen) redirected to 0x1B9004F0 (strlen) --7595-- Reading syms from /home2/prabhakt/anna/MSQL/lib/libserver-mt.so (0x1B902000) --7595-- Reading syms from /home2/prabhakt/anna/MSQL/lib/librel-mt.so (0x1B989000) --7595-- Reading syms from /home2/prabhakt/anna/MSQL/lib/libblz-mt.so (0x1BB2B000) --7595-- Reading syms from /home2/prabhakt/anna/MSQL/lib/librnm-mt.so (0x1BEDA000) --7595-- Reading syms from /home2/prabhakt/anna/MSQL/lib/libmsql-mt.so (0x1BEF6000) --7595-- Reading syms from /lib/libdl-2.3.2.so (0x1BFE1000) --7595-- Reading syms from /lib/libnsl-2.3.2.so (0x1BFE4000) --7595-- Reading syms from /lib/libcrypt-2.3.2.so (0x1BFF9000) --7595-- Reading syms from /lib/librt-2.3.2.so (0x1C026000) --7595-- Reading syms from /lib/libpthread-0.10.so (0x1C039000) --7595-- Reading syms from /usr/lib/libstdc++.so.5.0.3 (0x1C08B000) --7595-- object doesn't have a symbol table --7595-- Reading syms from /lib/libm-2.3.2.so (0x1C13E000) --7595-- Reading syms from /lib/libgcc_s-3.2.2-20030225.so.1 (0x1C160000) --7595-- object doesn't have a symbol table --7595-- Reading syms from /lib/libc-2.3.2.so (0x1C168000) --7595-- REDIR: 0x1C1E3B20 (memset) redirected to 0x1B900B54 (memset) ++7595++ sys_sigaction: sigNo 32, new 0x52BFE3BC, old 0x0, new flags 0x4000000 ++7595++ sys_sigaction: sigNo 33, new 0x52BFE3BC, old 0x0, new flags 0x4000000 ++7595++ sys_sigaction: sigNo 34, new 0x52BFE3BC, old 0x0, new flags 0x4000000 ++7595++ do_setmask: tid = 1 how = 0 (SIG_BLOCK), set = 0x52BFE69C 0000000080000000 --7595-- REDIR: 0x1C1E2500 (rindex) redirected to 0x1B900224 (rindex) --7595-- REDIR: 0x1C1E1A40 (strcpy) redirected to 0x1B900528 (strcpy) --7595-- REDIR: 0x1C1E21D0 (strlen) redirected to 0x1B9004D4 (strlen) --7595-- REDIR: 0x1C116E70 (operator new(unsigned)) redirected to 0x1B8FED4D (operator new(unsigned)) --7595-- REDIR: 0x1C1DAD80 (malloc) redirected to 0x1B8FE9B6 (malloc) --7595-- REDIR: 0x1C116FD0 (operator new[](unsigned)) redirected to 0x1B8FF187 (operator new[](unsigned)) --7595-- REDIR: 0x1C1E2470 (strncpy) redirected to 0x1B9005D8 (strncpy) --7595-- REDIR: 0x1C1E23B0 (strncmp) redirected to 0x1B9006E0 (strncmp) ==7595== Source and destination overlap in strncpy(0x1BE1E847, 0x1BE1E847, 4095) ==7595== at 0x1B900671: strncpy (mac_replace_strmem.c:290) ==7595== by 0x1BC7C89B: BlzMELT::setProgName(char const*) (BlzMELT.c:359) ==7595== by 0x1BC7CA24: BlzMELT::BlzMELT(char const*, BlzRC (*)(BlzMELTnode*)) (BlzMELT.c:401) ==7595== by 0x1BC7CBF5: BlzMELT::testAndInit() (BlzMELT.c:450) ==7595== by 0x1B91E301: BlzMELT::init() (BlzMELT.h:216) ==7595== by 0x1BD22FFA: BlzThreadData::BlzThreadData() (BlzThreadData.c:51) ==7595== by 0x1BD1A932: __static_initialization_and_destruction_0(int, int) (BlzSysInternal.c:82) ==7595== by 0x1BD1ABE2: _GLOBAL__I_BlzProcessIDnull (streambuf:131) ==7595== by 0x1BD698E4: (within /home2/prabhakt/anna/MSQL/lib/libblz-mt.so) ==7595== by 0x1BB9F648: (within /home2/prabhakt/anna/MSQL/lib/libblz-mt.so) ==7595== by 0x1B8F04B0: _dl_init (in /lib/ld-2.3.2.so) ==7595== by 0x1B8E4C1C: (within /lib/ld-2.3.2.so) --7595-- REDIR: 0x1C1DB570 (calloc) redirected to 0x1B8FFC87 (calloc) --7595-- REDIR: 0x1C1E0C80 (strcat) redirected to 0x1B90032C (strcat) --7595-- REDIR: 0x1C1DB000 (realloc) redirected to 0x1B8FFD32 (realloc) --7595-- REDIR: 0x1C1E0FA0 (strcmp) redirected to 0x1B900738 (strcmp) --7595-- signal 11 arrived ... si_code=1, EIP=0x1B921A39, eip=0xB162059F --7595-- SIGSEGV: si_code=1 faultaddr=0x52BFC790 tid=1 ESP=0x52BFC790 seg=0x52BFD000-0x52C00000 fl=34 shad=0x52D00000-0xB0000000 --7595-- -> extended stack base to 0x52BFC000 --7595-- signal 11 arrived ... si_code=1, EIP=0x1BBCEEE0, eip=0xB1624EC3 --7595-- SIGSEGV: si_code=1 faultaddr=0x52BFA710 tid=1 ESP=0x52BFA710 seg=0x52BFC000-0x52C00000 fl=34 shad=0x52D00000-0xB0000000 --7595-- -> extended stack base to 0x52BFA000 --7595-- REDIR: 0x1C1E0E30 (index) redirected to 0x1B9002CC (index) --7595-- signal 11 arrived ... si_code=1, EIP=0x1B93D133, eip=0xB162D1A7 --7595-- SIGSEGV: si_code=1 faultaddr=0x52BF76E0 tid=1 ESP=0x52BF76E0 seg=0x52BFA000-0x52C00000 fl=34 shad=0x52D00000-0xB0000000 --7595-- -> extended stack base to 0x52BF7000 --7595-- signal 11 arrived ... si_code=1, EIP=0x1BBCEEE0, eip=0xB1624EC3 --7595-- SIGSEGV: si_code=1 faultaddr=0x52BF5660 tid=1 ESP=0x52BF5660 seg=0x52BF7000-0x52C00000 fl=34 shad=0x52D00000-0xB0000000 --7595-- -> extended stack base to 0x52BF5000 --7595-- signal 11 arrived ... si_code=1, EIP=0x1BBCF3DE, eip=0xB1633AA3 --7595-- SIGSEGV: si_code=1 faultaddr=0x52BF4550 tid=1 ESP=0x52BF4550 seg=0x52BF5000-0x52C00000 fl=34 shad=0x52D00000-0xB0000000 --7595-- -> extended stack base to 0x52BF4000 --7595-- signal 11 arrived ... si_code=1, EIP=0x1BBCF315, eip=0xB163414F --7595-- SIGSEGV: si_code=1 faultaddr=0x52BF3524 tid=1 ESP=0x52BF3524 seg=0x52BF4000-0x52C00000 fl=34 shad=0x52D00000-0xB0000000 --7595-- -> extended stack base to 0x52BF3000 --7595-- signal 11 arrived ... si_code=1, EIP=0x1BBCEEE0, eip=0xB1624EC3 --7595-- SIGSEGV: si_code=1 faultaddr=0x52BF14A0 tid=1 ESP=0x52BF14A0 seg=0x52BF3000-0x52C00000 fl=34 shad=0x52D00000-0xB0000000 --7595-- -> extended stack base to 0x52BF1000 --7595-- REDIR: 0x1C1DAF40 (free) redirected to 0x1B8FF4CB (free) --7595-- REDIR: 0x1C115960 (operator delete(void*)) redirected to 0x1B8FF75F (operator delete(void*)) --7595-- signal 11 arrived ... si_code=1, EIP=0x1BBCEEE0, eip=0xB1624EC3 --7595-- SIGSEGV: si_code=1 faultaddr=0x52BF0460 tid=1 ESP=0x52BF0460 seg=0x52BF1000-0x52C00000 fl=34 shad=0x52D00000-0xB0000000 --7595-- -> extended stack base to 0x52BF0000 --7595-- REDIR: 0x1C1E3900 (memchr) redirected to 0x1B900798 (memchr) --7595-- REDIR: 0x1C1E4130 (memcpy) redirected to 0x1B9007BC (memcpy) --7595-- REDIR: 0x1C1E2280 (strnlen) redirected to 0x1B9004B0 (strnlen) ++7595++ sys_sigaction: sigNo 2, new 0x52BF74C0, old 0x52BF7430, new flags 0x14000004 ++7595++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x0 0000000000000000 ++7595++ oldset=0x52BF75A0 0000000080000000 ++7595++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x52BF75A0 0000000080000000 ++7595++ sys_sigaction: sigNo 15, new 0x52BF74C0, old 0x52BF7430, new flags 0x14000004 ++7595++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x0 0000000000000000 ++7595++ oldset=0x52BF75A0 0000000080000000 ++7595++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x52BF75A0 0000000080000000 ++7595++ sys_sigaction: sigNo 14, new 0x52BF74C0, old 0x52BF7430, new flags 0x14000004 ++7595++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x0 0000000000000000 ++7595++ oldset=0x52BF75A0 0000000080000000 ++7595++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x52BF75A0 0000000080000000 ++7595++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x0 0000000000000000 ++7595++ oldset=0x52BF7630 0000000080000000 ++7595++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x52BF7630 0000000080004000 ++7595++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x0 0000000000000000 ++7595++ oldset=0x52BF7630 0000000080004000 ++7595++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x52BF7630 0000000080004002 --7595-- REDIR: 0x1C1159C0 (operator delete[](void*)) redirected to 0x1B8FFA77 (operator delete[](void*)) DataBlitz(TM) Main-Memory Database System Release 7.0.Lh02-32SIO-beta3-d Copyright(C) 2003 Lucent Technologies Inc. All Rights Reserved. *** Starting DataBlitz on system database: /home/prabhakt/anna/pdb/BlzSysDB *** System started at Wed Jan 4 11:58:36 2006 DataBlitz server: datablitz OS Pid: 7595 Config File: /home/prabhakt/anna/pdb/sys.rc --7595-- signal 11 arrived ... si_code=1, EIP=0x1BD09E53, eip=0xB16F7B7D --7595-- SIGSEGV: si_code=1 faultaddr=0x52BD1290 tid=1 ESP=0x52BD1290 seg=0x52BF0000-0x52C00000 fl=34 shad=0x52D00000-0xB0000000 --7595-- -> extended stack base to 0x52BD1000 --7595-- signal 11 arrived ... si_code=1, EIP=0x1BBCF3DE, eip=0xB1633AA3 --7595-- SIGSEGV: si_code=1 faultaddr=0x52BD0230 tid=1 ESP=0x52BD0230 seg=0x52BD1000-0x52C00000 fl=34 shad=0x52D00000-0xB0000000 --7595-- -> extended stack base to 0x52BD0000 --7595-- signal 11 arrived ... si_code=1, EIP=0x1BBCF315, eip=0xB163414F --7595-- SIGSEGV: si_code=1 faultaddr=0x52BCF204 tid=1 ESP=0x52BCF204 seg=0x52BD0000-0x52C00000 fl=34 shad=0x52D00000-0xB0000000 --7595-- -> extended stack base to 0x52BCF000 --7595-- signal 11 arrived ... si_code=1, EIP=0x1BBCEEE0, eip=0xB1624EC3 --7595-- SIGSEGV: si_code=1 faultaddr=0x52BCD180 tid=1 ESP=0x52BCD180 seg=0x52BCF000-0x52C00000 fl=34 shad=0x52D00000-0xB0000000 --7595-- -> extended stack base to 0x52BCD000 --7595-- signal 11 arrived ... si_code=1, EIP=0x1BBCEEE0, eip=0xB1624EC3 --7595-- SIGSEGV: si_code=1 faultaddr=0x52BCC190 tid=1 ESP=0x52BCC190 seg=0x52BCD000-0x52C00000 fl=34 shad=0x52D00000-0xB0000000 --7595-- -> extended stack base to 0x52BCC000 ++7595++ sys_sigaction: sigNo 11, new 0x52BF6350, old 0x52BF62C0, new flags 0x14000004 ++7595++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x0 0000000000000000 ++7595++ oldset=0x52BF6430 0000000080004002 ++7595++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x52BF6430 0000000080004002 --7595-- REDIR: 0x1C1E3CE0 (stpcpy) redirected to 0x1B900944 (stpcpy) 01/04/2006 11:58:37 263696 7595 16384 datablitz [1] BlzErrSev = Error BlzRC = blzErrOpSys at ::startSys() BlzRootSrv.c::3409 [1] details: DataBlitz server failed to open the sysDB name='/home/prabhakt/anna/pdb/BlzSysDB' 01/04/2006 11:58:37 239923 7595 16384 datablitz [2] BlzErrSev = Error BlzRC = blzErrOpSys at BlzSysInternal::open() BlzSysInternal.c::1822 [2] details: Low level memory instantiation failed for sysDB name='/home/prabhakt/anna/pdb/BlzSysDB' 01/04/2006 11:58:37 233621 7595 16384 datablitz [3] BlzErrSev = Error BlzRC = blzErrOpSys at BlzSysDB::initMemImage() BlzSysDB.c::4521 [3] details: Low level memory instantiation failed for sysDB name='/home/prabhakt/anna/pdb/BlzSysDB' 01/04/2006 11:58:37 222055 7595 16384 datablitz [4] BlzErrSev = Error BlzRC = blzErrOpSys at BlzBaseDB::creatMemImage() BlzBaseDB.c::1490 [4] details: Unable to map/attach memory for db name='/home/prabhakt/anna/pdb/BlzSysDB' mode=26 01/04/2006 11:58:37 211097 7595 16384 datablitz [5] BlzErrSev = Error BlzRC = blzErrOpSys at BlzBaseDB::mapDB() BlzBaseDB.c::488 [5] details: Unable to map/attach memory for db name='/home/prabhakt/anna/pdb/BlzSysDB' mode=26 addr=0x17d78400 size=25395200 maxSize=209715200 01/04/2006 11:58:37 109439 7595 16384 datablitz [6] BlzErrSev = Error BlzRC = blzErrOpSys at BlzMmap::fastMap() ../../include/dbmgmt/BlzMmap.ih::377 [6] details: Memory map file fd=4 name='/home/prabhakt/anna/pdb/BlzSysDB/mem_image' to addr=0x17d79000 [6] details: for size=209715200 using prot=3 flags=17 failed [6] details: Operating system errno=2 errstr='No such file or directory' ++7595++ sys_sigaction: sigNo 14, new 0x52BF72D0, old 0x52BF7240, new flags 0x4000000 ++7595++ do_setmask: tid = 1 how = 1 (SIG_UNBLOCK), set = 0x52BF7470 0000000000002000 --7595-- REDIR: 0x1C1E3AC0 (memmove) redirected to 0x1B900B78 (memmove) DataBlitz server -- EXITING 01/04/2006 11:58:37 364372 7595 16384 datablitz [1] BlzErrSev = Error BlzRC = blzErrOpSys at ::blzRootMain() BlzRootSrv.c::3859 [1] details: Problems encountered opening/recovering sysDB name='/home/prabhakt/anna/pdb/BlzSysDB' while starting up ++7595++ sys_sigaction: sigNo 11, new 0xB0AEC8D8, old 0x0, new flags 0x0 ++7595++ sys_sigaction: sigNo 7, new 0xB0AEC8D4, old 0x0, new flags 0x0 ++7595++ sys_sigaction: sigNo 4, new 0xB0AEC8D0, old 0x0, new flags 0x0 ++7595++ sys_sigaction: sigNo 8, new 0xB0AEC8EC, old 0x0, new flags 0x0 ==7595== ==7595== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 44 from 1) ==7595== ==7595== 1 errors in context 1 of 1: ==7595== Source and destination overlap in strncpy(0x1BE1E847, 0x1BE1E847, 4095) ==7595== at 0x1B900671: strncpy (mac_replace_strmem.c:290) ==7595== by 0x1BC7C89B: BlzMELT::setProgName(char const*) (BlzMELT.c:359) ==7595== by 0x1BC7CA24: BlzMELT::BlzMELT(char const*, BlzRC (*)(BlzMELTnode*)) (BlzMELT.c:401) ==7595== by 0x1BC7CBF5: BlzMELT::testAndInit() (BlzMELT.c:450) ==7595== by 0x1B91E301: BlzMELT::init() (BlzMELT.h:216) ==7595== by 0x1BD22FFA: BlzThreadData::BlzThreadData() (BlzThreadData.c:51) ==7595== by 0x1BD1A932: __static_initialization_and_destruction_0(int, int) (BlzSysInternal.c:82) ==7595== by 0x1BD1ABE2: _GLOBAL__I_BlzProcessIDnull (streambuf:131) ==7595== by 0x1BD698E4: (within /home2/prabhakt/anna/MSQL/lib/libblz-mt.so) ==7595== by 0x1BB9F648: (within /home2/prabhakt/anna/MSQL/lib/libblz-mt.so) ==7595== by 0x1B8F04B0: _dl_init (in /lib/ld-2.3.2.so) ==7595== by 0x1B8E4C1C: (within /lib/ld-2.3.2.so) --7595-- --7595-- supp: 44 Ugly strchr error in /lib/ld-2.3.2.so ==7595== ==7595== IN SUMMARY: 1 errors from 1 contexts (suppressed: 44 from 1) ==7595== ==7595== malloc/free: in use at exit: 123628 bytes in 28 blocks. ==7595== malloc/free: 118 allocs, 90 frees, 249369 bytes allocated. ==7595== ==7595== searching for pointers to 28 not-freed blocks. ==7595== checked 2577124 bytes. ==7595== ==7595== ==7595== 40 bytes in 1 blocks are possibly lost in loss record 8 of 22 ==7595== at 0x1B8FF206: operator new[](unsigned) (vg_replace_malloc.c:197) ==7595== by 0x1BD645AC: BlzVersion::BlzVersion(char const*) (BlzVersion.c:165) ==7595== by 0x1BD64E27: __static_initialization_and_destruction_0(int, int) (BlzVersion.c:594) ==7595== by 0x1BD64EB4: _GLOBAL__I_blzVersionString (streambuf:131) ==7595== by 0x1BD698E4: (within /home2/prabhakt/anna/MSQL/lib/libblz-mt.so) ==7595== by 0x1BB9F648: (within /home2/prabhakt/anna/MSQL/lib/libblz-mt.so) ==7595== by 0x1B8F04B0: _dl_init (in /lib/ld-2.3.2.so) ==7595== by 0x1B8E4C1C: (within /lib/ld-2.3.2.so) ==7595== ==7595== ==7595== 4104 bytes in 1 blocks are definitely lost in loss record 19 of 22 ==7595== at 0x1B8FEDCC: operator new(unsigned) (vg_replace_malloc.c:164) ==7595== by 0x1BBE64B0: BlzLicense::init() (BlzCrypt.c:199) ==7595== by 0x1BBE69D4: BlzLicense::load(char const*, int) (BlzCrypt.c:304) ==7595== by 0x1BBE6021: BlzCrypt::checkLicense(void*) (BlzCrypt.c:137) ==7595== by 0x1B93DA60: blzRootMain(int, char**, char**) (BlzRootSrv.c:3822) ==7595== by 0x1B921B38: jointMain(int, char**, char**) (BlzJointSrv.c:100) ==7595== by 0x8048835: main (BlzSrvMain.c:21) ==7595== ==7595== LEAK SUMMARY: ==7595== definitely lost: 4104 bytes in 1 blocks. ==7595== possibly lost: 40 bytes in 1 blocks. ==7595== still reachable: 119484 bytes in 26 blocks. ==7595== suppressed: 0 bytes in 0 blocks. ==7595== Reachable blocks (those to which a pointer was found) are not shown. ==7595== To see them, rerun with: --show-reachable=yes --7595-- memcheck: sanity checks: 53 cheap, 3 expensive --7595-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --7595-- memcheck: auxmaps: 0 searches, 0 comparisons --7595-- memcheck: secondaries: 56 issued (3584k, 3M) --7595-- memcheck: secondaries: 113 accessible and distinguished (7232k, 7M) --7595-- tt/tc: 26457 tt lookups requiring 31945 probes --7595-- tt/tc: 26457 fast-cache updates, 4 flushes --7595-- translate: new 12461 (268813 -> 4382870; ratio 163:10) [0 scs] --7595-- translate: dumped 0 (0 -> ??) --7595-- translate: discarded 10 (285 -> ??) --7595-- scheduler: 2658704 jumps (bb entries). --7595-- scheduler: 53/14824 major/minor sched events. --7595-- sanity: 54 cheap, 3 expensive checks. --7595-- exectx: 4999 lists, 175 contexts (avg 0 per list) --7595-- exectx: 253 searches, 81 full compares (320 per 1000) --7595-- exectx: 207 cmp2, 130 cmp4, 0 cmpAll Rgds, anna -- Once upon a time, a man asked his girl, "Will you marry me?" She said, "No." And they lived happily ever after. |
|
From: Brian A. <bri...@gm...> - 2006-01-04 01:12:15
|
Wow. I didnt think to check that. But, the update seems to have fixed the problem. Thanks a bunch! ~Brian Julian Seward Wrote: >>didnt fix the problem. Any ideas? >> >> > >First off, try with 3.1.0. That has majorly overhauled memory management >compared to 3.0.1 (basically you're reporting a bug against an old version). > >J > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >Valgrind-users mailing list >Val...@li... >https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > |
|
From: Julian S. <js...@ac...> - 2006-01-04 01:00:37
|
> didnt fix the problem. Any ideas? First off, try with 3.1.0. That has majorly overhauled memory management compared to 3.0.1 (basically you're reporting a bug against an old version). J |
|
From: Brian A. <bri...@gm...> - 2006-01-04 00:51:31
|
Greetings. I am attempting to use valgrind on an application I am writing. Its written in C, but uses the botan library (http://botan.randombit.net/), and as a dependancy, the gmp library (http://www.swox.com/gmp). The program runs "ok" when its not under valgrind. But, I get the following when its under valgrind: $ valgrind --leak-check=yes ./a.out --help ==28586== Memcheck, a memory error detector. ==28586== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==28586== Using LibVEX rev 1367, a library for dynamic binary translation. ==28586== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==28586== Using valgrind-3.0.1, a dynamic binary instrumentation framework. ==28586== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==28586== For more details, rerun with: -v ==28586== ./a.out: error while loading shared libraries: libgmp.so.3: cannot enable executable stack as shared object requires: Invalid argument ==28586== Jump to the invalid address stated on the next line ==28586== at 0x4FA: ??? ==28586== by 0x1B8EF5EB: _dl_signal_error (in /lib/ld-2.3.5.so) ==28586== by 0x1B8EED11: _dl_map_object_deps (in /lib/ld-2.3.5.so) ==28586== by 0x1B8E63DE: dl_main (in /lib/ld-2.3.5.so) ==28586== by 0x1B8F2AE5: _dl_sysdep_start (in /lib/ld-2.3.5.so) ==28586== by 0x1B8E54CD: _dl_start (in /lib/ld-2.3.5.so) ==28586== by 0x1B8E47D6: (within /lib/ld-2.3.5.so) ==28586== Address 0x4FA is not stack'd, malloc'd or (recently) free'd ==28586== ==28586== Process terminating with default action of signal 11 (SIGSEGV) ==28586== Access not within mapped region at address 0x4FA ==28586== at 0x4FA: ??? ==28586== by 0x1B8EF5EB: _dl_signal_error (in /lib/ld-2.3.5.so) ==28586== by 0x1B8EED11: _dl_map_object_deps (in /lib/ld-2.3.5.so) ==28586== by 0x1B8E63DE: dl_main (in /lib/ld-2.3.5.so) ==28586== by 0x1B8F2AE5: _dl_sysdep_start (in /lib/ld-2.3.5.so) ==28586== by 0x1B8E54CD: _dl_start (in /lib/ld-2.3.5.so) ==28586== by 0x1B8E47D6: (within /lib/ld-2.3.5.so) ==28586== ==28586== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 3 from 1) ==28586== malloc/free: in use at exit: 0 bytes in 0 blocks. ==28586== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==28586== For counts of detected errors, rerun with: -v ==28586== No malloc'd blocks -- no leaks are possible. Ive searched the valgrind-users mailing lists, and have an active post about the same topic over in the Gentoo Programming forums. I tried recompiling gmp with -z noexecstack as suggested by one thread, but it didnt fix the problem. Any ideas? Thanks! ~Brian |
|
From: Martin H. <hi...@gm...> - 2006-01-03 21:37:03
|
This probably doesn't fix it for AMD64. It appears to work on IA32, though. Martin On 1/3/06, Keith Mange <km...@ex...> wrote: > Could this potentially fix bug 118293 on amd64: > > Bug 118239: vex amd64->IR: unhandled instruction bytes: 0xF 0xAE 0x3F > 0x48 (clflush) > > I think I'm using the latest code and I still see the problem on amd64. > > -Keith > > On Fri, 2005-12-30 at 17:42 -0600, Keith Mange wrote: > > > > -----Original Message----- > > From: val...@li... > > [mailto:val...@li...] On Behalf Of Martin > > Hirzel > > Sent: Friday, December 30, 2005 3:05 PM > > To: Julian Seward; val...@li... > > Subject: Re: [Valgrind-users] CLFLUSH on IA-32 > > > > I tried it with --smc-check=3Dall, now it works (doesn't crash or hang > > and produces reasonable-looking output). Not sure why it previously > > hung in the function with clflush, of all things, but as long as it > > works now, I'm happy. > > > > Thank you, > > Martin > > > > On 12/30/05, Martin Hirzel <hi...@gm...> wrote: > > > I didn't try with --smc-check=3Dall yet; I will do that. > > > > > > Thanks for re-looking at the clflush implementation. > > > > > > Thanks a lot for offering to look at this problem for me! > > > Unfortunately, I can't give you the JIT code or an ssh. Therefore, I > > > will try if I can isolate the problem. I'll try > > > --trace-flags=3D10000000; maybe, that sheds some more light. > > > > > > Martin > > > > > > On 12/30/05, Julian Seward <js...@ac...> wrote: > > > > > > > > Did you try with --smc-check=3Dall? That should take care of all > > > > self-modifying-code problems, even if the clflush implementation > > > > is broken. > > > > > > > > I just re-looked at the clflush implementation and there isn't > > > > anything _obviously_ wrong with it. (That doesn't mean it's right = :-) > > > > > > > > I'm happy to look at it (I want clflush to work properly) but that > > > > means I need to be able to reproduce it. At this stage you probabl= y > > have > > > > two options: either package up the sources of your jit so I can bui= ld > > > > it and reproduce the problem, or make an account on your system tha= t > > > > I can ssh to, set up a test framework, and I'll have a look. This > > > > second option is something I've done many times before. > > > > > > > > As a zeroth option, first do this: run your system with --tool=3Dno= ne > > > > --trace-flags=3D10000000. This will generate an unbelievable amoun= t > > > > of output. Capture it in a file. Find the BB in the file containi= ng > > > > the 'clflush' instruction and send it to me (or, if the .bz2 of it = is > > > > less than say 500k, just compress and send the whole thing). Since > > > > the system hangs when running on V, you'll need to control-C, but > > > > that shouldn't be a problem. > > > > > > > > J > > > > > > > > > > > > On Friday 30 December 2005 16:19, you wrote: > > > > > On 11/15/05, Julian Seward <js...@ac...> wrote: > > > > > > > I'm trying to run a JIT that uses CLFLUSH after code patching= to > > > > > > > > > > > > I just implemented it. svn up (you should get vex r1460, valgr= ind > > > > > > r5132), make distclean and rebuild everything from scratch (the= re > > have > > > > > > been several other changes too). Let us know if it works / doe= s not > > > > > > work. > > > > > > > > > > > > J > > > > > > > > > > Thank you so much for implementing this! Sorry it took me so long= to > > > > > get around to trying it. It looks like it hangs: I am running a h= ello > > > > > world program on top of my JIT, which in turn runs on top of nulg= rind. > > > > > Usually, this terminates in around 1 second, but with nulgrind, i= t is > > > > > still running after 10m. When I kill it (SIGINT), valgrind tells = me it > > > > > was currently in the JIT function with the CLFLUSH. > > > > > > > > > > Do you think your implementation of CLFLUSH in valgrind can hang = for > > > > > any reason? I am at a loss for what else could cause this behavio= r. > > > > > > > > > > Greetings, > > > > > Martin > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > |