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
(3) |
2
(4) |
3
(10) |
|
4
(1) |
5
(2) |
6
(10) |
7
(16) |
8
(7) |
9
(3) |
10
|
|
11
(11) |
12
(16) |
13
(14) |
14
(9) |
15
(13) |
16
(10) |
17
(2) |
|
18
|
19
(14) |
20
(1) |
21
(1) |
22
(11) |
23
(7) |
24
(8) |
|
25
(11) |
26
(10) |
27
(3) |
28
(8) |
29
(24) |
30
(10) |
|
|
From: Dennis L. <pla...@in...> - 2005-09-23 16:56:50
|
Hi, while having a question I read up valgrinds FAQ (actually the one from current svn) and hoped to find the answer in section 6.2. I think although its mentioned in the manual, there should be a short explanation of "direct" and "indirect" too. Now to my question I could not really find in the manual too. When valgrind(memcheck) reports the following: 80 (48 direct, 32 indirect) bytes in 1 blocks are definitely lost What I thought about a "block" was always that one block is one allocated chunk of memory, like the result of one single new/malloc etc. Now how can a part of this block beeing directly lost and the other one indirectly ? From what I understand the manual so far a block is directly lost if no pointer points to the beginning, or the block is indirectly lost when a pointer points into the middle of the block. But a part of the block beeing directly lost and the other one indirectly does not currently make sense to me, can anyone enlighten me on this point ? greets Dennis |
|
From: Dennis L. <pla...@in...> - 2005-09-23 16:37:49
|
Hi, I know that currently valgrind can only tell you where memory was allocated that is lost. In certain situations its hard to track down memory leaks with this information only, so like if the data is passed around to dozens of different parts in the program, and sometimes the correct parts destroys it and sometimes not. So, what would be a nice feature is, if valgrind could report the stacktrace for the position where the last pointer referencing the memory is lost. The question now is, if the memcheck tool can be (easily) get to track the pointers ? Im thinking of tracking whether copied around data is a pointer to something when copying it, and if the data gets unreachable (either through explicit deallocation, or implicit by reducing stack) then some reference counter for the allocated memory is decreased, and if 0 reported. If memcheck cannot be used for this, is there an estimate on how easy/hard it would be to create a new tool that does this (and only this) ? Or if its even possible with the valgrind framework ? greets Dennis |
|
From: Ken S. <ken...@ya...> - 2005-09-23 14:57:24
|
I submitted this as a bug, http://bugs.kde.org/show_bug.cgi?id=112731, but haven't heard anything on it. I recognize that this is a challenging bug to deal with, as I have been unable to reduce it to a self contained example. But, I was able to characterize it considerably and with a bit of help could characterize it further. Hopefully leading to a self contained example. Thanks, Ken --- Brian Crowder <cr...@fi...> wrote: > > Actually, thinking on this some more, I think my original answer is > incorrect or imprecise: > > char *ptr; > > int > main() > { > ptr = new char[10]; > return; > } > > Is a better example of an allocation which will not be reported by > valgrind as a direct or indirect leak. Even after main() returns, ptr > is still valid, reachable memory (I believe valgrind does its reporting > after main). This probably explains why your factory-generated objects > aren't being reported. You likely have a global automagic variable > that's hanging onto them. My original suggestion still holds, though. > Try --show-reachable. > > -- Brian > > Brian Crowder wrote: > > > > > int > > main() > > { > > char *ptr = new char[10] > > return; > > } > > > > Isn't necessarily a leak for valgrind. Your memory is still > > referencABLE, just not destroyed explicitly. If you want to see > > -everything- that hasn't been destroyed, run your program with > > --show-reachable=yes > > > > Ken Stanley wrote: > > > >> In my application, Amesos, > >> http://software.sandia.gov/trilinos/packages/amesos/index.html, > >> many memory leaks are not found by valgrind 2.2 and 3.01. Pointers > >> (or other > >> structures) defined in one of the Amesos classes, and allocated but not > >> deallocated are not identified as being lost or even reachable. > >> I have even added a bogus pointer, allocated space for it using new > >> int[10], > >> never deallocating it. This is not caught by valgrind 3.01. (I did > >> not check > >> 2.2 on this particular case). > >> These memory leaks are not caught when the Amesos classes are created > >> through a > >> factory interface, but they are caught when the Amesos classes are > >> created > >> directly (not through the factory interface). > >> > >> Ken > >> > >> Ken Stanley > >> 440 774 4322 7AM-9PM Eastern Time > >> > >> > >> ------------------------------------------------------- > >> SF.Net email is Sponsored by the Better Software Conference & EXPO > >> September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >> Practices > >> Agile & Plan-Driven Development * Managing Projects & Teams * Testing > >> & QA > >> Security * Process Improvement & Measurement * > >> http://www.sqe.com/bsce5sf > >> _______________________________________________ > >> Valgrind-users mailing list > >> Val...@li... > >> https://lists.sourceforge.net/lists/listinfo/valgrind-users > >> > >> > >> > >> > >> > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > > & QA > > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > > > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > Ken Stanley 440 774 4322 7AM-9PM Eastern Time |
|
From: Roman P. <rom...@ec...> - 2005-09-23 08:59:21
|
Dear Valgrind Users =20 While developing huge project on Linux. =20 Project info: * Red Hat Linux 3.2.3-52 (Enterprise 3) * gcc 3.2.3 * Valgrind 3.0 version compiled with gcc 3.2.3. * OCI ( Oracle Call Interface) Instant Client Version 10.1.0.4 * Also some other 3 party libraries which are compiled with gcc 3.2.3 and using specific hardware installed in the system NMS SS7 or INAP telecommunication cards * All software we write we compile with gcc 3.2.3 * We could not go to higher gcc version=20 =20 We tried to use Valgrind for memory profiling and what we face when running software in Valgrind: 1) When we want to connect to the Oracle with OCI it says that even OCI Environment could not be created and application refuse to work properly 2) No 3 party library is not working correctly is just no executing what it should =20 We really have made deep search in Valgrind docs and tried all possible ways but it doesn=92t help on the google people mostly do not have problems to use profile OCI. =20 Please any one who has some good idea how to fix that stuff are welcome to help use with info. =20 Best regards Roman Pakhomov =20 --=20 Internal Virus Database is out-of-date. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.18/91 - Release Date: 06/09/2005 =20 |
|
From: Stefan O. <so...@ly...> - 2005-09-23 08:52:13
|
Hi again list, I did not notice all replies to my question earlier, I wasn't subscribed to the list, so I only saw Nicholas' replies. I installed valgrind-2.4.1 now, and its output seems more reasonable. All loads that are executed have numbers larger than 0 in the margin. It looks to me as if valgrind-3.0.1 has a bug valgrind-2.4.1 don't. I'll see if I can construct a short version of the code to demonstrate the problem. |
|
From: <War...@ci...> - 2005-09-22 22:14:19
|
HI all, I've been trying to use valgrind on a largish project that involves a lot of C and C++ code invoked through jni from a java server. I've seen a couple of other posts here from people who say they are using valgrind with java successfully, but I find that even with a 'Hello World' java program, I hit the 30000 error limit before I even get to my main routine. And a lot of the error messages I get look like this: ==24225== 127 errors in context 53 of 53: ==24225== Invalid write of size 4 ==24225== at 0x1F22A20E: ??? ==24225== by 0x1F224A7A: ??? ==24225== by 0x1F2249A3: ??? ==24225== by 0x1F2249A3: ??? ==24225== by 0x1F2249A3: ??? ==24225== by 0x1F2249A3: ??? ==24225== by 0x1F224922: ??? ==24225== by 0x1F224C28: ??? ==24225== by 0x1F2249A3: ??? ==24225== by 0x1F2249A3: ??? ==24225== by 0x1F2249A3: ??? ==24225== by 0x1F222156: ??? so I have to add some very general suppressions to get through them. Am I missing something - is there an easier way to make this work? I'm actually not at all interested in valgrind info for any of the java code - just for our C and C++ code. Is there anyway to tell valgrind to only pay attention to certain shared libs? I'm doing this on a somewhat out-of-date debian unstable machine (probably 3-4 months since the last dist-upgrade) - it's an AMD 2800+ running a 2.6.8 kernel, I'm using the 1.5.0_03 build of java (although I see the same thing with a 1.4.2 build), and I'm using valgrind 3.0.1 built from source. Any advice would be greatly appreciated... Warren -- Warren Baird, Senior Technical Group Leader war...@ci... Cimmetry System Corp. 514 735 3219 x148 |
|
From: Nicholas N. <nj...@cs...> - 2005-09-22 21:08:22
|
Dear Valgrind User, We'd like you to participate in the second official Valgrind survey. It can be found at: http://www.valgrind.org/gallery/surveys.html Our first survey was in November 2003. It was very useful and we made a number of changes to how we do things as a result (the above page links to a list of some of these changes). Valgrind has changed a lot since then. This is your chance to let us know what you think about Valgrind and how it can be improved. This survey is shorter and better focused than the 2003 survey. We'd like you to respond, even if you filled out the 2003 survey, or filled out an intermediate survey on the website in the time between now and then -- the survey evolved over that time, and we'd like all the responses to be from the same time period. If you know a Valgrind user who doesn't read the lists, please forward this message to them. If you are worried about privacy: the survey can be taken anonymously, although the survey explains why we prefer that you include your name and email address. You don't have to answer any question you don't want to, but we encourage you to answer all of them. We won't reveal your name or email address to anyone outside the Valgrind team. Your response is confidential; we won't make raw data public, only summaries (which may include anonymous quotes). The only exception to this is if you answer "yes" to question 16 about mentioning your project on the Valgrind website. We will collect up the responses about one week from now (the exact time depends on the response rate, we'll keep it open longer if responses are still coming in), and post the analysis and results some time afterwards. Thank you for your participation. The Valgrind Team |
|
From: Nicholas N. <nj...@cs...> - 2005-09-22 20:40:33
|
On Thu, 22 Sep 2005, Neil Youngman wrote: > I see that Valgrind 3 has a lot or code with declarations in the middle of > blocks, so it no longer compiles on older systems with gcc 2. Is this a > deliberate decision? Not really. We should make a policy decision and turn on -Wdeclaration-after-statement if we decide to support older GCCs. Nick |
|
From: Neil Y. <nei...@yo...> - 2005-09-22 20:32:05
|
I see that Valgrind 3 has a lot or code with declarations in the middle of blocks, so it no longer compiles on older systems with gcc 2. Is this a deliberate decision? Neil Youngman |
|
From: John R.
|
> ==19693== Conditional jump or move depends on uninitialised value(s) > ==19693== at 0x422404: mbrtowc (in /lib/tls/libc-2.3.5.so) The patches linked in http://bitwagon.com/glibc-audit/glibc-audit.html fix an uninitialized "don't-care" local variable that is internal to __mbrtowc(). Perhaps this would help. -- |
|
From: Sampath N. R. <sam...@kc...> - 2005-09-22 14:11:38
|
Dear Valgrind user, I am using the STL list structure in one of my programs and I am getting the following messages from the memory checker. I am completely at a loss as to how I can initialise a list structure. Could someone tell me how to fix these problems. I am using Ferdora core 3 with gcc 3.3. Thanks, Sampath ------------------------------------------------------------------------------- ==19693== Conditional jump or move depends on uninitialised value(s) ==19693== at 0x422404: mbrtowc (in /lib/tls/libc-2.3.5.so) ==19693== by 0x3DD9B1: mblen (in /lib/tls/libc-2.3.5.so) ==19693== by 0x1BABD8EE: xercesc_2_7::IconvLCPTranscoder::calcRequiredSize(char const*, xercesc_2_7::MemoryManager*) (in /home/gnu/testns/ns- allinone-2.26/ns-2.26/xerces/lib/libxerces-c.so.27.0) ==19693== by 0x1BABDDD2: xercesc_2_7::IconvLCPTranscoder::transcode (char const*) (in /home/gnu/testns/ns- allinone-2.26/ns-2.26/xerces/lib/libxerces-c.so.27.0) ==19693== by 0x1BB8BAA0: xercesc_2_7::XMLString::transcode(char const*) (in /home/gnu/testns/ns- allinone-2.26/ns-2.26/xerces/lib/libxerces-c.so.27.0) ==19693== by 0x804AE75: Message::serialize() (stl_list.h:172) ==19693== by 0x804BFA9: main (messageTest.cpp:29) ==19693== ==19693== Conditional jump or move depends on uninitialised value(s) ==19693== at 0x422445: mbrtowc (in /lib/tls/libc-2.3.5.so) ==19693== by 0x3DD9B1: mblen (in /lib/tls/libc-2.3.5.so) ==19693== by 0x1BABD8EE: xercesc_2_7::IconvLCPTranscoder::calcRequiredSize(char const*, xercesc_2_7::MemoryManager*) (in /home/gnu/testns/ns- allinone-2.26/ns-2.26/xerces/lib/libxerces-c.so.27.0) ==19693== by 0x1BABDDD2: xercesc_2_7::IconvLCPTranscoder::transcode (char const*) (in /home/gnu/testns/ns- allinone-2.26/ns-2.26/xerces/lib/libxerces-c.so.27.0) ==19693== by 0x1BB8BAA0: xercesc_2_7::XMLString::transcode(char const*) (in /home/gnu/testns/ns- allinone-2.26/ns-2.26/xerces/lib/libxerces-c.so.27.0) ==19693== by 0x804AE75: Message::serialize() (stl_list.h:172) ==19693== by 0x804BFA9: main (messageTest.cpp:29) ==19693== ==19693== Conditional jump or move depends on uninitialised value(s) ==19693== at 0x3CC2FF: __gconv_transform_ascii_internal (in /lib/tls/libc-2.3.5.so) ==19693== by 0x42248A: mbrtowc (in /lib/tls/libc-2.3.5.so) ==19693== by 0x3DD9B1: mblen (in /lib/tls/libc-2.3.5.so) ==19693== by 0x1BABD8EE: xercesc_2_7::IconvLCPTranscoder::calcRequiredSize(char const*, xercesc_2_7::MemoryManager*) (in /home/gnu/testns/ns- allinone-2.26/ns-2.26/xerces/lib/libxerces-c.so.27.0) ==19693== by 0x1BABDDD2: xercesc_2_7::IconvLCPTranscoder::transcode (char const*) (in /home/gnu/testns/ns- allinone-2.26/ns-2.26/xerces/lib/libxerces-c.so.27.0) ==19693== by 0x1BB8BAA0: xercesc_2_7::XMLString::transcode(char const*) (in /home/gnu/testns/ns- allinone-2.26/ns-2.26/xerces/lib/libxerces-c.so.27.0) ==19693== by 0x804AE75: Message::serialize() (stl_list.h:172) ==19693== by 0x804BFA9: main (messageTest.cpp:29) ==19693== ==19693== Use of uninitialised value of size 4 ==19693== at 0x3CC31C: __gconv_transform_ascii_internal (in /lib/tls/libc-2.3.5.so) ==19693== by 0x42248A: mbrtowc (in /lib/tls/libc-2.3.5.so) ==19693== by 0x3DD9B1: mblen (in /lib/tls/libc-2.3.5.so) ==19693== by 0x1BABD8EE: xercesc_2_7::IconvLCPTranscoder::calcRequiredSize(char const*, xercesc_2_7::MemoryManager*) (in /home/gnu/testns/ns- allinone-2.26/ns-2.26/xerces/lib/libxerces-c.so.27.0) ==19693== by 0x1BABDDD2: xercesc_2_7::IconvLCPTranscoder::transcode (char const*) (in /home/gnu/testns/ns- allinone-2.26/ns-2.26/xerces/lib/libxerces-c.so.27.0) ==19693== by 0x1BB8BAA0: xercesc_2_7::XMLString::transcode(char const*) (in /home/gnu/testns/ns- allinone-2.26/ns-2.26/xerces/lib/libxerces-c.so.27.0) ==19693== by 0x804AE75: Message::serialize() (stl_list.h:172) ==19693== by 0x804BFA9: main (messageTest.cpp:29) |
|
From: Sampath N. R. <sam...@kc...> - 2005-09-22 14:01:14
|
|
From: Julian S. <js...@ac...> - 2005-09-22 09:40:21
|
Is this on x86 or amd64? The new address-space-manager, which will be in 3.1.X, should make this problem go away permanently as it removes various inflexibilities in address space layout. You can try it now: svn co svn://svn.valgrind.org/branches/ASPACEM LMK if it works. J On Thursday 22 September 2005 09:41, smiley glitter wrote: > I have an executable that is 1G in size after debug > recompilation. Valgrind 3.0.1 memcheck fails when > trying to mmap it to read symbols > > typically the following error is seen in log file > > ==22976== Reading syms from <exe> (0x8048000) > ==22976== warning: mmap failed on <exe> > > The following is a hack that shrinks the shadow memory > temporarily to get the executable onboard finishes the > symbol loading and rollsback the changes. > > If you have bigger dlopened shared objects this is not > the right way to go as you may end up loosing part of > the shadow. > > I guess Nick is working on a mechanism to get this > done in a lot more clean and legal way. > > Apply the patch to coregrind/m_debuginfo/symtab.c > > Thanks, > Madhan. > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com |
|
From: smiley g. <smi...@ya...> - 2005-09-22 08:41:44
|
I have an executable that is 1G in size after debug
recompilation. Valgrind 3.0.1 memcheck fails when
trying to mmap it to read symbols
typically the following error is seen in log file
==22976== Reading syms from <exe> (0x8048000)
==22976== warning: mmap failed on <exe>
The following is a hack that shrinks the shadow memory
temporarily to get the executable onboard finishes the
symbol loading and rollsback the changes.
If you have bigger dlopened shared objects this is not
the right way to go as you may end up loosing part of
the shadow.
I guess Nick is working on a mechanism to get this
done in a lot more clean and legal way.
Apply the patch to coregrind/m_debuginfo/symtab.c
Thanks,
Madhan.
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com |
|
From: Terrance <hap...@ya...> - 2005-09-22 05:55:35
|
China World Trade Corporation Reports Record Earnings
Inside Breaking News For Investors
CHINA WORLD TRADE CORP.
Ready to Run
Is This One Ready to Explode Higher Move?
How Will it React To This News Being Released?
Good Luck and Succesful Trading.
CWTD News coming stock is ready to rock Company has already
facilitated the money it need's to continue it's rapid growth
***WATCH THIS ONE SEPT 22, AS WE KNOW MANY OF YOU
LIKE MOMENTUM AND EXCITEMENT***
Timing is everything!!!!!
SYMBOL: CWTD
(Ticker: CWTD)
Price: $2
STATUS: (BUY)
RATING: 3-STAR
Good day to all broker's, Day Trader's and Investor's World stock report
has become famous with some great stock picks in the otc, small cap
market's!!! Here at World Stock Report we work on what we here
from the street. Rumor's circulating and keeping the focus
on the company's news. We pick our companies based on there
growth potential. We focus on stocks that have great potential
to move up in price.!!! While giving you liquitity.
HUGE PR campaign expected this week so grab as much as you can.
***PRESS RELEASE***PRESS RELEASE***PRESS RELEASE***PRESS RELEASE***
China World Trade Corporation Reports Record Earnings
in the Second Quarter 2005
China World Trade Corporation (CWTC) has established its business
in three distinct areas: the club and business centers throughout
major cities in China, business travel-related services,
and business value-added services. The Club and Business Center Division
is devoted to the building of the World Trade brand throughout China
via the opening and operating of business clubs in China's major,
positioning the CWTC to act as a platform to facilitate trade
between China and the world markets. The acquisition of CEO
Clubs China Limited ("CEO Clubs") in May 2004 further complements
CWTC's offerings by targeting high-level corporate executives
from premier companies. The Business Traveling Services Division,
New Generation, provides CWTC access to the rapidly growing
travel-related industry. New Generation is a pioneer and market leader
in the travel agency business through its strong network
of ticketing sales operations throughout Southern China.
The Business Value-Added Services Division focuses on value-added services
of credit cards, merchant-related business services, as well
as consultancy services to CWTC members and clients.
Guangdong World Trade Link Information Services Limited ("WTC Link"),
a subsidiary of CWTC, manages the Company's co-branded credit card project
and is an active provider of CRM solutions and services in China.
THIS COMPANY IS DOING INCREDIBLE THINGS. THAY HAVE CASH AND HAVE MADE
GREAT STRATEGIC AQUISITIONS. CURRENT PRICE $1.99. THEY HAVE DROPPED
BIG NEW'S IN THE PAST. WHO'S TO SAY THEY DON'T HAVE ANOTHER BIG ONE.
We see them on the AMEX very shortly.
Do this often enough, and your portfolio can double, even TRIPLE in value.
ds:
Information within this email contains "forward looking statements"
within the meaning of Section 27A of the Securities Act of 1933 and
Section 21B of the Securities Exchange Act of 1934. Any statements that
express or involve discussions with respect to predictions, goals,
expectations, beliefs, plans, projections, objectives, assumptions or
future events or performance are not statements of historical fact and
may be "forward looking statements."
Forward looking statements are based on expectations, estimates and
projections at the time the statements are made that involve a number
of risks and uncertainties which could cause actual results or events
to differ materially from those presently anticipated. Forward looking
statements in this action may be identified through the use of words
such as: "projects", "foresee", "expects", "estimates," "believes,"
"understands" "will", "anticipates," or that by statements indicating
certain actions "may," "could," or "might" occur. All information
provided within this email pertaining to investing, stocks,securities
must be understood as information provided and not investment advice.
Emerging Equity Alert advises all readers and subscribers to seek
advice from a registered professional securities representative before
deciding to trade in stocks featured within this email. None of the
material within this report shall be construed as any kind of
investment advice.
In compliance with Section 17(b), we disclose the holding of shares of
chms prior to the publication of this report. Be aware of an inherent
conflict of interest resulting from such holdings due to our intent
to profit from the liquidation of these shares. Shares may be sold
at any time, even after positive statements have been made regarding
the above company.
|
|
From: Madhan <mad...@or...> - 2005-09-22 03:29:53
|
With a database application like Oracle that uses shared memory heavily the rate of false positives is causing concern. Cross process data initialization is found in almost every piece of data that resides in the shared memory. As memcheck like tools look at the shared memory segment as local memory numerous false positives are generated. The scenario I am referring to here happens when process A copies uninitialized data to shared memory and process B initializes it, later A reads it back. The initialization happening inbetween is not visible to memcheck and hence reports the read by process A as an error. Around 70% of errors reported by Valgrind fall under this category. As such false positives are in the order of 1000s and as filtering them is mostly manual it makes the use of memcheck close to impossible with Oracle. Purify also suffers from the same disadvantage. Making shared memory always defined will be a very simple fix and can be of great help. Any data copied into shared memory becomes automatically defined. The real benefit occurs when the meta data for the shared memory is also shared among processes. All processes sharing the memory will update the meta data. Synchronization is not very important as the original data access should be synchronized. Thanks, Madhan. Tools dev, Server Technologies |
|
From: Richard C. <ric...@pr...> - 2005-09-21 11:09:00
|
Problem solved!!!!!
I've now found the cause of the problem - and I offer my sins up to you
in order to see if I could have used valgrind in a way which would have
caught the problem.
I have a cache for a routine, which used a hash based on a memory
location to see if it had already handled that particular item before.
The code was:
int getKey (); // returns &m_data or something similar
const int cache_size = 127;
static CacheType cache[cache_size];
int entry = (getKey () >> 2) % cache_size;
if (cache[entry] != 0) { ... }
The code didn't fail in valgrind as '&m_data' must always be less than
INT_MAX. However, when running on the machine normally, sometimes
m_data was above INT_MAX and so 'entry' was negative.
It might be asking a lot to have valgrind catch this - but I am
overjoyed that I've finally found the issue!
All the best!
Richard
Richard Corden wrote:
>
> Hi,
>
> One of our tools fails some tests on one of our machines. The
> failures are consistent and reproducible, they are seg 11s, and in
> some cases I get a message from glibc.
>
> *** glibc detected *** free(): invalid pointer: 0x082587f4 ***
>
> These messages always have the same memory address.
>
> The interesting thing is that when I run the same test with valgrind,
> I don't get any failures, and the tools pass the test as expected.
> Initially 'valgrind' found a 'memcpy' with overlapping memory which is
> now fixed but other than that there were no other issues when using
> --tool=memcheck.
>
> The machine is relatively new (Intel Zeon hyper threading P4 3.2GHz)
> and I have had problems keeping it cool, I do get a lot of messages
> from syslogd about passing temperature threshold.
>
> I need to find out if it is the overheating of the CPU or ?something
> else? which causes the failure?
>
> My question is, what could valgrind be doing that might stop the
> problem from occurring?
>
> I've been running using --tool=memcheck, should I try something else?
>
>
> Regards,
>
>
> Richard
>
--
Richard Corden
Programming Research Ltd.
ric...@pr...
+ 44 845 0048478
|
|
From: Stefan O. <so...@ly...> - 2005-09-20 13:55:11
|
I stepped though it with ddd and everything seemed fine, so I guess the debug info is alright. On Mon, 19 Sep 2005, Nicholas Nethercote wrote: > On Mon, 19 Sep 2005, Stefan Ottosson wrote: > > > The program itself is quite exotic. The asm files are generated by another > > program, and don't compute anything useful. The results of the > > computations performed by the generated code are meaningless, > > what is interesting is the execution performance. > > It might be worth trying to work out if the debug info looks like it is > bad, eg. by stepping through it by GDB or some other way. > > Nick > |
|
From: Tom H. <to...@co...> - 2005-09-19 22:04:05
|
In message <BAY...@ph...l>
"laurent de Vito" <l_d...@ho...> wrote:
> I have a Suse 9.3 box running on a Duron processor.
> Valgrind 2.4.1 runs smoothly on a C application compiled with gcc-3.3.5
> and the sole options -g -O0.
> For the same application, Valgrind 3.0.1 stops abruptly with the following :
[ snipped ]
> vex x86->IR: unhandled instruction bytes: 0xD9 0xF4 0xDD 0xD8
Please raise a bug for this on the bug tracker.
Thanks,
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2005-09-19 21:38:57
|
Hi, On Monday 19 September 2005 23:05, Fielder, Todd Patrick wrote: > Hi, > Does anyone know of anyway to annotate Fortran source code...ideally in > Valgrind, but if not, with any other cache profiling tool? as long as your Fortran compiler generates valid debug info (which allows to map instructions to your source file lines), annotation should work with e.g. with cachegrind, callgrind or oprofile either way. They work independant of the programming language. Josef |
|
From: Fielder, T. P. <tp...@sa...> - 2005-09-19 21:05:31
|
Hi, Does anyone know of anyway to annotate Fortran source code...ideally in = Valgrind, but if not, with any other cache profiling tool? Thanks Todd |
|
From: laurent de V. <l_d...@ho...> - 2005-09-19 20:21:55
|
Hallo, I have a Suse 9.3 box running on a Duron processor. Valgrind 2.4.1 runs smoothly on a C application compiled with gcc-3.3.5 and the sole options -g -O0. For the same application, Valgrind 3.0.1 stops abruptly with the following : ==30718== Memcheck, a memory error detector. ==30718== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==30718== Using LibVEX rev 1367, a library for dynamic binary translation. ==30718== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==30718== Using valgrind-3.0.1, a dynamic binary instrumentation framework. ==30718== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==30718== ==30718== My PID = 30718, parent PID = 7238. Prog and args are: ==30718== ./test --30718-- --30718-- Valgrind library directory: /usr/lib/valgrind --30718-- Command line --30718-- ./test --30718-- Startup, with flags: --30718-- --tool=memcheck --30718-- -v --30718-- --leak-check=yes --30718-- --leak-resolution=high --30718-- --show-reachable=yes --30718-- --error-limit=no --30718-- --log-file=log --30718-- Contents of /proc/version: --30718-- Linux version 2.6.11.4-21.9-default (geeko@buildhost) (gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)) #1 Fri Aug 19 11:58:59 UTC 2005 --30718-- Reading syms from /home/laurent/hull/linux/test (0x8048000) --30718-- Reading syms from /lib/ld-2.3.4.so (0x1B8E4000) --30718-- Reading syms from /usr/lib/valgrind/stage2 (0xB0000000) --30718-- Reading suppressions file: /usr/lib/valgrind/default.supp ==30718== --30718-- Reading syms from /usr/lib/valgrind/vg_preload_core.so (0x1B8FC000) --30718-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck.so (0x1B8FF000) --30718-- REDIR: 0x1B8F6B60 (index) redirected to 0x1B902170 (index) --30718-- REDIR: 0x1B8F6D00 (strlen) redirected to 0x1B9023B0 (strlen) --30718-- Reading syms from /home/laurent/hull/linux/libhull.so (0x1B904000) --30718-- Reading syms from /lib/tls/libm.so.6 (0x1B983000) --30718-- Reading syms from /lib/tls/libc.so.6 (0x1B9A6000) --30718-- Reading syms from /lib/libdl.so.2 (0x1BABF000) --30718-- REDIR: 0x1BA0DC90 (rindex) redirected to 0x1B902050 (rindex) --30718-- REDIR: 0x1B8E47A0 (_dl_sysinfo_int80) redirected to 0xB0022343 (???) --30718-- REDIR: 0x1BA0A520 (malloc) redirected to 0x1B90082A (malloc) --30718-- REDIR: 0x1BA0AA70 (realloc) redirected to 0x1B901BBA (realloc) --30718-- REDIR: 0x1BA0B3C0 (calloc) redirected to 0x1B901B0F (calloc) --30718-- REDIR: 0x1BA0D3B0 (strcpy) redirected to 0x1B9023F0 (strcpy) --30718-- REDIR: 0x1BA0EA90 (memset) redirected to 0x1B902AC0 (memset) --30718-- REDIR: 0x1BA0EFB0 (memcpy) redirected to 0x1B9026C0 (memcpy) vex x86->IR: unhandled instruction bytes: 0xD9 0xF4 0xDD 0xD8 ==30718== ==30718== Process terminating with default action of signal 4 (SIGILL) ==30718== Illegal opcode at address 0x1B98C3A4 ==30718== at 0x1B98C3A4: logb (in /lib/tls/libm.so.6) ==30718== by 0x1B909D05: reduce_inner (ch.c:303) ==30718== by 0x1B90A103: reduce (ch.c:339) ==30718== by 0x1B90A494: out_of_flat (ch.c:381) ==30718== by 0x1B908BCF: buildhull (hull.c:328) ==30718== by 0x1B90C3A1: build_convex_hull (ch.c:804) ==30718== by 0x1B90789D: convex_hull (hullmain.c:524) ==30718== by 0x1B912F87: volume_intersect (intersect.c:356) ==30718== by 0x8048A9F: main (test.c:170) --30718-- REDIR: 0x1BA08640 (free) redirected to 0x1B901353 (free) ==30718== ==30718== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 22 from 3) --30718-- --30718-- supp: 3 index-not-intercepted-early-enough-HACK-3 --30718-- supp: 17 dl_relocate_object --30718-- supp: 2 strlen/*dl_map_object*(Cond) ==30718== malloc/free: in use at exit: 3804168 bytes in 44 blocks. ==30718== malloc/free: 116 allocs, 72 frees, 3890016 bytes allocated. ==30718== ==30718== searching for pointers to 44 not-freed blocks. ............................. thanks for the help, regards, Laurent |
|
From: Nicholas N. <nj...@cs...> - 2005-09-19 18:40:02
|
On Mon, 19 Sep 2005, Stefan Ottosson wrote: > The program itself is quite exotic. The asm files are generated by another > program, and don't compute anything useful. The results of the > computations performed by the generated code are meaningless, > what is interesting is the execution performance. It might be worth trying to work out if the debug info looks like it is bad, eg. by stepping through it by GDB or some other way. Nick |
|
From: Stefan O. <so...@ly...> - 2005-09-19 18:01:40
|
The assembly files are compiled by "as" with --gstabs and linked with some C code (which was compiled with gcc -g) gcc -Wall -g -c -o obj/driver.o ... as --gstabs -o obj/test00.o obj/test00.s ar -r obj/test_blocks.a obj/test00.o ... gcc --static-libc -o driver -g -lrt -I. obj/driver.o obj/test_blocks.a ... The program itself is quite exotic. The asm files are generated by another program, and don't compute anything useful. The results of the computations performed by the generated code are meaningless, what is interesting is the execution performance. I'm writing my final thesis on a data prefetching technique, which I intend to evaluate using the above program. I'm mostly interested in the data cache, so I'll ignore the error message for now. I'll probably try oprofile later on, for "real" data. On Mon, 19 Sep 2005, Nicholas Nethercote wrote: > Cachegrind annotation is only as good as the debug info present in the > binary. Often it's not very exact, so that could be the problem. > It's interesting that you're annotating the asm. What command line are > you assembling with? > Cachegrind doesn't simulate trace caches accurately. So it just simulates > a normal I-cache instead. The overall results will still be indicative of > your program's cache behaviour in general, but don't expect it to match > the exact results you'd get on the real hardware. |
|
From: Federico F. <fli...@ya...> - 2005-09-19 17:32:05
|
Hi everyone. Im having problems running with valgrind programs that use the shared library of db2 (libdb2.so). I dont know exactly whats going on, but when I run my program under valgrind, the program seems not to be running, I mean, it looks halted. I know that valgrind slow down programs, but this is too much. Im sure something wrong is going on. I Is it possible to exclude the library so it wont be checked by valgrind? I have the feeling that what is taking so long to execute is code from the library... When i give up waiting the program to finish I get this problem on the log ==19595== Invalid free() / delete / delete[] ==19595== at 0x1B8FF54C: free (vg_replace_malloc.c:235) ==19595== by 0x1CAB4EAB: free_mem (in /lib/tls/libc-2.3.2.so) ==19595== by 0x1CAB4AB4: __libc_freeres (in /lib/tls/libc-2.3.2.so) ==19595== by 0x1B8FB876: _vgw_freeres (vg_preloaded.c:62) ==19595== by 0x1CAD5897: (within /lib/tls/libc-2.3.2.so) ==19595== by 0x1CA0B536: _IO_file_fopen@@GLIBC_2.1 (in /lib/tls/libc-2.3.2.so) ==19595== by 0x1CA00EB0: __fopen_internal (in /lib/tls/libc-2.3.2.so) ==19595== by 0x1CA00F0D: fopen@@GLIBC_2.1 (in /lib/tls/libc-2.3.2.so) ==19595== by 0x1BF4903C: EnvOpenFile(_IO_FILE**, char const*, char const*, int) (in /opt/IBM/db2/V8.1/lib/libdb2.so.1) ==19595== by 0x1BF46813: EnvRegRefresh(_senvregistry*) (in /opt/IBM/db2/V8.1/lib/libdb2.so.1) ==19595== by 0x1BF46521: EnvRegOpen(_senvregistry**) (in /opt/IBM/db2/V8.1/lib/libdb2.so.1) ==19595== by 0x1BF43B2B: sqloPRegQueryDefaultValue(int, char*, char const*) (in /opt/IBM/db2/V8.1/lib/libdb2.so.1) ==19595== Address 0x1CE4D650 is not stack'd, malloc'd or (recently) free'd thanks Fede __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com |