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
|
2
(7) |
3
(4) |
4
(6) |
5
(6) |
6
(4) |
|
7
|
8
(6) |
9
|
10
|
11
(10) |
12
(5) |
13
(2) |
|
14
(3) |
15
(3) |
16
(14) |
17
(7) |
18
(7) |
19
(5) |
20
(4) |
|
21
(5) |
22
(5) |
23
(3) |
24
(11) |
25
(5) |
26
(9) |
27
(5) |
|
28
(2) |
29
(7) |
30
(3) |
31
(2) |
|
|
|
|
From: Hourigan, E. <edw...@lm...> - 2004-03-24 23:12:42
|
I have a C++ app built w/ gcc 2.95.2. When it attemtpts to open a simple asc-ii file using fstream class, it hangs. Do I have to do anything special when using the C++ iostream classes? Thanks! Ed Hourigan Lockheed Martin Maritime Systems & Sensors P.O. Box 4840, EP7 6X19, MD60 Syracuse, NY 13221-4840 (315)456-2294 (Phone), (315)456-0149 (FAX) |
|
From: Alison Z. <ali...@au...> - 2004-03-24 21:12:58
|
Dear All, Thanks very much for your clear explaination. I have solved the problem now. Cheers Alison ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ |
|
From: Josef W. <Jos...@gm...> - 2004-03-24 12:41:41
|
On Tuesday 23 March 2004 14:54, Avery Pennarun wrote:
> On Tue, Mar 23, 2004 at 01:00:18PM +0100, Josef Weidendorfer wrote:
> > So the conversion would have to calculate inclusive costs from the self
> > cost of contexts.
>
> Sounds easy enough...
>
> > Another thing: doesn't massif provide the difference "Allocated" -
> > "Deallocated"? I'm not quite sure how to handle this.
>
> Well, it actually provides the continuous sum of allocated-deallocated over
> the runtime of the program. But that doesn't matter: the point is it
> provides just one major number per context ("the spacetime"), which we
> ought to be able to view in kcachegrind like the other numbers (cache
> misses, CPU cycles, etc).
You are right. It's only a matter of writing a conversion script from massif
data (raw/ASCII ?) to cachegrind/calltree format.
KCachegrind should be able to cope with multiple cachegrind/calltree simple
concatenated together (for multiple consensi). The format is described in a
HTML documentation in the calltree package.
Any volunteers?
Cheers,
Josef
>
> Have fun,
>
> Avery
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Henrik N. <hn...@ma...> - 2004-03-24 09:17:07
|
On Wed, 24 Mar 2004, RAMPARANY Fano FTRD/DIH/GRE wrote: > Does valgrind detect illegal access to statically allocated memory? Only if you pad the variable with inaccessible data. Normally the compiler packs static variables together in the data segment, so valgrin can not detect such misuse as for all valgrind knows you are accessing the next static variable.. (or more exactly some data in the static data segment of your application) You can however manually instrument your program to add suitable "red" zones arount suspectible variables just like valgrind automatically does on malloc:ed memory. See the "Client Requests" section in the memcheck chapter. But in many cases it is simpler to just allocate the variables with malloc instead as assays and pointers are semantically equivalent in C (except for sizeof).. converting to malloc also makes it possible for valgrind to guess what you intended to access in it's error report Regards Henrik |
|
From: Tom H. <th...@cy...> - 2004-03-24 08:53:48
|
In message <429...@ft...>
RAMPARANY Fano <fan...@fr...> wrote:
> Does valgrind detect illegal access to statically allocated memory?
>
> e.g. valgrind doesn't report any error on the following code:
>
> ...
> int mytable[5];
> ...
> mytable[6] = mytable[7];
> ...
That isn't statically allocated, it's allocated on the stack.
In general valgrind will not be able to detect stack overruns like
this. Although it will warn about the use of uninitialised values from
the stack, any value above the current stack point is considered
accessible and therefore writable.
It is in fact virtually impossible to spot the kind of error you show
with a purely run time instrumenter, as you would normally need to add
padding between the variables at compile time to detect the overruns.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: RAMPARANY F. FTRD/DIH/G. <fan...@fr...> - 2004-03-24 08:43:25
|
Does valgrind detect illegal access to statically allocated memory? e.g. valgrind doesn't report any error on the following code: ... int mytable[5]; ... mytable[6] =3D mytable[7]; ... |
|
From: RAMPARANY F. FTRD/DIH/G. <fan...@fr...> - 2004-03-24 08:27:30
|
Thank you for your help. Here is the output of gcc -v (note that while installing valgrind, I had To run "configure" with the commandline argument "CC=3Dgcc" otherwise it failed with the error appended below)=20 ----gcc -v thread.c -lpthread trace-------- Reading specs from /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2/specs Configured with: ../configure --prefix=3D/usr --libdir=3D/usr/lib --with-slibdir=3D/lib --mandir=3D/usr/share/man = --infodir=3D/usr/share/info --enable-shared --enable-threads=3Dposix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=3Dc,c++,ada,f77,objc,java --host=3Di586-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk) /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2/cc1 -lang-c -v -iprefix /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2/ -D__GNUC__=3D3 -D__GNUC_MINOR__=3D2 -D__GNUC_PATCHLEVEL__=3D0 -D__GXX_ABI_VERSION=3D102 -D__ELF__ -Dunix -D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux -Asystem=3Dposix -D__NO_INLINE__ -D__STDC_HOSTED__=3D1 -Acpu=3Di386 -Amachine=3Di386 -Di386 -D__i386 -D__i386__ -D__tune_i586__ -D__tune_pentium__ thread.c -quiet -dumpbase thread.c -version -o /user/nfs2/ramparfa/unix/tmp/ccd3fGYe.s GNU CPP version 3.2 (Mandrake Linux 9.0 3.2-1mdk) (cpplib) (i386 Linux/ELF) GNU C version 3.2 (Mandrake Linux 9.0 3.2-1mdk) (i586-mandrake-linux-gnu) compiled by GNU C version 3.2 (Mandrake Linux 9.0 3.2-1mdk). ignoring nonexistent directory "/usr/i586-mandrake-linux-gnu/include" ignoring nonexistent directory "/usr/i586-mandrake-linux-gnu/include" ignoring duplicate directory "/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include /usr/local/include /usr/include End of search list. as -V -Qy -o /user/nfs2/ramparfa/unix/tmp/ccerqw8l.o /user/nfs2/ramparfa/unix/tmp/ccd3fGYe.s GNU assembler version 2.12.90.0.15 (i586-mandrake-linux-gnu) using BFD version 2.12.90.0.15 20020717 /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2/../../../crt1.o /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2/../../../crti.o /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2/crtbegin.o -L/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2 -L/usr//bin/../lib/gcc-lib -L/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2 -L/usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2/../../.. -L/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/../../.. /user/nfs2/ramparfa/unix/tmp/ccerqw8l.o -lpthread -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2/crtend.o /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2/../../../crtn.o ------configure.log------------- ... configure:1777: checking for gcc configure:1803: result: acc configure:2047: checking for C compiler version configure:2050: acc --version </dev/null >&5 configure: line 1: acc: command not found configure:2053: $? =3D 127 configure:2055: acc -v </dev/null >&5 configure: line 1: acc: command not found configure:2058: $? =3D 127 configure:2060: acc -V </dev/null >&5 configure: line 1: acc: command not found configure:2063: $? =3D 127 configure:2087: checking for C compiler default output configure:2090: acc conftest.c >&5 configure: line 1: acc: command not found configure:2093: $? =3D 127 configure: failed program was: | #line 2066 "configure" | /* confdefs.h. */ |=20 | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "": -----Message d'origine----- De : Jeremy Fitzhardinge [mailto:je...@go...]=20 Objet : Re: [Valgrind-users] Re: RE : Pthread problems... Quoting Nicholas Nethercote <nj...@ca...>: >... > So it's not a problem with your program; I think it's a problem with=20 > Valgrind or gcc or libc or a combination. Unfortunately, I'm no=20 > expert on the segment-override stuff and can't help your further. =20 > I've cc'd the valgrind-users list in case anyone else knows more. The clear problem here is that the client is still picking up /lib/i686/ libpthread-0.9.so for some reason. I wonder if the program is being linked with=20 -Wl,-rpath,/lib or something. Or perhaps something is unsetting/resetting=20 LD_LIBRARY_PATH. Or maybe the toolchain, for whatever reason, just ignores=20 LD_LIBRARY_PATH. The output of gcc -v while linking would be interesting. |
|
From: Esben M. H. <es...@de...> - 2004-03-24 06:59:50
|
=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 24 March 2004 02:50, Alison Zhang wrote:
> It is related to the previous error which is:
>
> =3D=3D1821=3D=3D Mismatched free() / delete / delete []
> =3D=3D1821=3D=3D at 0x4002BEE7: __builtin_delete (vg_replace_malloc.c:=
244)
> =3D=3D1821=3D=3D by 0x81509B6: CimGraphixLineSet::~CimGraphixLineSet(v=
oid)
> (CimModel/CimGraphix/CimGraphixLineSet.C:263)
>
> this code is:
> int pl;
>
> for (pl=3D0;pl<np;pl++)
> {
> delete pts[pl];
> }
> delete pts; //in destructor
> code in constructor: float **pts; pts =3D new float*[np];
> I quess the way i delete arrays is not correct, i am java programmer.
> Please give me some hint how to delete various kinds of arrays in c.
Having worked with several Java programmers in the past, I agree: you show =
all=20
the signs of Java->C++ conversion ;-) Several points:
1. You don't need or want to call new() every time you want to construct an=
=20
object. Use of new is association; if you want composition use=20
class myclass {
CompositeClass composition;
};
instead. Local variables should almost never be allocated with new.
2. Dynamic arrays are best handled with a helper object. The C++ standard=20
library (STL) and QT each comes with their own. These are std::vector (STL)=
,=20
QValueVector (QT) and QPtrVector (QT). I suggest you look into these.
3. To answer you question, here's a program that does the dynamic array thi=
ng:
#include <vector>
int main() {
int noelements =3D 5;
// creating an array
int* array =3D new int[noelements];
// deleting an array
delete[] array;
// it's better to use a vector
std::vector<int> better_array(5);
// vectors are objects, and thus takes care of their=20
// own cleanup during destruction.
return 0;
}
=2D --=20
regards, Esben
Homepage: http://www.mosehansen.dk
Signature fingerprint at http://www.mosehansen.dk/about
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAYTIvrfnftt13wXIRAiIAAJ9LxgZh/yKTyjxtbZkwp82dUyBNwgCeM7lT
=46ee+79aj0CGHStE1bbOtuDU=3D
=3DxKJy
=2D----END PGP SIGNATURE-----
|
|
From: Alison Z. <ali...@au...> - 2004-03-24 01:54:34
|
It is related to the previous error which is:
==1821== Mismatched free() / delete / delete []
==1821== at 0x4002BEE7: __builtin_delete (vg_replace_malloc.c:244)
==1821== by 0x81509B6: CimGraphixLineSet::~CimGraphixLineSet(void)
(CimModel/CimGraphix/CimGraphixLineSet.C:263)
this code is:
int pl;
for (pl=0;pl<np;pl++)
{
delete pts[pl];
}
delete pts; //in destructor
code in constructor: float **pts; pts = new float*[np];
I quess the way i delete arrays is not correct, i am java programmer.
Please give me some hint how to delete various kinds of arrays in c.
Thanks very much,
Alison
|
|
From: Alison Z. <ali...@au...> - 2004-03-24 01:38:26
|
Hi Avery, Thanks for reply. The 'entire' error is: ==1821== Address 0x44FA1BFC is 0 bytes inside a block of size 40 alloc'd ==1821== at 0x4002BD5C: __builtin_vec_new (vg_replace_malloc.c:203) ==1821== by 0x81508E9: CimGraphixLineSet::CimGraphixLineSet(int, Cim3DTransform &) (CimModel/CimGraphix/CimGraphixLineSet.C:241) ==1821== by 0x815A747: CimModelLVPS4x4::getModelImageIntersections(int, int, Cim3DVector *, Cim3DVector *) (CimModel/CimModel/CimModelLVPS4x4.C:1882) ==1821== by 0x816266F: CimModeller::getModelImageIntersections(int, int, int, Cim3DVector *, Cim3DVector *) (CimModel/CimModel/CimModeller.C:1050) np = nPlanes; //nPlanes is a constructor prameter pts = new float*[np]; those lines are in the constructor of CimGraphixLineSet cheers Alison |
|
From: Alison Z. <ali...@au...> - 2004-03-24 00:22:33
|
Hello All, I got the above error message when i run my program under valgrind. I do not quite understand what is wrong with my code: float **pts //defined in header file np = nPlanes; //nPlanes is a constructor prameter pts = new float*[np]; //this line is in constructor, it causes the above error Can anyone please tell me what is wrong here. Thanks a lot |