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
(4) |
|
2
|
3
(1) |
4
|
5
(2) |
6
(1) |
7
(3) |
8
(1) |
|
9
|
10
(9) |
11
(9) |
12
(10) |
13
(2) |
14
|
15
|
|
16
(1) |
17
(9) |
18
(5) |
19
(17) |
20
|
21
(5) |
22
|
|
23
|
24
(17) |
25
(8) |
26
(7) |
27
(10) |
28
(11) |
29
(1) |
|
30
|
31
(6) |
|
|
|
|
|
|
From: Chris S. <c.s...@co...> - 2005-01-12 20:29:06
|
Is there a way to make valgrind report the _read_ of an uninitialized value instead of waiting until a conditional jump depends on it? I think that would make it easier to find out how I got to the point where the jump depends on it. -chris |
|
From: Chris S. <c.s...@co...> - 2005-01-12 20:23:40
|
On Wed, Jan 12, 2005 at 12:49:23PM -0600, Yardumian, Hrant (HEYA) (hrant) wrote: > > I am trying to use Valgrind on an executable that's built with the -g > option, yet Valgrind complains that it cannot load the debug info and > symbols. (see sample output below.) > > As a result, Valgrind output will not give me exact locations of > problems. > > Are there any settings other than -g that I need when building my > executable? > > Thanks - > You should show the command line used to execute valgrind. What version are you using? > > > ==30298== Reading syms from > /.automount/zion/d/a/data/intersect/build/build_with_debug/ix/unit_test/ > simulator_test/simulator_test_simulator_test_main.exe (0x8048000) > ==30298== warning: mmap failed on Why is the mmap failing? > /.automount/zion/d/a/data/intersect/build/build_with_debug/ix/unit_test/ > simulator_test/simulator_test_simulator_test_main.exe > ==30298== no symbols or debug info loaded > ==30298== Reading syms from /lib/ld-2.2.5.so (0x1B8E4000) > ==30298== object doesn't have any debug info > ==30298== Reading syms from > /.automount/izu/vol/vol0/rpo_rpp_q1/intersect/users/liko/valgrind-2.2.0/ > lib/valgrind/stage2 (0xB0000000) > ==30298== Reading syms from /lib/ld-2.2.5.so (0xB1000000) > ==30298== object doesn't have any debug info > ==30298== Reading syms from /lib/libdl-2.2.5.so (0xB1031000) > ==30298== object doesn't have any debug info > ==30298== Reading syms from /lib/i686/libc-2.2.5.so (0xB1035000) > ==30298== object doesn't have any debug info > > Hrant Yardumian > ChevronTexaco - ETC > Reservoir Simulation Research - INTERSECT Team > 4800 Fournace Pl., Rm E-561 > Bellaire, TX 77401-2324 > > Tel : (713) 432-2816 > Mobile : (281) 782-8669 > Fax : (713) 432-6620 > |
|
From: Yardumian, H. (H. (hrant) <hr...@ch...> - 2005-01-12 18:49:42
|
I am trying to use Valgrind on an executable that's built with the -g option, yet Valgrind complains that it cannot load the debug info and symbols. (see sample output below.) As a result, Valgrind output will not give me exact locations of problems. Are there any settings other than -g that I need when building my executable? Thanks - =3D=3D30298=3D=3D Reading syms from /.automount/zion/d/a/data/intersect/build/build_with_debug/ix/unit_test/ simulator_test/simulator_test_simulator_test_main.exe (0x8048000) =3D=3D30298=3D=3D warning: mmap failed on /.automount/zion/d/a/data/intersect/build/build_with_debug/ix/unit_test/ simulator_test/simulator_test_simulator_test_main.exe =3D=3D30298=3D=3D no symbols or debug info loaded =3D=3D30298=3D=3D Reading syms from /lib/ld-2.2.5.so (0x1B8E4000) =3D=3D30298=3D=3D object doesn't have any debug info =3D=3D30298=3D=3D Reading syms from /.automount/izu/vol/vol0/rpo_rpp_q1/intersect/users/liko/valgrind-2.2.0/ lib/valgrind/stage2 (0xB0000000) =3D=3D30298=3D=3D Reading syms from /lib/ld-2.2.5.so (0xB1000000) =3D=3D30298=3D=3D object doesn't have any debug info =3D=3D30298=3D=3D Reading syms from /lib/libdl-2.2.5.so (0xB1031000) =3D=3D30298=3D=3D object doesn't have any debug info =3D=3D30298=3D=3D Reading syms from /lib/i686/libc-2.2.5.so (0xB1035000) =3D=3D30298=3D=3D object doesn't have any debug info Hrant Yardumian ChevronTexaco - ETC Reservoir Simulation Research - INTERSECT Team 4800 Fournace Pl., Rm E-561 Bellaire, TX 77401-2324 Tel : (713) 432-2816 =20 Mobile : (281) 782-8669 Fax : (713) 432-6620 |
|
From: Olly B. <ol...@su...> - 2005-01-12 16:06:07
|
On 2005-01-12, Chris Shoemaker <c.s...@co...> wrote:
> I don't know what's special about gdb 6.1-debian, but a stock gdb 6.3
> also fixes this problem. Sorry for the noise.
Debian often patch software when packaging, to fix bugs which haven't
been fixed in an upstream release yet, or backporting important fixes
(most notably security fixes) to versions of the software in the stable
distribution.
So if you look in the debian patches for gdb 6.1, you'll probably find
a patch to fix this problem, which was either backported from 6.2 or
6.3, or has been submitted upstream and included in 6.2 or 6.3.
Cheers,
Olly
|
|
From: Chris S. <c.s...@co...> - 2005-01-12 14:52:10
|
On Tue, Jan 11, 2005 at 04:57:40PM -0500, Chris Shoemaker wrote: > On Tue, Jan 11, 2005 at 04:22:39PM -0500, Chris Shoemaker wrote: > > > > Now: perhaps I'm doing something dumb, but is there some way I can > > preserve stack frame info when I attach gdb? > <snip self> > > > > [chris@badger2 test]$ gdb a.out > > GNU gdb Red Hat Linux (6.1post-1.20040607.43rh) > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1". > > After doing a bit more testing, I discovered that changing gdb versions makes a difference. > gdb that came with FC1, gdb-5.3.90-0.20030710.41.i386.rpm, shows stack info. > gdb that came with FC2, gdb-6.0post-0.20040223.19.i386.rpm, DOESN'T. > and neither does the more recent, (6.1post-1.20040607.43rh) > > However, on a debian box, (gdb 6.1-debian), has no problem. I guess I > should find the gdb mailing list, huh? I don't know what's special about gdb 6.1-debian, but a stock gdb 6.3 also fixes this problem. Sorry for the noise. -chris |
|
From: vinod k. <sar...@gm...> - 2005-01-12 07:22:32
|
Hi, I get a lot of "..unlikely looking definition in unparsed remains.." when I use valgrind. Googling for the same, it seems like its a minor error that has been fixed in the valgrind cvs version. Its more annoying than anything else. I would like to use the cvs version of valgrind, but I am sitting behind a proxy server that requires authentication. Using Gcvs does not allow me to connect via a proxy that requires authentication ( or does it? or is there any other cvs tool that allows me to access your repos via a proxy server that requires authentication?). I guess my question is when I can see the fixed version for regular download? Or an answer to the previous question of accessing cvs repos via proxy with authentication ( albeit not pertaining to this forum) would be most helpful. TIA Vinod |
|
From: Alison Z. <ali...@au...> - 2005-01-12 01:08:42
|
Hi Dennis, I have checked the errors shown, most of them are errors from library which i can do nothing. I remember when i run valgrind before, it did show me lots lots of errors. Why dose not it show me all the errors even if i added error-limit=no? Any other way to make it show all the errors? Cheers Alison Dennis Lubert wrote: > At 23:41 11.01.2005, Alison Zhang wrote: > >> Hi, >> I am trying to check memory leak problem of my C program in linux. >> And here is the result >> >> ==11795== More than 30000 total errors detected. I'm not reporting >> any more. >> ==11795== Final error counts will be inaccurate. Go fix your program! >> ==11795== Rerun with --error-limit=no to disable this cutoff. Note >> ==11795== that errors may occur in your program without prior warning >> from >> ==11795== Valgrind, because errors are no longer being displayed. >> ==11795== >> ==11795== FATAL: M_PROCMAP_BUF is too small; increase it and recompile >> >> Then the program just exited here. >> Could someone please tell me how to fix this problem. > > > First fix all the errors in your program valgrind reported, then other > errors like this will mostly disappear... > > > Carpe quod tibi datum est > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Dennis L. <pla...@in...> - 2005-01-12 00:36:49
|
At 23:41 11.01.2005, Alison Zhang wrote: >Hi, >I am trying to check memory leak problem of my C program in linux. And >here is the result > >==11795== More than 30000 total errors detected. I'm not reporting any more. >==11795== Final error counts will be inaccurate. Go fix your program! >==11795== Rerun with --error-limit=no to disable this cutoff. Note >==11795== that errors may occur in your program without prior warning from >==11795== Valgrind, because errors are no longer being displayed. >==11795== >==11795== FATAL: M_PROCMAP_BUF is too small; increase it and recompile > >Then the program just exited here. >Could someone please tell me how to fix this problem. First fix all the errors in your program valgrind reported, then other errors like this will mostly disappear... Carpe quod tibi datum est |
|
From: Tom H. <th...@cy...> - 2005-01-12 00:07:49
|
In message <E08...@ha...>
"Yasin, Ahmad" <ahm...@in...> wrote:
> Sorry in advance if I missed some regulation. I'm a new to this system.
>
> Can you help me whether this issue was resolved or not? In which
> version?
Which issue? There are several different issues discussed in
the mailing list thread that you referre to.
> Nicholas, What do you mean by "Done" in this reply?
> http://sourceforge.net/mailarchive/message.php?msg_id=7025790
>
> In the latest 2.2.0 version the 2 assertions still occur to me
> eventhough VKI_CLONE_PARENT_SETTID is included in PRE(clone) in
> coregrind/vg_syscalls.c.
Which assertion? The "Done" referred to the fork problem which
caused the "unimplemented clone" message. That isn't actually
an assertion.
If you mean the assertion mentioned in the first messages of the
thread then I think that is fixed, but I'm not sure what version
it is in.
If you have a current problem, then please submit a bug with the
details.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Yasin, A. <ahm...@in...> - 2005-01-11 22:45:25
|
Hi, Sorry in advance if I missed some regulation. I'm a new to this system. Can you help me whether this issue was resolved or not? In which version? Nicholas, What do you mean by "Done" in this reply? http://sourceforge.net/mailarchive/message.php?msg_id=3D7025790 In the latest 2.2.0 version the 2 assertions still occur to me eventhough VKI_CLONE_PARENT_SETTID is included in PRE(clone) in coregrind/vg_syscalls.c. Also I tried just to disable them as suggested at the beginning of the thread and it finally leads to segmentation fault. Any idea, Thanks in advance, Ahmad |
|
From: Alison Z. <ali...@au...> - 2005-01-11 22:41:31
|
Hi, I am trying to check memory leak problem of my C program in linux. And here is the result ==11795== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==11795== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==11795== Using valgrind-2.0.0, a program supervision framework for x86-linux. ==11795== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==11795== ==11795== My PID = 11795, parent PID = 9058. Prog and args are: ==11795== ./cim ==11795== Estimated CPU clock rate is 3076 MHz ==11795== For more details, rerun with: -v ==11795== ==11795== Syscall param modify_ldt(ptr)(func=1 or 0x11) contains uninitialised or unaddressable byte(s) ==11795== at 0x405DF0D8: (within /usr/lib/libGL.so.1.0.5336) ==11795== Address 0xBFFFEF90 is on thread 1's stack ==11795== ==11795== Source and destination overlap in memcpy(0x43b053f8, 0x43b053f8, 4) ==11795== at 0x4002473A: memcpy (mac_replace_strmem.c:95) ==11795== by 0x40423163: (within /usr/X11R6/lib/libXt.so.6.0) ==11795== by 0x40423586: _XtGetResources (in /usr/X11R6/lib/libXt.so.6.0) ==11795== by 0x4040EE8C: (within /usr/X11R6/lib/libXt.so.6.0) ==11795== ==11795== Source and destination overlap in memcpy(0x43b16618, 0x43b16618, 4) ==11795== at 0x4002473A: memcpy (mac_replace_strmem.c:95) ==11795== by 0x40423163: (within /usr/X11R6/lib/libXt.so.6.0) ==11795== by 0x40423821: _XtGetSubresources (in /usr/X11R6/lib/libXt.so.6.0) ==11795== by 0x404238EA: XtGetSubresources (in /usr/X11R6/lib/libXt.so.6.0) ==11795== ==11795== Use of uninitialised value of size 8 ==11795== at 0x81A56CE: CompColMatVec_double(int, int, int, double const &, double const *, int const *, int const *, double const *, int, double *, int) (spmm.cc:140) ==11795== by 0x81A69AA: dcscmm_ (spmm.cc:567) ==11795== by 0x819F773: CompCol_Mat_double::operator*(MV_Vector_double const &) const (compcol_double.cc:289) ==11795== by 0x8173053: CimModelRVLVFFD::calcLocalParams(int) (CimModel/CimModel/CimModelRVLVFFD.C:393) ==11795== ==11795== More than 30000 total errors detected. I'm not reporting any more. ==11795== Final error counts will be inaccurate. Go fix your program! ==11795== Rerun with --error-limit=no to disable this cutoff. Note ==11795== that errors may occur in your program without prior warning from ==11795== Valgrind, because errors are no longer being displayed. ==11795== ==11795== FATAL: M_PROCMAP_BUF is too small; increase it and recompile Then the program just exited here. Could someone please tell me how to fix this problem. Thanks a lot. Alison |
|
From: Chris S. <c.s...@co...> - 2005-01-11 21:57:14
|
On Tue, Jan 11, 2005 at 04:22:39PM -0500, Chris Shoemaker wrote: > > Now: perhaps I'm doing something dumb, but is there some way I can > preserve stack frame info when I attach gdb? <snip self> > > [chris@badger2 test]$ gdb a.out > GNU gdb Red Hat Linux (6.1post-1.20040607.43rh) > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1". After doing a bit more testing, I discovered that changing gdb versions makes a difference. gdb that came with FC1, gdb-5.3.90-0.20030710.41.i386.rpm, shows stack info. gdb that came with FC2, gdb-6.0post-0.20040223.19.i386.rpm, DOESN'T. and neither does the more recent, (6.1post-1.20040607.43rh) However, on a debian box, (gdb 6.1-debian), has no problem. I guess I should find the gdb mailing list, huh? -chris |
|
From: Chris S. <c.s...@co...> - 2005-01-11 21:22:11
|
First off: I _love_ valgrind. This is an amazingly ambitious piece of
software and it is incredibly useful and useable. My thanks to the developer(s)!
Now: perhaps I'm doing something dumb, but is there some way I can
preserve stack frame info when I attach gdb?
For example:
[chris@badger2 test]$ cat a.c
int main (int argc, char ** argv)
{
free((void *) 0xbadbad);
return 0;
}
[chris@badger2 test]$ gcc -o a.out a.c
[chris@badger2 test]$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
[I've tried this with gcc 3.3, too, with same results.]
[chris@badger2 test]$ gdb a.out
GNU gdb Red Hat Linux (6.1post-1.20040607.43rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) r
Starting program: /home/chris/gnucash/gnucash/src/gnome-utils/test/a.out
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0xf6f0eab9 in free () from /lib/tls/libc.so.6
(gdb) bt
#0 0xf6f0eab9 in free () from /lib/tls/libc.so.6
#1 0x08048391 in main ()
(gdb) q
The program is running. Exit anyway? (y or n) y
[Obviously, the symbols are there.]
[chris@badger2 test]$ valgrind --tool=none --db-attach=yes a.out
==23865== Nulgrind, a binary JIT-compiler for x86-linux.
==23865== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote.
==23865== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==23865== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==23865== For more details, rerun with: -v
==23865==
==23865==
==23865== Process terminating with default action of signal 11 (SIGSEGV)
==23865== Access not within mapped region at address 0xBADBA9
==23865== at 0x3A9F6AB9: free (in /lib/tls/libc-2.3.4.so)
==23865== by 0x8048390: main (in /home/chris/gnucash/gnucash/src/gnome-utils/test/a.out)
==23865==
[ I notice that symbol name and locations are good. Curious about 0xBADBA9 vs. 0xbadbad. ]
==23865== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
==23865== starting debugger with cmd: /usr/bin/gdb -nw /proc/23867/fd/821 23867
GNU gdb Red Hat Linux (6.1post-1.20040607.43rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1".
Attaching to program: /proc/23867/fd/821, process 23867
0x3a9f6ab9 in ?? ()
(gdb) bt
#0 0x3a9f6ab9 in ?? ()
#1 0x3a970a80 in ?? ()
#2 0x3aabd15c in ?? ()
#3 0x3aabaff4 in ?? ()
#4 0xafefe9b4 in ?? ()
#5 0xafefe940 in ?? ()
#6 0xafefe928 in ?? ()
#7 0x08048391 in main ()
[ very unhelpful, even main() is off-by-one, no? ]
(gdb) q
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: /proc/23867/fd/821, process 23867
==23865==
==23865== Debugger has detached. Valgrind regains control. We continue.
==23865==
Segmentation fault
[chris@badger2 test]$ valgrind --version
valgrind-2.2.0
[If this is a bug in valgrind, I'm willing to test patches, although,
my setup is probably reproducible, (FedoraCore3)]
-chris
|
|
From: Jess A. M. <ja...@me...> - 2005-01-11 16:48:18
|
Hi everyone! Im a newbie to valgrind. I downloaded valgrind in order to track down a memory leak in a huge MPI program. However, before I got that far, I performed the test valgrind --tool=memcheck ls -lrt which responded as expected, i.e. as described in the documentation. After that, I was not able to open windows with Nedit, gnome-terminal, etc. After a while, I began to wonder, what was running on the machine and discovered that valgrind was still running - it had consumed more than two gig, and used 99.9% CPU. What is worse - valgrind does not repond to Ctrl-C or kill -9 <PID>. How do I stop valgrind. Rebooting is not an option, since the computer is the login node for a large installation. Best regards, Jess Michelsen |
|
From: <oli...@on...> - 2005-01-11 15:44:13
|
Bob Rossi <bo...@br...> schrieb am 11.01.2005, 14:13:26: > On Tue, Jan 11, 2005 at 09:20:02AM +0100, oli...@on... wrote: > > > > I checked out the actual CVS source and tried to ran the autogen.sh, but > > I got the following error: > > > > : bad interpreter: No such file or directory > > > > So I ran all the autoconf/automake stuff manually and then I tried to > > the configure and it exited at the following messages: > > > > configure: creating ./config.status > > config.status: creating Makefile > > config.status: creating > > .infig.status: error: cannot find input file: > > > > There seems something to go obviously wrong. Anybody can help me there? > > I'm just guessing, but I don't think this has anything to do with > valgrind, it could simply just be a configuration error on your point > with autoconf. Hmm...is there so much, that can be wrong. As I said I ran all from the autogen.sh manually and those are just 4 commands and only one has a parameter. I assumed everything should be fine after that. > Are you trying to compile this on windows? (cygwin) Nope, it's a linux box. The 2.2.0 release built fine. |
|
From: Bob R. <bo...@br...> - 2005-01-11 13:13:56
|
On Tue, Jan 11, 2005 at 09:20:02AM +0100, oli...@on... wrote: > > I checked out the actual CVS source and tried to ran the autogen.sh, but > I got the following error: > > : bad interpreter: No such file or directory > > So I ran all the autoconf/automake stuff manually and then I tried to > the configure and it exited at the following messages: > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating > .infig.status: error: cannot find input file: > > There seems something to go obviously wrong. Anybody can help me there? I'm just guessing, but I don't think this has anything to do with valgrind, it could simply just be a configuration error on your point with autoconf. Are you trying to compile this on windows? (cygwin) Bob Rossi |
|
From: Piotr <ko...@ad...> - 2005-01-11 09:51:35
|
On Mon, Jan 10, 2005 at 08:45:03PM +0000, Nicholas Nethercote wrote: > On Mon, 10 Jan 2005, Piotr [iso-8859-2] Pi?tkowski wrote: >=20 > >Maybe someone has already prepared such patch? Or should I try to ma= ke it > >myself? >=20 > Someone has written a patch, it may be somewhere in the bugs database= --=20 > have a search there (see valgrind.kde.org/bugs.html). Thank you, I've found it and I fixed this patch to compile with version 2.2.0 - looks that it works fine: http://bugs.kde.org/show_bug.cgi?id=3D72649#c2 Why isn't it included in the official distribution? --=20 Piotr Pi=B1tkowski, Onet.pl SA, Krak=F3w [= PT/SH] perl -le 's**02).4&\*534^[./4(%2^0%2,^([#+%2&**y%& -;^[%"`-{ a%%s%%$_%e= e' |
|
From: <oli...@on...> - 2005-01-11 08:22:07
|
I checked out the actual CVS source and tried to ran the autogen.sh, but I got the following error: : bad interpreter: No such file or directory So I ran all the autoconf/automake stuff manually and then I tried to the configure and it exited at the following messages: configure: creating ./config.status config.status: creating Makefile config.status: creating .infig.status: error: cannot find input file: There seems something to go obviously wrong. Anybody can help me there? |
|
From: Nicholas N. <nj...@ca...> - 2005-01-10 20:45:08
|
On Mon, 10 Jan 2005, Piotr [iso-8859-2] Pi=B1tkowski wrote: > Maybe someone has already prepared such patch? Or should I try to make it > myself? Someone has written a patch, it may be somewhere in the bugs database --=20 have a search there (see valgrind.kde.org/bugs.html). N |
|
From: Nicholas N. <nj...@ca...> - 2005-01-10 20:43:42
|
On Mon, 10 Jan 2005, Charlie Shelton wrote: > When I run the following program with valgrind 2.2.0, I get > the output below it. The invalid read and writes are flagged > for the subscripts that are slightly off(-1, 100), but are > not for the larger errors(1000). I understand that valgrind > allocates some amount of memory on either side of the array, > but is there any way to catch this error of a large offset > if it reaches into validly allocated memory(ptr2)? Unfortunately not, it's an inherent shortcoming of Memcheck's technique (and mentioned in the FAQ). I tried writing a Valgrind tool once that would detect such an error, but it never really worked properly. N |
|
From: Charlie S. <csh...@ho...> - 2005-01-10 18:22:04
|
Hi,
When I run the following program with valgrind 2.2.0, I get
the output below it. The invalid read and writes are flagged
for the subscripts that are slightly off(-1, 100), but are
not for the larger errors(1000). I understand that valgrind
allocates some amount of memory on either side of the array,
but is there any way to catch this error of a large offset
if it reaches into validly allocated memory(ptr2)? If I
take out the ptr2 allocation, then I get invalid read and
writes for the 1000 subscript.
Thanks,
Charlie Shelton
#include <stdio.h>
#include <stdlib.h>
#include <malloc.h>
int main ( int argc, char **argv )
{
int i = 0;
int * ptr0 = 0;
int * ptr2 = 0;
int * ptr = 0;
int ara[100];
int n;
ptr0 = (int *) malloc ( sizeof(int) * 10000 );
ptr = (int *) malloc ( sizeof(int) * 100 );
ptr2 = (int *) malloc ( sizeof(int) * 10000 );
for (i=0; i<100; i++)
{
ptr[i] = 0;
ara[i] = 0;
}
n = ptr[-1];
n = ara[-1];
n = ptr[100];
n = ptr[1000];
ptr[100] = 0;
ptr[1000] = 0;
free ( ptr0 );
free ( ptr );
free ( ptr2 );
return (0);
}
==14621== Invalid read of size 4
==14621== at 0x8048422: main (test.c:25)
==14621== Address 0x1BE34C94 is 4 bytes before a block of size 400 alloc'd
==14621== at 0x1B903D74: malloc (vg_replace_malloc.c:131)
==14621== by 0x80483CA: main (test.c:16)
==14621==
==14621== Invalid read of size 4
==14621== at 0x8048432: main (test.c:28)
==14621== Address 0x1BE34E28 is 0 bytes after a block of size 400 alloc'd
==14621== at 0x1B903D74: malloc (vg_replace_malloc.c:131)
==14621== by 0x80483CA: main (test.c:16)
==14621==
==14621== Invalid write of size 4
==14621== at 0x8048452: main (test.c:31)
==14621== Address 0x1BE34E28 is 0 bytes after a block of size 400 alloc'd
==14621== at 0x1B903D74: malloc (vg_replace_malloc.c:131)
==14621== by 0x80483CA: main (test.c:16)
Without the ptr2 allocation, I also get the following:
==14643== Invalid read of size 4
==14643== at 0x804842F: main (test.c:29)
==14643== Address 0x1BE35C38 is not stack'd, malloc'd or (recently) free'd
==14643==
==14643== Invalid write of size 4
==14643== at 0x804844D: main (test.c:32)
==14643== Address 0x1BE35C38 is not stack'd, malloc'd or (recently) free'd
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-01-10 17:21:54
|
> Hi, > > When I run Valgrind 2.2.0, I get this error message: > > > > [srivathsan@tms-server lnms_working]$ valgrind --tool=memcheck > --log-file=test ./lnms > > open interp: No such file or directory > > [srivathsan@tms-server lnms_working]$ > > > > > > I think it is trying to read some interpreter, but not sure what and from > where. Any help is appreciated. > To be able to resolve this problem, more information is needed: # The output of uname -a. # The full output of valgrind -v. You can read more about this at http://valgrind.kde.org/bugs.html Regards, Jeroen. > > > Thanks, > > S.Srivathsan > > > > |
|
From: Piotr <ko...@ad...> - 2005-01-10 14:44:22
|
I was really disappointed today, when I've realised that valgrind doesn=
't
detect memory leaks with cyclic references.=20
Example:
void do_leak() {
void **p =3D (void**)malloc( 1024 );
p[0] =3D p;
}
int main() {
while( 1 ) {
do_leak();
sleep( 1 );
}
}
=2E..and leak report:
=3D=3D25900=3D=3D LEAK SUMMARY:
=3D=3D25900=3D=3D definitely lost: 0 bytes in 0 blocks.
=3D=3D25900=3D=3D possibly lost: 0 bytes in 0 blocks.
=3D=3D25900=3D=3D still reachable: 5120 bytes in 5 blocks.
=3D=3D25900=3D=3D suppressed: 0 bytes in 0 blocks.
Of course, this is exactly as is stated in docs, nevertheless I need th=
e
option of reporting such leaks - this doesn't look very complicated, ju=
st
during searching for pointers to allocated memory regions, one should c=
heck
if pointers to some memory region are defined only in this region, then
treat such region as not reachable (and then repeat this process for
regions, which has pointers only in this - not reachable - region, and =
so
on).
Maybe someone has already prepared such patch? Or should I try to make =
it
myself?
--=20
Piotr Pi=B1tkowski, Onet.pl SA, Krak=F3w [=
PT/SH]
perl -le 's**02).4&\*534^[./4(%2^0%2,^([#+%2&**y%& -;^[%"`-{ a%%s%%$_%e=
e'
|
|
From: Morten W. J. <mo...@ne...> - 2005-01-10 12:16:46
|
Now, would you believe that!!!
> {
> strlen
> Memcheck:Cond
> fun:strlen
> fun:xml_storage_trim
> fun:xml_storage_walk_xpath
> }
My suppression now works the way i want.
> The other option of course is to fix the problem in your program ;-)
That is of cause an option, but it is more fun to learn Valgrind than fixin=
g=20
segmentation faults. :-D
I think we'll call them "features" instead of "faults".
Thank for your quick reply.
Regards,
Morten W. J=F8rgensen
|
|
From: Tom H. <th...@cy...> - 2005-01-10 11:57:17
|
In message <200...@ne...>
Morten W. J. <mo...@ne...> wrote:
> Checking (with memcheck) my program I have a lot of calls to strlen via the
> same execution path like below there the strlen() is performed on a argument
> to the function xml_storage_trim.
>
> ==13393== Conditional jump or move depends on uninitialised value(s)
> ==13393== at 0x1B903691: strlen (mac_replace_strmem.c:189)
> ==13393== by 0x8048AF8: xml_storage_trim (xmlstorage.c:32)
> ==13393== by 0x8048D5B: xml_storage_walk_xpath (xmlstorage.c:113)
> ==13393== by 0x804A596: load_structure (xmlstorage.c:526)
>
> This happens a couple of hundred times so I would like to supress the warning.
> However I have some trouble writing a proper supresion rule, so I hope
> somebody can help me out.
>
> My effords so far have resulted in the following.
>
> {
> strlen
> Memcheck:Cond
> fun:xml_storage_trim
> fun:xml_walk_xpath
> }
>
> which doesn't help me much.
You've missed out strlen from the functions to match, so that rule
will never match. You also got one of the other names wrong. What you
want is:
{
strlen
Memcheck:Cond
fun:strlen
fun:xml_storage_trim
fun:xml_storage_walk_xpath
}
The other option of course is to fix the problem in your program ;-)
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|