You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(16) |
2
(22) |
3
(23) |
4
(12) |
5
(24) |
6
(28) |
7
(16) |
|
8
(3) |
9
(2) |
10
(9) |
11
(22) |
12
(19) |
13
(19) |
14
(15) |
|
15
(10) |
16
(23) |
17
(27) |
18
(31) |
19
(26) |
20
(19) |
21
(17) |
|
22
(6) |
23
(4) |
24
(3) |
25
(14) |
26
(1) |
27
(20) |
28
(14) |
|
29
(10) |
30
(26) |
|
|
|
|
|
|
From: Philippe W. <phi...@sk...> - 2013-09-23 18:53:04
|
On Mon, 2013-09-23 at 17:57 +0400, Timur Iskhodzhanov wrote: > Has this landed anywhere? No (not yet). The patch as it stands was discussed and found reasonable. However, it was deemed necessary to do a little bit more investigations about the absence of deadlocks e.g. when multiple threads try to exit in parallel. If time permits (and the resulting analysis shows absence of deadlock) it might land in 3.9.0. Philippe > > > 2013/8/16 Philippe Waroquiers <phi...@sk...> > On Tue, 2013-08-13 at 13:34 +0400, Alexander Potapenko wrote: > > (+timurrrr) > > For the record, another idea is to perform the leak checking > when the > > program is being terminated by an exit() call or right after > the > > return from main(). > > If I insert VALGRIND_DO_LEAK_CHECK right before "return 0" > in the > > above example, no leaks are reported, because the detached > threads are > > still live. > > Perhaps we shouldn't shut them down before checking for > leaks? > > > It is better to have only one thread remaining when doing > the leak search to e.g. avoid problems when running > the libc free resource (see valgrind option > --run-libc-freeres=no|yes). > > The attached patch solves the problem by having the exiting > thread > marking (using VgSrc_ExitProcess) the other threads which must > terminate due to the sys_exit_group syscall. > The exitreason VgSrc_ExitProcess is then used to detect that > the registers of an empty thread still have to be used for > leak > search. > Patch has been regression tested on linux x86, amd64 and > ppc64. > > Assuming the approach in the patch is deemed ok, there are > still a few > additional points to cleanup e.g. > the darwin equivalent code should be done > (would be nice to have an access to a darwin system for > that) > some obsolete comments about VgSrc_ExitProcess > confirming (or not) that a process can have threads of > multiple > thread group, and updating the code accordingly > > Philippe > > > |
|
From: Timur I. <tim...@go...> - 2013-09-23 13:58:26
|
Has this landed anywhere? 2013/8/16 Philippe Waroquiers <phi...@sk...> > On Tue, 2013-08-13 at 13:34 +0400, Alexander Potapenko wrote: > > (+timurrrr) > > For the record, another idea is to perform the leak checking when the > > program is being terminated by an exit() call or right after the > > return from main(). > > If I insert VALGRIND_DO_LEAK_CHECK right before "return 0" in the > > above example, no leaks are reported, because the detached threads are > > still live. > > Perhaps we shouldn't shut them down before checking for leaks? > > It is better to have only one thread remaining when doing > the leak search to e.g. avoid problems when running > the libc free resource (see valgrind option > --run-libc-freeres=no|yes). > > The attached patch solves the problem by having the exiting thread > marking (using VgSrc_ExitProcess) the other threads which must > terminate due to the sys_exit_group syscall. > The exitreason VgSrc_ExitProcess is then used to detect that > the registers of an empty thread still have to be used for leak > search. > Patch has been regression tested on linux x86, amd64 and ppc64. > > Assuming the approach in the patch is deemed ok, there are still a few > additional points to cleanup e.g. > the darwin equivalent code should be done > (would be nice to have an access to a darwin system for that) > some obsolete comments about VgSrc_ExitProcess > confirming (or not) that a process can have threads of multiple > thread group, and updating the code accordingly > > Philippe > > |
|
From: Yan <ya...@ya...> - 2013-09-23 07:10:24
|
Hey guys, It's me again. I just wrote about Python VEX bindings that I put up here: https://github.com/zardus/pyvex Although I originally wrote them for static analysis, one obvious idea with these bindings is to have some ability to write Valgrind tools in Python. Presumably, once a Python interpreter is embedded into Valgrind, pyvex can expose the IRSBs to a Python instrumentation function. I think this would be useful for quick prototyping, and analyses where flexibility of programming is more important than speed. Personally, I'd use it a bunch. Hopefully other people are interested :-) Of course, the challenge is embedding a python interpreter in Valgrind. I've been trying to do this for a few days (see the pygrind subdirectory in the pyvex module). I've tried the following approaches: 1. #including <Python.h>, initializing Python normally, and so forth. This is, I presume for good reason, a complete nightmare to get to link with the way Valgrind wants to link things. When I force all the various things to be linked (including the python interpreter, math library, crypto libraries, libc, etc, which I'm sure breaks tons of things), Valgrind can no longer load the tool, with the following message: valgrind: mmap(0x400000, 102400) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. 2. Using libdl to dlopen the Python interpreter on the fly and initialize it this way, in an attempt to avoid linking in tons of stuff. Unfortunately, libdl still relies on linking in libc, and Valgrind still fails with the error from #1. My next idea is to try to find a self-contained dlopen implementation, and see if I can make that work. Is anyone else interested in this sort of thing? Suggestions on how to actually do it? Thanks! - Yan |
|
From: Yan <ya...@ya...> - 2013-09-23 07:04:46
|
Hey guys, I've written up some python bindings for VEX, to be able to write analysis tools that reason about VEX IR in Python. I just GPL'ed them on github here: https://github.com/zardus/pyvex The bindings are used like, for example: import pyvex irsb = pyvex.IRSB(bytes="\x55\xc3") # translates "push ebp; ret" to VEX IR irsb.pp() # prints the VEX IR for s in irsb.statements(): if type(s) == pyvex.IRStmt.WrTmp: print "Temp %d being written:" % s.tmp s.data.pp() And various things like that. I wrote this to support some static analysis, so it has no working interface to Valgrind at the moment. I think this would be cool, but am not sure it's possible, and I'll start another thread about that. At any rate, if anyone's interested, I'd love to hear your comments, suggestions, and especially your pull requests. I think this could be useful for people doing analysis on this stuff. The code has plenty of issues (speed issues, implementation issues, you name it), which are documented in the README, and is a little heavy on macros because there are a lot of structs to interface to in VEX, but it seems to work :-) - Yan |