You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(6) |
2
(16) |
3
(3) |
4
(11) |
5
(2) |
|
6
(4) |
7
(11) |
8
(4) |
9
(6) |
10
(25) |
11
(10) |
12
(1) |
|
13
(2) |
14
(6) |
15
(16) |
16
(19) |
17
(16) |
18
(5) |
19
|
|
20
(4) |
21
(5) |
22
(21) |
23
(4) |
24
(14) |
25
(3) |
26
(9) |
|
27
(3) |
28
(13) |
29
(6) |
30
(16) |
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-14 17:33:56
|
On Mon, 14 Apr 2003, Mathieu Malaterre wrote:
> 1. I would like to know where the 'KLUDGED call' happens in my soft, is
> it possible to trace it or print the call tree ?
Does your code call pthread_cond_destroy anywhere?
These options may be useful:
--trace-sched=no|yes show thread scheduler details? [no]
--trace-pthread=none|some|all show pthread event details? [no]
> 2. Is the python garbage collector well supported in valgrind ?
In theory, any program should work ok, so it should...
> 3. AS I am having troubles (well just guessing fow now) with threads on
> my SMP linux box does anyone know how to force the soft to only use
> *one* thread (either from c/c++ or python...)?
I don't know about that one.
N
|
|
From: Sebastian <sc...@nb...> - 2003-04-14 14:54:39
|
Hello again, Just wanted to say that I just tested it with 1.9.5 and that produces exactly the same behaviour. ciao, Sebastian -- -. sc...@nb... -. + http://segfault.net/~scut/ `--------------------. -' segfault.net/~scut/pgp `' 5453 AC95 1E02 FDA7 50D2 A42D 427E 6DEF 745A 8E07 `- 4 BLU-82/MOAB articles offered, payment due. hi echelon! -----------------' |
|
From: Sebastian <sc...@nb...> - 2003-04-14 14:38:09
|
Hello, I use valgrind a lot and its a really decent program. Today I stumbled across a quite weird thing which might be a bug in my program, in valgrind or in both. This is how both valgrind 1.0.4 (debian unstable) and 1.9.4 (selfcompiled) complains about code in my program. The first complaint is: ==1682== Use of uninitialised value of size 8 ==1682== at 0x804AB95: be_random_prob (utility.c:111) ==1682== by 0x804F7CB: codegen_getreg (codegen.c:165) Where the interesting part of this function is this: 0x804ab7e <be_random_prob+69>: push $0xffffffff 0x804ab80 <be_random_prob+71>: call 0x804aa89 <be_random> 0x804ab85 <be_random_prob+76>: add $0x10,%esp 0x804ab88 <be_random_prob+79>: mov %eax,0xffffffec(%ebp) 0x804ab8b <be_random_prob+82>: mov 0xffffffec(%ebp),%eax 0x804ab8e <be_random_prob+85>: mov $0x0,%edx 0x804ab93 <be_random_prob+90>: push %edx 0x804ab94 <be_random_prob+91>: push %eax 0x804ab95 <be_random_prob+92>: fildll (%esp,1) 0x804ab98 <be_random_prob+95>: lea 0x8(%esp,1),%esp 0x804ab9c <be_random_prob+99>: fstpl 0xfffffff0(%ebp) It extracted all functions taking part in this code to extra files and ran some tests, without successes. The situation is quite simple: be_random returns one random unsigned int (in %eax), %edx is zeroed out, a 64 bit integer is temporarily created on the stack and the resulting number is loaded into a double register (fildll). The code was generated by gcc 3.2.3 without any optimizations active. I attached a test program to this mail, which does _not_ reproduce the bug, but contains exactly the same code (which I believe to be correct). So, could the valgrind complaint be a side effect of an uncatched bug in my program earlier or is it possibly a bug in valgrind? (I can provide the original program triggering the bug as binary to the authors if they wish so, but not to the list). ciao, Sebastian -- -. sc...@nb... -. + http://segfault.net/~scut/ `--------------------. -' segfault.net/~scut/pgp `' 5453 AC95 1E02 FDA7 50D2 A42D 427E 6DEF 745A 8E07 `- 4 BLU-82/MOAB articles offered, payment due. hi echelon! -----------------' |
|
From: Jeremy F. <je...@go...> - 2003-04-14 11:10:42
|
Quoting Nathan Neulinger <nn...@um...>:
> First off, openafs is doing some user-space threading using
> setjmp/etc.
> There seems to be a mention in the valgrind docs about maybe having
> trouble with this, if this is the problem, is there any workaround?
The big question is how large are the thread stacks, and how far apart are they
in memory? Valgrind's only heuristic for distinguishing between longjmp within
a stack vs. longjmp between stacks is looking at the size of the esp movement;
if it is large, it is a stack switch, and if small it is within one stack.
This heuristic is horribly broken if you have relatively small stacks closely
spaced. Normally, when %esp moves to a lower address, Valgrind considers the
stack to be extended, which means the memory becomes available for use.
Conversely, when %esp goes up, the memory under %esp is considered non-valid.
Now, if Valgrind sees %esp move up, and assumes it is within one stack, then all
the memory between the old value and the new value is invalidated. If it was,
in fact, a stack switch, it has probably completely invalidated one or more of
your stacks, and therefore their local variables, return address, etc. This can
cause massive numbers of spurious errors (including errors at the end of a
function caused by a return to an undefined return address).
There is no good workaround for this at the moment, except by changing the
heuristic threshhold constant (in vg_memory.c from memory, but I don't have the
source with me at the moment).
I have a better solution in mind, but the first implementation didn't work; I
need to think about it more.
J
|
|
From: <da...@2g...> - 2003-04-14 09:07:08
|
Hello, Now I have made a small example that has the following properties: 1) The server works standalone 2) The server works in valgrind 1.0.4 3) The server does not work in valgrind 1.9.5 My system is RedHat Linux 8 with the latest updates. Output from `uname -a`: Linux zion.2good.net 2.4.18-27.8.0 #1 Fri Mar 14 06:45:49 EST 2003 i686 i686 i386 GNU/Linux Some RPM versions: glib-1.2.10-8 glib-devel-1.2.10-8 glibc-2.3.2-4.80.6 glibc-devel-2.3.2-4.80.6 Download my example code here: http://www.2good.nu/tmp/server.tar.gz Just type make to build. Start the server in one shell and run the client in another shell. Expected output from server: connect now! <-- when the server starts client found? condition=1 <-- when a client connects New client! (6) In thread Socket closed <-- this never happens in valgrind 1.9.5 The client does not provide any output, it should just connect and then exit when the server closes the connection. Thank you very much, David Eriksson |
|
From: Mathieu M. <Mat...@cr...> - 2003-04-14 08:17:08
|
Nicholas, Thanks for replying, anyway I still have some questions. 1. I would like to know where the 'KLUDGED call' happens in my soft, is it possible to trace it or print the call tree ? 2. Is the python garbage collector well supported in valgrind ? 3. AS I am having troubles (well just guessing fow now) with threads on my SMP linux box does anyone know how to force the soft to only use *one* thread (either from c/c++ or python...)? thanks, mathieu Nicholas Nethercote wrote: > On Fri, 11 Apr 2003, Mathieu Malaterre wrote: > > >>1. What does : "valgrind's libpthread.so: KLUDGED call to: >>pthread_cond_destroy" means ? >> >>I wasn't able to translate KLUDGED ... > > > 'kludged' means something like 'faked' or 'handled semi-bogusly'. I'm not > sure exactly what it means in this context, but some parts of V's > libpthread.so aren't really complete. It may not matter for your program, > I think. > > >>2. And what does >> >>" Syscall param writev(vector[...]) contains uninitialised or >>unaddressable byte(s) >>at 0x40237951: my_do_syscall3 (vg_libpthread.c:2389) >>by 0x40236BA8: vgIntercept_writev (vg_libpthread.c:2055) >>by 0x4017BF68: __writev (vg_intercept.c:287) >>by 0x43246B45: (within /usr/X11R6/lib/libX11.so.6.2) >>Address 0x413C7FD8 is 124 bytes inside a block of size 2048 alloc'd >>at 0x40165F4D: calloc (vg_clientfuncs.c:242) >>by 0x4321D6FE: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2) >>by 0x430BEB12: gdk_init_check (in /usr/lib/libgdk-1.2.so.0.9.1) >>by 0x42EC3CA1: gtk_init_check (in /usr/lib/libgtk-1.2.so.0.9.1)" >> >>means ? > > > Some code within libX11.so.2 is calling the sys call writev() with some > bogus memory -- in this case, it looks like some of the memory block > passed to writev() (via a pointer) is uninitialised. The 2nd half of the > error tells you where the block in question was allocated. > > If it's in libX11.so, that might be out of your control? in which case you > could suppress it if it does not affect your program, but it sounds like > it unfortunately does in this case. > > N > > > -- Mathieu Malaterre CREATIS 28 Avenue du Doyen LEPINE B.P. Lyon-Montchat 69394 Lyon Cedex 03 http://www.creatis.insa-lyon.fr/~malaterre/ |