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
(9) |
2
(5) |
3
(1) |
4
(4) |
5
|
6
(8) |
7
(12) |
|
8
(6) |
9
(10) |
10
(6) |
11
(8) |
12
(12) |
13
(5) |
14
(1) |
|
15
(1) |
16
(12) |
17
(9) |
18
(4) |
19
(8) |
20
(4) |
21
(1) |
|
22
|
23
(4) |
24
(12) |
25
(13) |
26
(16) |
27
(4) |
28
(2) |
|
29
(1) |
30
(4) |
31
(9) |
|
|
|
|
|
From: Dennis L. <pla...@tz...> - 2006-01-19 21:32:20
|
Am Donnerstag, den 19.01.2006, 17:21 +0000 schrieb Bryan Henderson: > Because while both these methods have zero false positives and > therefore eliminate the time it takes me to analyze them, my proposal > catches lots more real bugs than yours does, as does my manual version > of it. Yeah, all the reports of V about all those things is annoying. The Program runs, and who cares about ISO standard compliant program behaviour if it just runs? V should really only report those things are definetly causing segfaults, thats what it was made for! greeds Dennis |
|
From: Daniel B. <czc...@br...> - 2006-01-19 20:13:27
|
CWTD's announcement has created a fantastic stir in the market. Investors have been pushing up the volume and the price has been following. The announcement hit late Friday and has only started to create its waves this morning. Today we watched as the price climbed to a high of $1.59 from Fridays close of $1.36. Tomorrow we expect much of the same pushing the price to $2.00 and UP. Take a look at today's stats and review last weeks announcement. Company: China World Trade Corporation Symbol: CWTD Previous: $1.59 Wed High: $1.80 Short Term: $2.50 Note: Volume And Price Increase CWTD's corporate services are spread across the scale through their many divisions. Working with some of the largest corporations in the Asian market, combined with strategic alliances gives the foundation to continue expanding the their market share. How We See It: This company has continued to generate a growing interest among investors. Each time it releases news on its expansion or strategic changes, the stock soars giving both day traders and long term investors fantastic returns on there investments. We are looking forward to another climb in price and volume tomorrow. If you have not already jumped on this stock we think you should take advantage of it in the morning before it climbs any higher. For those of you have already gotten on board, tomorrow enjoy another prosperous day. Our Viewpoint: Last time this stock released an announcement like this it climbed in price and volume and made many of our members a healthy return on their investment. Make sure you get in on CWTD first thing Thursday. (OTCBB:CWTD):Closed January 30, 2004 at $1.50. Closed February 17th at $7.90, Up 426%, we see the same thing happening again... |
|
From: <br...@gi...> - 2006-01-19 17:40:27
|
>> My personal strategy is to look at every "Invalid read of size 4" and if >> it just runs off the end of an odd-sized block, I write a suppression for >> it. I don't try to determine if there's a real problem; I just presume >> there isn't. > >If the bad read comes from libc, your strategy is possibly ok, >though you may miss bugs where you pass a "too small" buffer >into libc. > >If it comes from your own code, it is almost certainly a bug in your >code (unless you also perform "ultra-optimizations", and you should fix it >instead of suppressing. I'd say it's most likely correct in any code. Code that does a full word read like this is _probably_ doing the ultra-optimization. Empirically, every single one I've seen (about 6) is in this category. Also, every single one was in code I can't practically change. >> So why can't Valgrind do that for me? > >Why not run with --tool=none ? >That way you wouldn't get any reports at all. Because while both these methods have zero false positives and therefore eliminate the time it takes me to analyze them, my proposal catches lots more real bugs than yours does, as does my manual version of it. -- Bryan Henderson Phone 408-621-2000 San Jose, California |
|
From: Julian S. <js...@ac...> - 2006-01-19 07:49:32
|
> So why can't Valgrind do that for me? I assume it can't or it would > have been mentioned in this context. But I'd love to be able to tell > Valgrind to ignore invalid reads of size one word that happen in the > last word of a block. It can. You need --partial-loads-ok=yes and you need to use 3.1.0. Note that my (possibly unconstructive) view is that programs which behave like that are basically broken. Yeh, I know it's safe wrt not taking any extra page faults, and it's hardwired into glibc and so essentially unavoidable, but still it's not ANSI/ISO compliant. J |
|
From: Sigurd S. <sig...@go...> - 2006-01-19 06:22:35
|
Done. Bug #120410. HTH Sigurd Am Wednesday 18 January 2006 14:58 schrieb Tom Hughes: > In message <200...@gm...> > > Sigurd Schneider <sig...@go...> wrote: > > Running valgrind-3.1.0 on my system with any executable always lead up to > > the following error. I'm using the compiler option > > -fprefetch-loop-arrays. Maybe that is a problem? > > If you need more information feel free to mail me. If it is stupid to > > report this, then please let me know. > > Please raise a bug for this on the tracker - the important thing > to include is the error message with the unhandled bytes listed. > > Tom |
|
From: Paul P. <ppl...@gm...> - 2006-01-19 05:01:46
|
On 19 Jan 2006 04:29:04 +0000, Bryan Henderson <br...@gi...> wr= ote: > My personal strategy is to look at every "Invalid read of size 4" and if > it just runs off the end of an odd-sized block, I write a suppression for > it. I don't try to determine if there's a real problem; I just presume > there isn't. If the bad read comes from libc, your strategy is possibly ok, though you may miss bugs where you pass a "too small" buffer into libc. If it comes from your own code, it is almost certainly a bug in your code (unless you also perform "ultra-optimizations", and you should fix it instead of suppressing. > So why can't Valgrind do that for me? Why not run with --tool=3Dnone ? That way you wouldn't get any reports at all. Cheers, |
|
From: <br...@gi...> - 2006-01-19 04:44:56
|
I've seen a few references in the archives to the ultra-optimized glibc strlen function (and various other functions that use the same optimization). This must be quite familiar to all Valgrind users -- I myself am getting tired of dealing with it. But as a reminder: Some functions read a byte-granularity block of memory one word at a time, for speed. That means they tend to overrun the block of memory by a few bytes at the end, and Valgrind/Memcheck screams. My personal strategy is to look at every "Invalid read of size 4" and if it just runs off the end of an odd-sized block, I write a suppression for it. I don't try to determine if there's a real problem; I just presume there isn't. So why can't Valgrind do that for me? I assume it can't or it would have been mentioned in this context. But I'd love to be able to tell Valgrind to ignore invalid reads of size one word that happen in the last word of a block. -- Bryan Henderson Phone 408-621-2000 San Jose, California |
|
From: Dalibor T. <ro...@ka...> - 2006-01-19 03:10:57
|
Richard Frith-Macdonald <richard <at> brainstorm.co.uk> writes: > I haven't managed to get things to work with Kaffe ... I am sorry to hear that. > The only way I'm likely to find out for sure is to build a > version from source and run under gdb to see exactly what's going on > when it starts up Yeah. You may want to chose jikes for the java compiler, since ecj crashes building 1.1.6-91 (i.e 1.1.7-rc1) on amd64 debian, according to the buildd logs from today :/ cheers, dalibor topic |