You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
1
|
2
(2) |
3
|
4
|
|
5
(2) |
6
|
7
|
8
(3) |
9
|
10
|
11
|
|
12
|
13
(4) |
14
(3) |
15
|
16
(4) |
17
(1) |
18
(1) |
|
19
|
20
(1) |
21
(1) |
22
(1) |
23
(1) |
24
|
25
|
|
26
|
27
(1) |
28
|
29
|
30
(8) |
31
|
|
|
From: Philippe W. <phi...@sk...> - 2013-05-16 20:47:25
|
On Thu, 2013-05-16 at 22:14 +0200, Roland Mainz wrote: > On Thu, May 16, 2013 at 9:13 PM, Philippe Waroquiers > > However, the impact of this part is not as easy. > > I know... I studied the valgrind code in the meantime and started to > gnaw my fingernails off... ;-/ > > > This implies to change the basic way the malloc interception is done, > > by adding an additional "grouping" parameter, and store this in each > > memory "chunk" managed by memcheck. > > More impact on memory, and on the interface between the core and > > the tools replacing the malloc, and a lot more difficult to make > > "generic". > > I suspect this will imply also some possibly heavy changes to > > the "core" redirection logic. > > Right... but some day it needs to be done... ;-/ > ... for AFAIK (at least) two reasons: For sure, the below are valid reasons. But there is a balance between the additional complexity/cpu/memory in Valgrind versus the possible use. Valgrind already provides client requests which allows to instrument "mempool" libraries to have (some) support of bug detection by memcheck. Note that this support provides less bug detection capabilities than the replacement of the "standard" malloc/free/... but it looks unclear to me how to e.g. properly add redzone, freelist, etc to mempools. So, it looks unlikely to me that the mempool support can be made much better than what is provided by the *MEMPOOL* client requests in valgrind.h include file. For what concerns mixing chicken malloc and pterodactylus free: interesting functionality, but again IMO, the balance cost/benefit is not clear. The balance cost/benefit of a generalised --soname-synonyms looks however better to me. I might take the time to look at this. This would allow any redirection (e.g. the pthread redirections for helgrind or drd) to have synonyms, allowing e.g. these tools to work with static libraries. Philippe |
|
From: Roland M. <rol...@nr...> - 2013-05-16 20:14:35
|
On Thu, May 16, 2013 at 9:13 PM, Philippe Waroquiers
<phi...@sk...> wrote:
> On Tue, 2013-05-14 at 04:28 +0200, Roland Mainz wrote:
>> On Thu, Apr 25, 2013 at 1:42 PM, Sebastian Feld
>> <seb...@gm...> wrote:
>> > On Wed, Apr 24, 2013 at 11:10 PM, Roland Mainz <rol...@nr...> wrote:
>> >> On Wed, Apr 24, 2013 at 10:14 PM, Roland Mainz <rol...@nr...> wrote:
>> >>> On Wed, Apr 24, 2013 at 12:45 AM, John Reiser <jr...@bi...> wrote:
>
>> >> $ valgrind "--allocator-sym-redirect=sh_malloc=malloc,sh_free=free,sh_calloc=calloc"
>> >> ... # would instruct valgrind to take function |sh_malloc()| as an
>> >> alternative |malloc(), |sh_free()| as alternative |free()| version
>> >> etc. etc.
>> >>
>> >> The only issue is that if multiple allocators are active within a
>> >> single process we may need some kind of "grouping" to explain valgrind
>> >> that memory allocated by |sh_malloc()| can not be freed by |tcfree()|
>> >> or |_ast_free()| ... maybe it could be done using '{'- and '}'-pairs,
>> >> e.g. $ valgrind
>> >> "--allocator-sym-redirect={sh_malloc=malloc,sh_free=free,sh_calloc=calloc},{_ast_malloc=malloc,_ast_free=free,_ast_calloc=calloc}"
>> >> ... #
>> >
>> > The idea of (finally!) providing such an option sounds like a very
>> > good idea. Until now the only way to probe python and bash4 via
>> > valgrind is to poke in the valgrind sources (which should never
>> > happen).
> I think it would not be very difficult to extend the command line option
> --soname-synonyms=syn1=pattern1,syn2=pattern2,... synonym soname
> specify patterns for function wrapping or replacement.
> To use a non-libc malloc library that is
> in the main exe: --soname-synonyms=somalloc=NONE
> in libxyzzy.so: --soname-synonyms=somalloc=libxyzzy.so
> to support also to give synonym for the "function" part of a redirection.
> Now that I understand better all this area, it should be relatively
> easy to allow to give synonyms for any (existing) redirection
> (library part or function part).
> In other words, to make -soname-synonyms "generic".
That would be helpfull (in our case it's the AST toolkit which has
it's own utility library called libast.so.1 and to avoid namespace
collisions on old operating systems many functions (including their
|malloc()| version) are prefixed with |_ast|, e.g. |_ast_malloc()|,
|_ast_free()| etc. on demand.
>> > I also think the idea to let valgrind detect mixing of different
>> > allocators is a very valuable feature since this has been a source of
>> > more and more bugs. Usually happens in complex projects with use many
>> > different shared libraries, all with their own memory allocators.
>
> However, the impact of this part is not as easy.
I know... I studied the valgrind code in the meantime and started to
gnaw my fingernails off... ;-/
> This implies to change the basic way the malloc interception is done,
> by adding an additional "grouping" parameter, and store this in each
> memory "chunk" managed by memcheck.
> More impact on memory, and on the interface between the core and
> the tools replacing the malloc, and a lot more difficult to make
> "generic".
> I suspect this will imply also some possibly heavy changes to
> the "core" redirection logic.
Right... but some day it needs to be done... ;-/
... for AFAIK (at least) two reasons:
1. Big applications depending on many utility libraries sooner or
later hit the issue of having multiple |malloc()| versions. For
passing a pointer obtained from |_chicken_malloc()| to
|_pterodactylus_free()| is likely causing some very interesting
trouble if the process doesn't get a SIGSEGV/SIGBUS walloped over the
head on the first try... ;-/
2. Some memory allocators (for example used by commercial C++
libraries... or take a look at Sun/Oracle is doing for the VM2 project
in Solaris 11.1/12) allow "pools" of memory (e.g. you create a pool
and then use the pool as argument to a |malloc()|-like function) where
from each pool memory can be allocated independently (this is usually
done to boost performance (for example each thread owns it's own pool
and doesn't have to use atomic operations unless new "backing store"
needs to be obtained), fight fragmentation, make
dealloc_everything_from_this_pool-in-one-go easier/faster etc.).
Beyond the usual trouble some implementations allow nesting of pools,
e.g. one pool provides the "backing store" for a couple of sub-pools
etc. (for example there is a "global" pool which is thread-safe and
the threads maintain their own pools (without the need for atomic
operations) and use the global pool to obtain the memory)
>> Uhm... was there any feedback yet for that idea ?
>
> Some feedback above :).
Thanks... :-)
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) rol...@nr...
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
|
|
From: Philippe W. <phi...@sk...> - 2013-05-16 19:13:24
|
On Tue, 2013-05-14 at 04:28 +0200, Roland Mainz wrote:
> On Thu, Apr 25, 2013 at 1:42 PM, Sebastian Feld
> <seb...@gm...> wrote:
> > On Wed, Apr 24, 2013 at 11:10 PM, Roland Mainz <rol...@nr...> wrote:
> >> On Wed, Apr 24, 2013 at 10:14 PM, Roland Mainz <rol...@nr...> wrote:
> >>> On Wed, Apr 24, 2013 at 12:45 AM, John Reiser <jr...@bi...> wrote:
> >> $ valgrind "--allocator-sym-redirect=sh_malloc=malloc,sh_free=free,sh_calloc=calloc"
> >> ... # would instruct valgrind to take function |sh_malloc()| as an
> >> alternative |malloc(), |sh_free()| as alternative |free()| version
> >> etc. etc.
> >>
> >> The only issue is that if multiple allocators are active within a
> >> single process we may need some kind of "grouping" to explain valgrind
> >> that memory allocated by |sh_malloc()| can not be freed by |tcfree()|
> >> or |_ast_free()| ... maybe it could be done using '{'- and '}'-pairs,
> >> e.g. $ valgrind
> >> "--allocator-sym-redirect={sh_malloc=malloc,sh_free=free,sh_calloc=calloc},{_ast_malloc=malloc,_ast_free=free,_ast_calloc=calloc}"
> >> ... #
> >
> > The idea of (finally!) providing such an option sounds like a very
> > good idea. Until now the only way to probe python and bash4 via
> > valgrind is to poke in the valgrind sources (which should never
> > happen).
I think it would not be very difficult to extend the command line option
--soname-synonyms=syn1=pattern1,syn2=pattern2,... synonym soname
specify patterns for function wrapping or replacement.
To use a non-libc malloc library that is
in the main exe: --soname-synonyms=somalloc=NONE
in libxyzzy.so: --soname-synonyms=somalloc=libxyzzy.so
to support also to give synonym for the "function" part of a redirection.
Now that I understand better all this area, it should be relatively
easy to allow to give synonyms for any (existing) redirection
(library part or function part).
In other words, to make -soname-synonyms "generic".
> >
> > I also think the idea to let valgrind detect mixing of different
> > allocators is a very valuable feature since this has been a source of
> > more and more bugs. Usually happens in complex projects with use many
> > different shared libraries, all with their own memory allocators.
However, the impact of this part is not as easy.
This implies to change the basic way the malloc interception is done,
by adding an additional "grouping" parameter, and store this in each
memory "chunk" managed by memcheck.
More impact on memory, and on the interface between the core and
the tools replacing the malloc, and a lot more difficult to make
"generic".
I suspect this will imply also some possibly heavy changes to
the "core" redirection logic.
> Uhm... was there any feedback yet for that idea ?
Some feedback above :).
Philippe
|
|
From: David F. <fa...@kd...> - 2013-05-16 18:29:38
|
On Tuesday 14 May 2013 20:18:44 Phil Longstaff wrote: > int* my_ptr = new int; > *my_ptr = 10; > pthread_mutex_lock(&lock); > shared_ptr = my_ptr; > pthread_mutex_unlock(&lock); > > Thread 2: > pthread_mutex_lock(&lock); > int* my_ptr = shared_ptr; > pthread_mutex_unlock(&lock); > ... = *my_ptr; You're reading a region of memory outside mutex protection, and that region of memory was written to, outside mutex protection. That's the basic definition of a data race. Getting the address of that region of memory within the mutex doesn't change that. You see it as non-racy because "how could *my_ptr ever be something else than 10" ... but if you think about a multi-processor system, the write of the value 10 might not get propagated to the cache of the other processor where the read happens, since the system had no reason to perform that synchronisation. -- David Faure, fa...@kd..., http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 |