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
(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: Julian S. <js...@ac...> - 2003-04-17 23:32:38
|
That's very strange. V has threading problems with glibcs > 2.3.1, though. So I wonder if that's it. Do you have an older linux distro you can try it on, something like RH 7.3, or Suse 8.1 ? Basically anything with glibc 2.3.1 or before; 2.2.5 would be even better. J On Thursday 17 April 2003 6:58 pm, Todd Richmond wrote: > I just started using valgrind and it has already found 2 nasty buffer > overruns for me. However, it only works on my single threaded programs. I > have a MT server that uses a thread pool for incoming socket requests - one > thread poll()s on all fds and then queues up work objects to be run by > slave threads. My problem is that once the master thread is started, it > runs properly in a poll() loop (with a few second timeout), but other > threads receive almost no cpu time, including the original main thread that > started the master poller! At first I thought all other threads were hung > indefinitely, but I left the program run for 30+ minutes and the main > thread finally printed out a debug string after the pthread_create() so > slowly that it did so one character at a time over several minutes. > > I am using Redhat 8 updated to all current patches which includes glibc > 2.3.2 and have tried both vgrind 1.9.5 and the 2.0 cvs branch > > Thanks, > Todd > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Todd R. <ric...@pr...> - 2003-04-17 18:00:09
|
I just started using valgrind and it has already found 2 nasty buffer
overruns for me. However, it only works on my single threaded programs. I
have a MT server that uses a thread pool for incoming socket requests - one
thread poll()s on all fds and then queues up work objects to be run by slave
threads. My problem is that once the master thread is started, it runs
properly in a poll() loop (with a few second timeout), but other threads
receive almost no cpu time, including the original main thread that started
the master poller! At first I thought all other threads were hung
indefinitely, but I left the program run for 30+ minutes and the main thread
finally printed out a debug string after the pthread_create() so slowly that
it did so one character at a time over several minutes.
I am using Redhat 8 updated to all current patches which includes glibc
2.3.2 and have tried both vgrind 1.9.5 and the 2.0 cvs branch
Thanks,
Todd
|
|
From: Melchior F. <mf...@us...> - 2003-04-17 14:18:32
|
* Mathieu Malaterre -- Thursday 17 April 2003 16:03: > If you are using the lastest nvidia driver you can use: > > $__GL_FORCE_GENERIC_CPU=1 valgrind ... Or else you can still override the nvidia driver by mesa, as in $ LD_PRELOAD=/usr/lib/GL/libGL.so.1.3.mesasoft valgrind ... m. |
|
From: Nicholas N. <nj...@ca...> - 2003-04-17 14:12:16
|
On Thu, 17 Apr 2003, Jos van den Oever wrote:
> Now I'm rather clueless about SSE, but I know 3DNow is Athlon specific.
> Is SSE Pentium related? Or is MMX not completely implemented yet?
SSE and SSE2 are yet more sets of extra instructions, like MMX and 3DNow.
They are supported by modern Pentiums and Athlons. Valgrind doesn't yet
support them.
However, NVidia also noticed this it seems, and the "latest" drivers
(version 4349, apparently) come with this text
DISABLING CPU SPECIFIC FEATURES
Setting the environment variable __GL_FORCE_GENERIC_CPU to a
non-zero value will inhibit the use of CPU specific features
such as MMX, SSE, or 3DNOW!. Use of this option may result in
performance loss. This option may be useful in conjunction with
software such as the Valgrind memory debugger.
Set __GL_FORCE_GENERIC_CPU=1 and Valgrind should work.
N
|
|
From: Mathieu M. <Mat...@cr...> - 2003-04-17 14:09:10
|
If you are using the lastest nvidia driver you can use: $__GL_FORCE_GENERIC_CPU=1 valgrind ... mathieu Jos van den Oever wrote: > I'm trying to debug an OpenGL program on a Pentium IV with an NVidia > Riva TNT2 graphics card. However valgrind from today's CVS on SuSE 8.2 > gives me this error: > > disInstr: unhandled 2-byte opcode: 0x28 0x2 0xF > This _might_ be the result of executing a SSE, SSE2 or 3DNow! > instruction. Valgrind does not currently support such instructions. > Sorry. > Aborted > > Now I'm rather clueless about SSE, but I know 3DNow is Athlon specific. > Is SSE Pentium related? Or is MMX not completely implemented yet? > > Best regards, Jos van den Oever > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Mathieu Malaterre CREATIS 28 Avenue du Doyen LEPINE B.P. Lyon-Montchat 69394 Lyon Cedex 03 http://www.creatis.insa-lyon.fr/~malaterre/ |
|
From: Thomas R. T. <tr...@cs...> - 2003-04-17 13:59:35
|
valgrind seems to have a problem with swapcontext() tasking.
We use getcontext/setcontext/swapcontext
rather than setjmp/longjmp for tasking.
The *context routines are slower than *jmp
but seem to be a more official API for tasking.
For example the program below triggers messages such as:
==26015== Invalid write of size 4
==26015== at 0x42045D6C: __swapcontext (in /lib/i686/libc-2.2.93.so)
==26015== Address 0xBFFFE9BC is on thread 1's stack
This isn't a problem for us, since we can optionally use pthread tasking.
But I thought I should mention it.
Tom Truscott
#include <stdio.h>
#include <stdlib.h>
#include <ucontext.h>
ucontext_t child, parent;
#define STACKSZ (256*1024)
void childfunc(void)
{
printf("entering child\n");
swapcontext(&child, &parent);
printf("leaving child\n");
}
int
main()
{
printf("entering main\n");
getcontext(&child);
child.uc_link = 0;
child.uc_stack.ss_sp = malloc(STACKSZ);
child.uc_stack.ss_size = STACKSZ;
child.uc_stack.ss_flags = 0;
makecontext(&child, (void(*)())childfunc, 0);
swapcontext(&parent, &child);
printf("leaving main\n");
return 0;
}
|
|
From: Jos v. d. O. <jos...@wu...> - 2003-04-17 13:53:21
|
I'm trying to debug an OpenGL program on a Pentium IV with an NVidia Riva TNT2 graphics card. However valgrind from today's CVS on SuSE 8.2 gives me this error: disInstr: unhandled 2-byte opcode: 0x28 0x2 0xF This _might_ be the result of executing a SSE, SSE2 or 3DNow! instruction. Valgrind does not currently support such instructions. Sorry. Aborted Now I'm rather clueless about SSE, but I know 3DNow is Athlon specific. Is SSE Pentium related? Or is MMX not completely implemented yet? Best regards, Jos van den Oever |
|
From: Neulinger, N. <nn...@um...> - 2003-04-17 13:43:43
|
> Or how behaves the LWP lib of AFS on stack overflows? If it=20 > uses mprotect()=20 > for manual stack growing, we can track this, too. I'm pretty sure it behaves really badly. The stack switching I believe is fairly limited, and is being used to implement threads. The application is responsible for requesting a large enough stack to handle it's deepest nesting of calls. Since it's a server, and fairly predictable, that isn't usually a problem. -- Nathan |
|
From: Josef W. <Jos...@in...> - 2003-04-17 13:37:43
|
On Thursday 17 April 2003 10:31, Jeremy Fitzhardinge wrote: > ... > I think the correct solution is to move stack switch detection into the > skin themselves (memcheck, addrcheck and helgrind are the only ones I know > of which care). Memcheck and addrcheck can use their existing validity > info to make the determination; helgrind is harder. Calltree does ESP tracking, too. Needed for recursion detection and correct handling of setjmp/longjmp or C++ exceptions and like that. So I'm voting for a skin trackable event for stack switching from the core. Isn't this almost the same as the "switch_thread" event? As I see, the first stack switch always has quite a large delta. If we remember the instruction address somehow and assume further stack switches if the same instruction is executed (breaking up a BB into two at this point). [This is new in the resend to Valgrind-users] Another idea: Doesn't the kernel need to know about stack segments somehow by declaring the VMA as growable? So isn't it enough to check for ESP changes among growable VMAs? Or how behaves the LWP lib of AFS on stack overflows? If it uses mprotect() for manual stack growing, we can track this, too. Josef |
|
From: Sebastian K. <Seb...@so...> - 2003-04-17 10:27:00
|
From: "Nicholas Nethercote" <nj...@ca...> > Maybe have VALGRIND_START_STACK_SWITCH and VALGRIND_END_STACK_SWITCH, and > within that look for a "sizeable" %esp change (eg. anything bigger than > 1KB or something) as a genuine switch? Or maybe not, I don't know. Hello! Just some not-insider suggestion: Maybe then use VALGRING_START_STACK_SWITCH(min_size)? min_size would be used to determine if ESP change is sizeable? rgds Sebastian Kaliszewski |
|
From: Nicholas N. <nj...@ca...> - 2003-04-17 08:47:04
|
On Thu, 17 Apr 2003, Jeremy Fitzhardinge wrote: > > Would a client request be a good compromise? Eg. insert > > VALGRIND_STACK_SWITCH just before the stack switch? It's more > > intrusive than a command line option, but it's more precise. Similar > > to the client request for handling self-modifying code. > > > > [I haven't thought through how the request would actually be > > implemented, but it shouldn't be too hard, I think...] > > Yeah, it would. It would need to mean something like "the next change to %esp is > a stack switch", but what if changing the stack changes %esp multiple times? How > do you know if the compiler is going to generate some non-stack switch changes to > %esp as part of its codegen? Maybe have VALGRIND_START_STACK_SWITCH and VALGRIND_END_STACK_SWITCH, and within that look for a "sizeable" %esp change (eg. anything bigger than 1KB or something) as a genuine switch? Or maybe not, I don't know. > I think the correct solution is to move stack switch detection into the skin > themselves (memcheck, addrcheck and helgrind are the only ones I know of which > care). Memcheck and addrcheck can use their existing validity info to make the > determination; helgrind is harder. How does validity info help? N |
|
From: Jeremy F. <je...@go...> - 2003-04-17 08:33:19
|
Quoting Robert Walsh <rj...@du...>: > JeremyF and I had a chat about this over lunch a few weeks ago. One > idea floated was to check what the instruction that was ultimately > responsible for the stack switch was. If it was a move to sp type > instruction, it's probably a stack switch. Otherwise it's probably a > push or a pop. No, if its a move, its probably a longjmp; you still can't tell whether its a stack switch or a longjmp within the stack. J |
|
From: Jeremy F. <je...@go...> - 2003-04-17 08:31:58
|
Quoting Nicholas Nethercote <nj...@ca...>: > On Tue, 15 Apr 2003, Neulinger, Nathan wrote: > > > I think (from what I understand) that the problem is that if you > lower > > the threshold to something like 128K, valgrind will get confused if > you > > allocate a 128K+ object on the stack. If you're certain that no > > individual object on the stack would be that size, it would probably > be > > useful to have an option to specify it. > > Would a client request be a good compromise? Eg. insert > VALGRIND_STACK_SWITCH just before the stack switch? It's more > intrusive > than a command line option, but it's more precise. Similar to the > client > request for handling self-modifying code. > > [I haven't thought through how the request would actually be > implemented, > but it shouldn't be too hard, I think...] Yeah, it would. It would need to mean something like "the next change to %esp is a stack switch", but what if changing the stack changes %esp multiple times? How do you know if the compiler is going to generate some non-stack switch changes to %esp as part of its codegen? I think the correct solution is to move stack switch detection into the skin themselves (memcheck, addrcheck and helgrind are the only ones I know of which care). Memcheck and addrcheck can use their existing validity info to make the determination; helgrind is harder. J |
|
From: Jeremy F. <je...@go...> - 2003-04-17 08:24:00
|
Quoting Sebastian <sc...@nb...>:
> This code looks correct to me. 'rand_fd' leads to /dev/urandom, so to
> valgrind it should just look like if 'tmp' is defined by the read(), and
> the
> return value defined by the modulo operation.
Only if you're sure that max is defined. Try scattering some
VALGRIND_CHECK_DEFINED()s around to see what is actually a defined value where.
BTW, this won't generate an even distribution from 0...max if that's what you
need.
J
|
|
From: Jeremy F. <je...@go...> - 2003-04-17 08:18:29
|
Quoting "Neulinger, Nathan" <nn...@um...>:
> I believe that LWP (afs's light weight process library) defaults to a
> minimum stack size of 192k for linux.
>
> Although some of the users of that library request smaller -
> 8k/16k/24k/etc. I believe the minimum is enforced.
>
> Here's the warnings I get when testing:
>
> ==11883== Warning: client switching stacks? %esp: 0xBFFFEB5C -->
> 0x41067ABC
> ==11883== Warning: client switching stacks? %esp: 0x41067A08 -->
> 0xBFFFEB90
> ==11883== Warning: client switching stacks? %esp: 0xBFFFEB8C -->
> 0x410AC094
> ==11883== Warning: client switching stacks? %esp: 0x410ABE90 -->
> 0xBFFFEBC0
> ==11883== Warning: client switching stacks? %esp: 0xBFFFE66C -->
> 0x410ABEF4
>
> Those are fairly large address changes. It looks to me like it is
> switching to a temporary stack stored in malloc'd memory.
>
> In vg_memory, it talks about a VG_PLAUSIBLE_STACK_SIZE of 8000000 and
> VG_HUGE_DELTA of VG_P_S_S / 4.
>
> I wonder if perhaps the issue is that the above stack switches show up
> as changes because it's going from the normal stack to malloc'd mem,
> but
> changes between the fake stacks are not showing up, since they are
> small
> switches within malloced mem.
Yup, that would be it. Make HUGE_DELTA smallish and see if that helps (and
increase the LWP stack size if you can).
J
|
|
From: Philippe E. <ph...@wa...> - 2003-04-17 00:06:03
|
Nicholas Nethercote wrote: > On Wed, 16 Apr 2003, Philippe Elie wrote: > > >>>This works, but it would be better if the GDB variable was put into a .h >>>file, so it's available everywhere -- that's better than having to feed it >>>in to every file that needs it with -D. This could be done by introducing >>>eg. vg_skin.h.in, but that would be a pain, especially just for one >>>variable. >> >>Yes, it's a better way but the trivial: > > > [snip] > > >>Not very elegant but the only way I found > > > Hmm, pretty ugly... if that's the only way to do it, I can live with > passing in the option using -D :) But the dependencies problem ? If the flags change you don't recompile the right file. A user with two gdb version, can change $PATH to select a different version and run configure; make but he will not get the right gdb version. regard, Phil |