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
(11) |
2
|
|
3
(5) |
4
(8) |
5
(33) |
6
(11) |
7
(1) |
8
(3) |
9
(4) |
|
10
(3) |
11
(12) |
12
(17) |
13
(10) |
14
(13) |
15
(7) |
16
|
|
17
(2) |
18
(22) |
19
(9) |
20
(7) |
21
(1) |
22
(4) |
23
(1) |
|
24
|
25
(1) |
26
(3) |
27
(8) |
28
(3) |
29
(16) |
30
(4) |
|
31
|
|
|
|
|
|
|
|
From: Jason G. <jga...@la...> - 2003-08-19 13:55:42
|
> -----Orig > Let's see: > > [~/grind/annelid] gcc a.o memcheck/vgskin_memcheck.so > coregrind/valgrind.so [~/grind/annelid] > VG_ARGS=--suppressions=default.supp; a.out ==26034== > Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. > ==26034== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. > ==26034== Using valgrind-20030725, a program supervision > framework for x86-linux. > ==26034== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. > ==26034== Estimated CPU clock rate is 1404 MHz ==26034== For > more details, rerun with: -v ==26034== ==26034== ==26034== > ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from > 0) ==26034== malloc/free: in use at exit: 0 bytes in 0 blocks. > ==26034== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. > ==26034== For a detailed leak analysis, rerun with: > --leak-check=yes ==26034== For counts of detected errors, > rerun with: -v > > So the answer seems to be yes, with some provisos: > > - You have to link with a particular skin. I linked with Memcheck > above. > > - You have to put the skin .so before valgrind.so when linking. > > - You have to setup $VG_ARGS, by adding a --suppressions= > entry, at the > least. > > I'd be interested to know why you want to do this. That's very nice. Thank you. The reason I want to do this: I run a MUD. I know it has some invalid read/writes and more than likely some memory issues (judging from the cores I've been getting :) ) The problem is, that I cannot reasonable run the MUD in valgrind and find these problems. I need the players to get on there and do what players do (hours or DAYS before a crash occurs). Therefore, I was hoping I could just create a single executable for simplicity. I could run it through the executable, but I thought this would be a little nicer. Thanks! |
|
From: Julian S. <js...@ac...> - 2003-08-19 08:05:17
|
On Tuesday 19 August 2003 07:18, Tom Hughes wrote: > In message <3F4...@re...> > > Steve Fink <sf...@re...> wrote: > > I was mostly wondering if, now that valgrind supports MMX and some SSE, > > it is now reporting that it is an MMX/SSE cpu? If so, is there some way > > of making it act stupid again? (I don't know whether my problem is with > > MMX or SSE instructions, actually.) > > I sent a patch to this list several weeks ago to stop valgrind > reporting the CPU as SSE capable for people with your problem. > > There shouldn't be any problem with MMX as valgrind's MMX support > is supposed to be complete. Yes, the problem happens because the current cvs head, and 20030725 report whatever the real machine's CPUID report, but do not actually implement all the SSE insns. Hence the Intel libraries think the cpu is sse capable when in fact it isn't. A quick hack is to change the definition of VG_(helper_CPUID) in vg_helpers.S back to what it was in 1.9.6 or thereabouts, which claimed to be a pre-MMX pentium-I. That should fool the intel libraries appropraitely. J |
|
From: Nicholas N. <nj...@ca...> - 2003-08-19 07:45:39
|
On Mon, 18 Aug 2003, Jason Gauthier wrote:
> Is it possible to actually link against a valgrind library, or can one only
> run it through the executable?
Let's see:
[~/grind/annelid] gcc a.o memcheck/vgskin_memcheck.so coregrind/valgrind.so
[~/grind/annelid] VG_ARGS=--suppressions=default.supp; a.out
==26034== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==26034== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==26034== Using valgrind-20030725, a program supervision framework for x86-linux.
==26034== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==26034== Estimated CPU clock rate is 1404 MHz
==26034== For more details, rerun with: -v
==26034==
==26034==
==26034== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==26034== malloc/free: in use at exit: 0 bytes in 0 blocks.
==26034== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==26034== For a detailed leak analysis, rerun with: --leak-check=yes
==26034== For counts of detected errors, rerun with: -v
So the answer seems to be yes, with some provisos:
- You have to link with a particular skin. I linked with Memcheck
above.
- You have to put the skin .so before valgrind.so when linking.
- You have to setup $VG_ARGS, by adding a --suppressions= entry, at the
least.
I'd be interested to know why you want to do this.
N
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-19 07:38:42
|
On Mon, 18 Aug 2003, Steve G wrote: > I think this thread has strayed way beyond Jeremy's > original post. He was asking if it was worthwhile to have > something like a Hellegrind race detector. Hear hear! > Should something be done to help locate problems? In one of > the first e-mails of this thread, I wrote an algorithm that > may help locate those problems. Does it work? Can anyone > see a better way to do it? As Jeremy said, it sounds like it would be difficult to do. His Helgrind/Eraser-like algorithm sounds more suitable. However, adding it would make Crocus much more complicated, and I have enough things on my plate as it is. Someone else is very welcome to have a go at adding the functionality. > Am I the only one that believes a race detector would be helpful? I think you are much more aware of these things than most programmers, due to your experience with daemons, etc. N |
|
From: Tom H. <th...@cy...> - 2003-08-19 06:19:41
|
In message <3F4...@re...>
Steve Fink <sf...@re...> wrote:
> I was mostly wondering if, now that valgrind supports MMX and some SSE,
> it is now reporting that it is an MMX/SSE cpu? If so, is there some way
> of making it act stupid again? (I don't know whether my problem is with
> MMX or SSE instructions, actually.)
I sent a patch to this list several weeks ago to stop valgrind
reporting the CPU as SSE capable for people with your problem.
There shouldn't be any problem with MMX as valgrind's MMX support
is supposed to be complete.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2003-08-19 06:13:58
|
On Mon, 2003-08-18 at 06:47, Steve G wrote:
> I suppose an approach might be something like this: Each
> time a signal is about to be delivered, check the mask. If
> any unblocked signal (besides the one about to be
> delivered) has a user defined signal handler, fake
> delivering a signal to it and only note the addresses it
> wanted to read data from or write data to and what the
> access type is (read or write). Don't let it actually
> write, reading is ok since its non-destructive. Then after
> faking a signal to all user defined handlers, check the
> list each time the current signal handler accesses a memory
> location. Only read/write or write/write collisions matter.
> The list gets thrown away at the end of the signal handler.
So you're saying speculatively run the signal handler without side
effects? I think that's pretty tricky. For one, it may have a read
which depends on one of its earlier writes. Even more tricky, it may
write to memory with a syscall, which would be hard to make
side-effect-free.
I think a helgrind-like algorithm would be more appropriate:
For each memory location, maintain a state. There are 4 states:
1. untouched
2. private - only touched by mainline code or a handler for a
particular signal, but not both
3. read-shared - only ever read by mainline and signal handlers
4. RW-shared - both read and written by mainline and signal
handlers
In RW-shared state, it keeps a set of signal handlers which touch the
memory location. If any code touches a location in RW-shared state, it
must have that set of signals blocked, otherwise it reports an error.
The tricky part is trying to determine if a given instruction is being
run as part of a signal handler or not. Entering the signal handler is
pretty obvious, since Valgrind has to go to some effort to deliver a
signal to a thread. Detecting when the application leaves the handler
is more tricky. If the handler does a normal return it's easy enough,
but if it longjmps out of the handler it's harder to tell. I think the
sure-fire way which works in both cases is to detect when ESP goes above
the signal stack frame - this will happen in both the longjmp and
sigreturn cases.
The other potentially tricky thing to handle is recursive signals. I
need to think about it more - it may just fall out in the algorithm
above. I think if you consider the mainline code to also be a
particular form of signal handler (SIGMAIN) then it comes out naturally.
J
|
|
From: Steve F. <sf...@re...> - 2003-08-19 02:34:57
|
I used to be able to valgrind my app, but these days I always run into unimplemented instructions. I have changed several pieces of the puzzle since the last time I was able to successfully run, but I was hoping someone might have an idea. I am using the NVIDIA driver with the __GL_FORCE_GENERIC_CPU flag. I have no reason to suspect that there is any problem with this. I am also using Intel's IPP libraries that make heavy use of MMX and SSE acceleration. They provide versions that are not supposed to contain any MMX code, and I am linking with these. I suspect there may be a problem here, especially since I have upgraded versions since my last successful valgrind run. By liberally spreading printouts through my code and running it under valgrind, it appears that what is happening is that my application calls something in libpng, which calls the pow() function, which has been overridden by the IPP libraries. When disassembled by gdb, IPP's pow() seems to autodetect whether the CPU it is running on supports MMX, and dynamically selects a version of the function to run based on that. (I don't know *why* it is bothering to autodetect anything, since I told it to link with the non-MMX version of the library.) That detection appears to be resulting in it believing that it is running on an MMX processor (which it is, except for the valgrind VM layer). Fall down go boom. Or maybe I'm just horribly confused, and this isn't what's happening at all. I was mostly wondering if, now that valgrind supports MMX and some SSE, it is now reporting that it is an MMX/SSE cpu? If so, is there some way of making it act stupid again? (I don't know whether my problem is with MMX or SSE instructions, actually.) If it would help, I'll post the actual error message. I can't now, since it's on the other side of a very long recompile cycle. This is with valgrind-20030725, and also a CVS checkout from about a week ago. If nobody has any brilliant ideas, I guess I'll slog through downgrading each piece of the puzzle until I can valgrind again. Thanks! Steve |
|
From: Steve G <lin...@ya...> - 2003-08-19 01:14:22
|
>No, cache coherency suffices, really! You can't say that without having a particular problem in mind. For example, cache coherency doesn't suffice when I/O is in the mix. I think this thread has strayed way beyond Jeremy's original post. He was asking if it was worthwhile to have something like a Hellegrind race detector. Rather than pontificating the various ways a signal handler can work or not and how to synchronize, why don't we discuss the *merits* of a race detector? I think the sum of all of this thread is that signal handlers can be tricky. There are many that are bad. Should something be done to help locate problems? In one of the first e-mails of this thread, I wrote an algorithm that may help locate those problems. Does it work? Can anyone see a better way to do it? Am I the only one that believes a race detector would be helpful? This is an interesting subject, but I think we are off track. Jeremy's original question was thoughtful and deserves more consideration. Best Regards, -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Jason G. <jga...@la...> - 2003-08-19 00:40:44
|
Is it possible to actually link against a valgrind library, or can one only run it through the executable? Thanks, Jason |