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
(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: Eric L. <ew...@an...> - 2006-06-08 19:15:58
|
> On Wednesday 07 June 2006 07:35, Eric Li wrote: >> What's the "dispatcher" at the end of VexTranslateArgs in 3.2.0 (but >> not 3.1.1) for? And what should go there in my case? I've read the >> comments but I'm still not clear on it. > > More or less irrelevant from an analysis point of view. It's where > execution (on the host) jumps to after the generated code is run, so that > the next block can be found/run. I'd set it to NULL. You won't see it in > the IR anyway. There are asserts in LibVEX_Translate (specifically the switch stmt where the arch is X86 or AMD64) that check that "dispatch" is not NULL. Can I just create a dummy function for it instead? Thanks, Eric |
|
From: Dennis L. <pla...@pr...> - 2006-06-08 13:01:13
|
*cries* Am Donnerstag, den 08.06.2006, 03:27 +0100 schrieb Julian Seward: > Please note that Helgrind is still not working. |
|
From: Stewart S. <st...@fl...> - 2006-06-08 05:07:58
|
On my system (Ubuntu 6.06) I don't seem to have qplatformdefs.h anywhere that the build process finds. CPPFLAGS=3D"-I/usr/share/qt3/mkspecs/linux-cxx/" ./configure makes it work. --=20 Stewart Smith (st...@fl...) http://www.flamingspork.com/ |
|
From: Julian S. <js...@ac...> - 2006-06-08 02:27:46
|
We are pleased to announce a new release of Valgrind, version 3.2.0, available from http://www.valgrind.org. Valgrind is an open-source suite of simulation based debugging and profiling tools. With the tools that come with Valgrind, you can automatically detect many memory management bugs, avoiding hours of frustrating bug-hunting, and make your code more stable. You can also perform detailed time and space profiling to help speed up and slim down your programs. 3.2.0 is a feature release with many significant improvements and the usual collection of bug fixes. This release supports X86/Linux, AMD64/Linux, PPC32/Linux and PPC64/Linux. Performance, especially of Memcheck, is improved, Addrcheck has been removed, Callgrind has been added, PPC64/Linux support has been added, Lackey has been improved, and MPI support has been added. In parallel with the 3.2.0 release, a new version (1.2.0) of the Valkyrie GUI is available from http://www.valgrind.org/downloads/current.html. There are many other refinements and bug fixes. See the attached release notes for details. Many thanks to all those who contribute to Valgrind's development. This release represents a great deal of time, energy and effort on the part of many people. Happy (and productive) debugging and profiling, -- The Valgrind Developers Release 3.2.0 (7 June 2006) ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.2.0 is a feature release with many significant improvements and the usual collection of bug fixes. This release supports X86/Linux, AMD64/Linux, PPC32/Linux and PPC64/Linux. Performance, especially of Memcheck, is improved, Addrcheck has been removed, Callgrind has been added, PPC64/Linux support has been added, Lackey has been improved, and MPI support has been added. In detail: - Memcheck has improved speed and reduced memory use. Run times are typically reduced by 15-30%, averaging about 24% for SPEC CPU2000. The other tools have smaller but noticeable speed improvments. We are interested to hear what improvements users get. Memcheck uses less memory due to the introduction of a compressed representation for shadow memory. The space overhead has been reduced by a factor of up to four, depending on program behaviour. This means you should be able to run programs that use more memory than before without hitting problems. - Addrcheck has been removed. It has not worked since version 2.4.0, and the speed and memory improvements to Memcheck make it redundant. If you liked using Addrcheck because it didn't give undefined value errors, you can use the new Memcheck option --undef-value-errors=no to get the same behaviour. - The number of undefined-value errors incorrectly reported by Memcheck has been reduced (such false reports were already very rare). In particular, efforts have been made to ensure Memcheck works really well with gcc 4.0/4.1-generated code on X86/Linux and AMD64/Linux. - Josef Weidendorfer's popular Callgrind tool has been added. Folding it in was a logical step given its popularity and usefulness, and makes it easier for us to ensure it works "out of the box" on all supported targets. The associated KDE KCachegrind GUI remains a separate project. - A new release of the Valkyrie GUI for Memcheck, version 1.2.0, accompanies this release. Improvements over previous releases include improved robustness, many refinements to the user interface, and use of a standard autoconf/automake build system. You can get it from http://www.valgrind.org/downloads/guis.html. - Valgrind now works on PPC64/Linux. As with the AMD64/Linux port, this supports programs using to 32G of address space. On 64-bit capable PPC64/Linux setups, you get a dual architecture build so that both 32-bit and 64-bit executables can be run. Linux on POWER5 is supported, and POWER4 is also believed to work. Both 32-bit and 64-bit DWARF2 is supported. This port is known to work well with both gcc-compiled and xlc/xlf-compiled code. - Floating point accuracy has been improved for PPC32/Linux. Specifically, the floating point rounding mode is observed on all FP arithmetic operations, and multiply-accumulate instructions are preserved by the compilation pipeline. This means you should get FP results which are bit-for-bit identical to a native run. These improvements are also present in the PPC64/Linux port. - Lackey, the example tool, has been improved: * It has a new option --detailed-counts (off by default) which causes it to print out a count of loads, stores and ALU operations done, and their sizes. * It has a new option --trace-mem (off by default) which causes it to print out a trace of all memory accesses performed by a program. It's a good starting point for building Valgrind tools that need to track memory accesses. Read the comments at the top of the file lackey/lk_main.c for details. * The original instrumentation (counting numbers of instructions, jumps, etc) is now controlled by a new option --basic-counts. It is on by default. - MPI support: partial support for debugging distributed applications using the MPI library specification has been added. Valgrind is aware of the memory state changes caused by a subset of the MPI functions, and will carefully check data passed to the (P)MPI_ interface. - A new flag, --error-exitcode=, has been added. This allows changing the exit code in runs where Valgrind reported errors, which is useful when using Valgrind as part of an automated test suite. - Various segfaults when reading old-style "stabs" debug information have been fixed. - A simple performance evaluation suite has been added. See perf/README and README_DEVELOPERS for details. There are various bells and whistles. - New configuration flags: --enable-only32bit --enable-only64bit By default, on 64 bit platforms (ppc64-linux, amd64-linux) the build system will attempt to build a Valgrind which supports both 32-bit and 64-bit executables. This may not be what you want, and you can override the default behaviour using these flags. Please note that Helgrind is still not working. We have made an important step towards making it work again, however, with the addition of function wrapping (see below). Other user-visible changes: - Valgrind now has the ability to intercept and wrap arbitrary functions. This is a preliminary step towards making Helgrind work again, and was required for MPI support. - There are some changes to Memcheck's client requests. Some of them have changed names: MAKE_NOACCESS --> MAKE_MEM_NOACCESS MAKE_WRITABLE --> MAKE_MEM_UNDEFINED MAKE_READABLE --> MAKE_MEM_DEFINED CHECK_WRITABLE --> CHECK_MEM_IS_ADDRESSABLE CHECK_READABLE --> CHECK_MEM_IS_DEFINED CHECK_DEFINED --> CHECK_VALUE_IS_DEFINED The reason for the change is that the old names are subtly misleading. The old names will still work, but they are deprecated and may be removed in a future release. We also added a new client request: MAKE_MEM_DEFINED_IF_ADDRESSABLE(a, len) which is like MAKE_MEM_DEFINED but only affects a byte if the byte is already addressable. - The way client requests are encoded in the instruction stream has changed. Unfortunately, this means 3.2.0 will not honour client requests compiled into binaries using headers from earlier versions of Valgrind. We will try to keep the client request encodings more stable in future. BUGS FIXED: 108258 NPTL pthread cleanup handlers not called 117290 valgrind is sigKILL'd on startup 117295 == 117290 118703 m_signals.c:1427 Assertion 'tst->status == VgTs_WaitSys' 118466 add %reg, %reg generates incorrect validity for bit 0 123210 New: strlen from ld-linux on amd64 123244 DWARF2 CFI reader: unhandled CFI instruction 0:18 123248 syscalls in glibc-2.4: openat, fstatat, symlinkat 123258 socketcall.recvmsg(msg.msg_iov[i] points to uninit 123535 mremap(new_addr) requires MREMAP_FIXED in 4th arg 123836 small typo in the doc 124029 ppc compile failed: `vor' gcc 3.3.5 124222 Segfault: @@don't know what type ':' is 124475 ppc32: crash (syscall?) timer_settime() 124499 amd64->IR: 0xF 0xE 0x48 0x85 (femms) 124528 FATAL: aspacem assertion failed: segment_is_sane 124697 vex x86->IR: 0xF 0x70 0xC9 0x0 (pshufw) 124892 vex x86->IR: 0xF3 0xAE (REPx SCASB) 126216 == 124892 124808 ppc32: sys_sched_getaffinity() not handled n-i-bz Very long stabs strings crash m_debuginfo n-i-bz amd64->IR: 0x66 0xF 0xF5 (pmaddwd) 125492 ppc32: support a bunch more syscalls 121617 ppc32/64: coredumping gives assertion failure 121814 Coregrind return error as exitcode patch 126517 == 121814 125607 amd64->IR: 0x66 0xF 0xA3 0x2 (btw etc) 125651 amd64->IR: 0xF8 0x49 0xFF 0xE3 (clc?) 126253 x86 movx is wrong 126451 3.2 SVN doesn't work on ppc32 CPU's without FPU 126217 increase # threads 126243 vex x86->IR: popw mem 126583 amd64->IR: 0x48 0xF 0xA4 0xC2 (shld $1,%rax,%rdx) 126668 amd64->IR: 0x1C 0xFF (sbb $0xff,%al) 126696 support for CDROMREADRAW ioctl and CDROMREADTOCENTRY fix 126722 assertion: segment_is_sane at m_aspacemgr/aspacemgr.c:1624 126938 bad checking for syscalls linkat, renameat, symlinkat (3.2.0RC1: 27 May 2006, vex r1626, valgrind r5947). (3.2.0: 7 June 2006, vex r1628, valgrind r5957). |
|
From: Eric L. <ew...@an...> - 2006-06-07 18:11:29
|
> I guess one kludge is: if you want to vexify a block which you know > contains N instructions, you can initialise vex and set > VexControl.guest_max_insns to N (along with setting .guest_chase_thresh to > zero). Then it should stop after N insns even if it thinks it could go > further. If I want to Vexity an array of BB's, each with a diff number of instructions, in a loop, do I have to call LibVEX_Init every iteration after setting the guest_max_insns of the VexControl argument for the current BB? Or can I just modify the VexControl struct only and VEX would pick it up? Are there any undesired side effects to calling LibVEX_Init multiple times? Thanks, Eric |
|
From: Julian S. <js...@ac...> - 2006-06-07 11:52:15
|
On Wednesday 07 June 2006 07:35, Eric Li wrote: > What's the "dispatcher" at the end of VexTranslateArgs in 3.2.0 (but not > 3.1.1) for? And what should go there in my case? I've read the comments but > I'm still not clear on it. More or less irrelevant from an analysis point of view. It's where execution (on the host) jumps to after the generated code is run, so that the next block can be found/run. I'd set it to NULL. You won't see it in the IR anyway. J |
|
From: Eric L. <ew...@an...> - 2006-06-07 06:35:27
|
What's the "dispatcher" at the end of VexTranslateArgs in 3.2.0 (but not 3.1.1) for? And what should go there in my case? I've read the comments but I'm still not clear on it. Thanks, Eric |
|
From: Julian S. <js...@ac...> - 2006-06-06 22:58:41
|
On Tuesday 06 June 2006 23:51, Eric Li wrote: > > You have two main problems. One is you need to make vex not chase over > > bb boundaries. You can do this by using a VexControl struct with > > guest_chase_thresh set to zero (you have to supply this struct at some > > point, I can't remember where). > > What if I just created a dummy chase_into_ok function that always returned > false and passed that into LibVEX_Translate? Would that work? Yes, although it seems pointless since you have to supply a VexControl struct at some point anyway. It wouldn't solve the problem of ensuring that vex disassembles the right number of instructions though. For that you do need the other kludge I mentioned. J |
|
From: Eric L. <ew...@an...> - 2006-06-06 22:51:30
|
> You have two main problems. One is you need to make vex not chase over bb > boundaries. You can do this by using a VexControl struct with > guest_chase_thresh set to zero (you have to supply this struct at some > point, I can't remember where). What if I just created a dummy chase_into_ok function that always returned false and passed that into LibVEX_Translate? Would that work? |
|
From: Julian S. <js...@ac...> - 2006-06-06 22:40:43
|
One other thing -- if it hasn't been pointed out already -- is to make friends with the Valgrind flag combination --tool=none --trace-flags=10000000 --trace-notbelow=0 (also --trace-flags=10001000). I always find that seeing the IR printed out nicely makes it much easier to understand what's going on. J |
|
From: Julian S. <js...@ac...> - 2006-06-06 22:34:40
|
> It seems like the 6th and 7th arguments to LibVEX_Translate, Don't use the 3.1.1 vex; use the one in the 3.2.0 release candidate (http://www.valgrind.org/downloads/valgrind-3.2.0rc1.tar.bz2). All these zillions of parameters got put in a struct, which is a lot cleaner. guest_bytes point at the actual insn bytes to read. guest_bytes_addr, as you say, is where we claim those bytes are in the guest process address space. You can put what you like there; I guess it depends on whether or not you care about the address relationship between different basic blocks or not. guest_bytes_addr_noredir, or whatever, is gone. All that ugly redirection crap is handled entirely on the valgrind side now. You have two main problems. One is you need to make vex not chase over bb boundaries. You can do this by using a VexControl struct with guest_chase_thresh set to zero (you have to supply this struct at some point, I can't remember where). If you do that then if you're lucky vex will not try and disassemble beyond the blocks of code you give it. But that's fragile since it relies on vex's decision about the end of a bb matching that from your own disassembler. I guess one kludge is: if you want to vexify a block which you know contains N instructions, you can initialise vex and set VexControl.guest_max_insns to N (along with setting .guest_chase_thresh to zero). Then it should stop after N insns even if it thinks it could go further. Does that make any sense at all? J |
|
From: Eric L. <ew...@an...> - 2006-06-06 22:17:20
|
Oh, I forgot to mention that I'm doing all this translation statically. So my program currently takes in the name of the executable that I want to examine, then does all the disassembly, translation, and analysis. It seems like the 6th and 7th arguments to LibVEX_Translate, guset_bytes_addr and guest_bytes_addr_noredir, have to do with where in the process's addr space the BB is loaded into? But my binary has no process because it's not running so what should I fill in for those? Thanks again, Eric > On Mon, 5 Jun 2006, Eric Li wrote: > >>> What are you really trying to achieve? >> >> I'm working on a research project that generates vulnerability >> signatures (signatures that let you detect exploits and all their >> polymorphic variations in a binary). The framework translates from BB to >> IR to GCL to WP(weakest preconditions) and we were hoping to replace our >> IR with the one in Valgrind because it's more mature. > > How do you go from BB to IR? Something must be identifying the BBs. > Couldn't you keep that and then pass its output to Vex? > > Nick > > > |
|
From: Josef W. <Jos...@gm...> - 2006-06-06 21:54:26
|
On Tuesday 06 June 2006 23:28, Haizhu Liu wrote: > Hello, > > Can someone explain to me the first stack frames as below, the second to > last frame is _dl_init, and then call_init, and then the > /opt/hsc/lib/libtrace.so, that means dl_init calls call_init and then > call_init calls something in /opt/hsc/lib/libtrace.so? That does not look > right since /opt/hsc/lib/libtrace.so is not standard library. It seems correct to me. /opt/hsc/lib/libtrace.so is a shared library linked with your binary; the runtime linker first loads all shared libs, and calls an initialization function of every shared lib before main() is run. In the initialization functions, e.g. constructors for global C++ objects are called, as is done in your case, too. Josef |
|
From: Julian S. <js...@ac...> - 2006-06-06 21:38:29
|
> Can someone explain to me the first stack frames as below, the second to I agree with Brian Crowder's analysis - you are running global constructors, and your program has not yet started main(). > >From: Brian Crowder <cr...@fi...> > > > >You're not in main() here, you're calling a CTOR on a globally declared > >std::deque, _dl_init IS the very first frame of the stack, there are no > >more beyond it. J |
|
From: Haizhu L. <hai...@ho...> - 2006-06-06 21:29:05
|
Hello, Can someone explain to me the first stack frames as below, the second to last frame is _dl_init, and then call_init, and then the /opt/hsc/lib/libtrace.so, that means dl_init calls call_init and then call_init calls something in /opt/hsc/lib/libtrace.so? That does not look right since /opt/hsc/lib/libtrace.so is not standard library. >>Example back traces: >> >>==3714== 218,712 bytes in 36 blocks are possibly lost in loss record 26 of >>26 >>==3714== at 0x401C9DC: operator new(unsigned) (in >>/usr/lib/valgrind/x86-linux/vgprelo >>ad_memcheck.so) >>==3714== by 0x4243689: (within /usr/lib/libstdc++.so.5.0.6) >>==3714== by 0x42433C0: std::__default_alloc_template<true, >>0>::_S_chunk_alloc(unsigne >>d, int&) (in /usr/lib/libstdc++.so.5.0.6) >>==3714== by 0x4243200: std::__default_alloc_template<true, >>0>::_S_refill(unsigned) (i >>n /usr/lib/libstdc++.so.5.0.6) >>==3714== by 0x402C0B2: std::_Deque_base<trace_rec_t, >>std::allocator<trace_rec_t> >::_ >>M_initialize_map(unsigned) (bits/stl_alloc.h:349) >>==3714== by 0x402B8C5: __static_initialization_and_destruction_0(int, >>int) (bits/stl_ >>deque.h:430) >>==3714== by 0x402BE1D: _GLOBAL__I_MAKE_DAEMON (bits/stl_queue.h:89) >>==3714== by 0x402F5E4: (within /opt/hsc/lib/libtrace.so) >>==3714== by 0x4028128: (within /opt/hsc/lib/libtrace.so) >>==3714== by 0x400D44B: call_init (in /lib/ld-2.3.3.so) >>==3714== by 0x400D531: _dl_init (in /lib/ld-2.3.3.so) >>==3714== by 0x40009C4: (within /lib/ld-2.3.3.so) >From: Brian Crowder <cr...@fi...> >CC: val...@li... >Subject: Re: [Valgrind-users] can num-callers be larger than 12 with >valgrind 3.1.1 >Date: Thu, 01 Jun 2006 13:36:51 -0700 > > >You're not in main() here, you're calling a CTOR on a globally declared >std::deque, _dl_init IS the very first frame of the stack, there are no >more beyond it. > >-- Brian > >Haizhu Liu wrote: >>Hello, >> >>Example back traces: >> >>==3714== 218,712 bytes in 36 blocks are possibly lost in loss record 26 of >>26 >>==3714== at 0x401C9DC: operator new(unsigned) (in >>/usr/lib/valgrind/x86-linux/vgprelo >>ad_memcheck.so) >>==3714== by 0x4243689: (within /usr/lib/libstdc++.so.5.0.6) >>==3714== by 0x42433C0: std::__default_alloc_template<true, >>0>::_S_chunk_alloc(unsigne >>d, int&) (in /usr/lib/libstdc++.so.5.0.6) >>==3714== by 0x4243200: std::__default_alloc_template<true, >>0>::_S_refill(unsigned) (i >>n /usr/lib/libstdc++.so.5.0.6) >>==3714== by 0x402C0B2: std::_Deque_base<trace_rec_t, >>std::allocator<trace_rec_t> >::_ >>M_initialize_map(unsigned) (bits/stl_alloc.h:349) >>==3714== by 0x402B8C5: __static_initialization_and_destruction_0(int, >>int) (bits/stl_ >>deque.h:430) >>==3714== by 0x402BE1D: _GLOBAL__I_MAKE_DAEMON (bits/stl_queue.h:89) >>==3714== by 0x402F5E4: (within /opt/hsc/lib/libtrace.so) >>==3714== by 0x4028128: (within /opt/hsc/lib/libtrace.so) >>==3714== by 0x400D44B: call_init (in /lib/ld-2.3.3.so) >>==3714== by 0x400D531: _dl_init (in /lib/ld-2.3.3.so) >>==3714== by 0x40009C4: (within /lib/ld-2.3.3.so) >> >>I ran valgrind on interl i686, and I ran valgrind with -v option, >> >>--3714-- Reading syms from /usr/ld-2.3.3.so (0x4000000) >>--3714-- Reading syms from /opt/hsc/bin/ibnmsmd (0x8048000) >>--3714-- Reading syms from /usr/lib/valgrind/x86-linux/memcheck >>(0xB0000000) >>--3714-- object doesn't have a symbol table >>--3714-- object doesn't have a dynamic symbol table >>--3714-- Reading suppressions file: /usr/lib/valgrind/default.supp >>--3714-- REDIR: 0x40129B0 (index) redirected to 0xB0021532 (???) >>--3714-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_core.so >>(0x4018000) >>--3714-- object doesn't have a symbol table >>--3714-- Reading syms from >>/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x401A000) >>--3714-- object doesn't have a symbol table >>--3714-- REDIR: 0x4012B50 (strlen) redirected to 0x401CFD0 (strlen) >>--3714-- Reading syms from /opt/hsc/lib/libtrace.so (0x4025000) >>--3714-- Reading syms from /lib/tls/libpthread.so.0 (0x4033000) >>--3714-- Reading syms from /usr/lib/libnetsnmp.so.5.1.0 (0x4043000) >>--3714-- Reading syms from /usr/lib/libcrypto.so.0.9.6 (0x40C7000) >>--3714-- Reading syms from /usr/lib/libstdc++.so.5.0.6 (0x41B8000) >>--3714-- object doesn't have a symbol table >>--3714-- Reading syms from /lib/tls/libm.so.6 (0x4289000) >>--3714-- Reading syms from /lib/tls/libc.so.6 (0x42AB000 >>-3714-- object doesn't have a symbol table >> >>>From: Julian Seward <js...@ac...> >>>To: val...@li... >>>Subject: Re: [Valgrind-users] can num-callers be larger than 12 with >>>valgrind 3.1.1 >>>Date: Thu, 1 Jun 2006 16:39:34 +0100 >>> >>>On Thursday 01 June 2006 16:26, Haizhu Liu wrote: >>> > Hello, >>> > >>> > I tried to use the num-callers option to be larger than 12, but it >>>does not >>> > seem to give me more than that many frames. Is 12 the maximum? >>> >>>No, the max is 50 or 100 or some crazy number like that. >>> >>>Can you send some examples of the backtraces you are getting? >>> >>>What platform (cpu) are you using? >>> >>>If you run with -v do you get any warnings immediately following >>>the lines "Reading syms from ..." ? >>> >>>J >>> >>> >>>------------------------------------------------------- >>>All the advantages of Linux Managed Hosting--Without the Cost and Risk! >>>Fully trained technicians. The highest number of Red Hat certifications >>>in >>>the hosting industry. Fanatical Support. Click to learn more >>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 >>>_______________________________________________ >>>Valgrind-users mailing list >>>Val...@li... >>>https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> >> >> >> >>------------------------------------------------------- >>All the advantages of Linux Managed Hosting--Without the Cost and Risk! >>Fully trained technicians. The highest number of Red Hat certifications in >>the hosting industry. Fanatical Support. Click to learn more >>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 >>_______________________________________________ >>Valgrind-users mailing list >>Val...@li... >>https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> >> > > >------------------------------------------------------- >All the advantages of Linux Managed Hosting--Without the Cost and Risk! >Fully trained technicians. The highest number of Red Hat certifications in >the hosting industry. Fanatical Support. Click to learn more >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 >_______________________________________________ >Valgrind-users mailing list >Val...@li... >https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Tom H. <to...@co...> - 2006-06-06 18:18:32
|
In message <ef8...@ny...>
cn...@ny... wrote:
> > In message <f07...@ny...>
> > cn...@ny... wrote:
> >
> > > I'm trying to cross-compile Valgrind v3.1.1 (March 15, 2006) on
> > > x86 for PPC. The TLS test failed but I added --disable-tls to
> > > my config script. But when I try to build memcheck, I get an
> > > unresolved external,> __builtin_expect. In message
> > > http://sourceforge.net/mailarchive/message.php?msg_id=14232995, I
> > > see that this seems to have been fixed in December so I don't quite
> > > understand why the fix isn't in v3.1.1. I've modified my
> > > mc_mail.c to have the #ELSE part of the fix described above but
> > > I'd rather not continue that way. The bug database is down right
> > > now so I can't research it very far. What's up?
> >
> > Well that commit was on the trunk so unless somebody merged it to
> > the 3_1 branch it won't have been in the 3.1.1 release.
>
> OK. That makes sense as far as it goes. But when I looked for source
> to download, and all I saw was v3.1.1, I kind of figured it was
> latest-and-greatest and would include a 3-month-old patch. <shrug> Is
> there another source tar ball I should have found?
Yes, of course it should have been in 3.1.1 but it obviously got
overlooked, probably because there was never a bug for it so it
never got entered in the bug status file so it didn't get considered
for merging before the release.
There is a 3.2.0 release candidate tar ball around - it was announced
on the list last week. That will have the fix.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <cn...@ny...> - 2006-06-06 18:12:51
|
> In message <f07...@ny...> > cn...@ny... wrote: > > > I'm trying to cross-compile Valgrind v3.1.1 (March 15, 2006) on > > x86 for PPC. The TLS test failed but I added --disable-tls to > > my config script. But when I try to build memcheck, I get an > > unresolved external,> __builtin_expect. In message > > http://sourceforge.net/mailarchive/message.php?msg_id=14232995, I > > see that this seems to have been fixed in December so I don't quite > > understand why the fix isn't in v3.1.1. I've modified my > > mc_mail.c to have the #ELSE part of the fix described above but > > I'd rather not continue that way. The bug database is down right > > now so I can't research it very far. What's up? > > Well that commit was on the trunk so unless somebody merged it to > the 3_1 branch it won't have been in the 3.1.1 release. OK. That makes sense as far as it goes. But when I looked for source to download, and all I saw was v3.1.1, I kind of figured it was latest-and-greatest and would include a 3-month-old patch. <shrug> Is there another source tar ball I should have found? |
|
From: Tom H. <to...@co...> - 2006-06-06 17:59:11
|
In message <f07...@ny...>
cn...@ny... wrote:
> I'm trying to cross-compile Valgrind v3.1.1 (March 15, 2006) on x86 for
> PPC. The TLS test failed but I added --disable-tls to my config script.
> But when I try to build memcheck, I get an unresolved external,
> __builtin_expect. In message
> http://sourceforge.net/mailarchive/message.php?msg_id=14232995, I see
> that this seems to have been fixed in December so I don't quite
> understand why the fix isn't in v3.1.1. I've modified my mc_mail.c to
> have the #ELSE part of the fix described above but I'd rather not
> continue that way. The bug database is down right now so I can't
> research it very far. What's up?
Well that commit was on the trunk so unless somebody merged it to
the 3_1 branch it won't have been in the 3.1.1 release.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Eric L. <ew...@an...> - 2006-06-06 17:43:38
|
Right now, my existing code gives me pointers to the start and end of a BB and I want to use LibVEX_Translate to process it. In LibVEX_Translate, is the "guest_bytes" argument a pointer to the start of the BB I want to translate? What are "guest_bytes_addr" and "guest_bytes_addr_noredir" for? And how do I specify the length (or the end) of the block I want to translate? Thanks, Eric > On Mon, 5 Jun 2006, Eric Li wrote: > >>> What are you really trying to achieve? >> >> I'm working on a research project that generates vulnerability >> signatures (signatures that let you detect exploits and all their >> polymorphic variations in a binary). The framework translates from BB to >> IR to GCL to WP(weakest preconditions) and we were hoping to replace our >> IR with the one in Valgrind because it's more mature. > > How do you go from BB to IR? Something must be identifying the BBs. > Couldn't you keep that and then pass its output to Vex? > > Nick > > > |
|
From: <cn...@ny...> - 2006-06-06 16:24:48
|
I'm trying to cross-compile Valgrind v3.1.1 (March 15, 2006) on x86 for PPC. The TLS test failed but I added --disable-tls to my config script. But when I try to build memcheck, I get an unresolved external, __builtin_expect. In message http://sourceforge.net/mailarchive/message.php?msg_id=14232995, I see that this seems to have been fixed in December so I don't quite understand why the fix isn't in v3.1.1. I've modified my mc_mail.c to have the #ELSE part of the fix described above but I'd rather not continue that way. The bug database is down right now so I can't research it very far. What's up? Chris |
|
From: Josef W. <Jos...@gm...> - 2006-06-06 13:59:38
|
On Monday 05 June 2006 20:56, Eric Li wrote:
> Is there a module that parses binaries to BB's that I can use?
I once did a Valgrind tool (for 2.x) to get static infos about binaries.
The first time an ELF object was touched, I iterated over the code segment
space [start;end[ like this, ignoring code without debug info:
...
addr = start;
while(addr < end) {
/* search for address with line debug info */
while(addr < end) {
if (VG_(get_filename_linenum)(addr, filename, FILENAME_LEN, &line))
break;
addr++;
}
if (addr == end) break;
/* this always should be inside of a function */
if (!VG_(get_fnname)(addr, fn_name, FN_NAME_LEN)) { addr++; continue; }
/* decode a basic block */
bb_addr = addr;
cb = VG_(alloc_UCodeBlock)();
cb->orig_eip = addr;
size = VG_(disBB)(cb, addr);
if (size <=0) {
/* skip on error: not decodable? */
VG_(free_UCodeBlock)(cb);
continue;
}
...
I am not sure if VEX has an API similar to VG_(alloc_UCodeBlock)() and
VG_(disBB)(cb, addr) of VG 2.x.
Note that the above was still a hack, as the UCode block structure returned
by VG_(disBB) was officially not visible to tools, so I copied the definition
into the tool.
Above code would be useful for a code coverage tool: callgrind/cachegrind
optionally could include information about code which never was executed.
A postprocessing tool could say: "In this library, only 80% of code which
has debug info was touched."
This currently is impossible.
Josef
|
|
From: Eric L. <ew...@an...> - 2006-06-06 03:49:53
|
> On Mon, 5 Jun 2006, Eric Li wrote: > >>> What are you really trying to achieve? >> >> I'm working on a research project that generates vulnerability >> signatures (signatures that let you detect exploits and all their >> polymorphic variations in a binary). The framework translates from BB to >> IR to GCL to WP(weakest preconditions) and we were hoping to replace our >> IR with the one in Valgrind because it's more mature. > > How do you go from BB to IR? Something must be identifying the BBs. > Couldn't you keep that and then pass its output to Vex? > Yea, that's what I'm planning to do. But at first we wanted to try to replace as much of the binary to IR stuff with Valgrind as we can since Valgrind's code is more complete and mature. > Nick > > > |
|
From: Nicholas N. <nj...@cs...> - 2006-06-06 02:05:52
|
On Mon, 5 Jun 2006, Eric Li wrote: >> What are you really trying to achieve? > > I'm working on a research project that generates vulnerability signatures > (signatures that let you detect exploits and all their polymorphic > variations in a binary). The framework translates from BB to IR to GCL to > WP(weakest preconditions) and we were hoping to replace our IR with the > one in Valgrind because it's more mature. How do you go from BB to IR? Something must be identifying the BBs. Couldn't you keep that and then pass its output to Vex? Nick |
|
From: Eric L. <ew...@an...> - 2006-06-06 01:12:28
|
>> 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? > > No. This is somewhere between very difficult and impossible; in the most > general case distinguishing code from data is equivalent to solving the > halting problem I believe. Valgrind carefully avoids this by translating > code on demand. OK, well, at least now I know not to bother trying. > > What are you really trying to achieve? I'm working on a research project that generates vulnerability signatures (signatures that let you detect exploits and all their polymorphic variations in a binary). The framework translates from BB to IR to GCL to WP(weakest preconditions) and we were hoping to replace our IR with the one in Valgrind because it's more mature. > > J > > |
|
From: Julian S. <js...@ac...> - 2006-06-05 22:40:11
|
> 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? No. This is somewhere between very difficult and impossible; in the most general case distinguishing code from data is equivalent to solving the halting problem I believe. Valgrind carefully avoids this by translating code on demand. What are you really trying to achieve? J |