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
(5) |
|
2
(2) |
3
(15) |
4
(3) |
5
|
6
(11) |
7
(4) |
8
|
|
9
(3) |
10
(6) |
11
(4) |
12
(5) |
13
(7) |
14
(37) |
15
(8) |
|
16
(1) |
17
(19) |
18
(20) |
19
(20) |
20
(15) |
21
(13) |
22
|
|
23
|
24
(20) |
25
(6) |
26
(2) |
27
(4) |
28
(6) |
29
|
|
30
(5) |
|
|
|
|
|
|
|
From: Test V. <am...@in...> - 2003-11-14 11:39:30
|
Hi All, I downloaded the valgrind sources (both Valgrind version 20031012 and valgrind-2.0) from http://valgrind.kde.org. As per the README, used the following commands ./configure --prefix /usr/local/bin make make install I guess both the times the valgrind was compiled and installed correctly. I also tried once with ./configure only (i.e. without giving prefix option). Also tried using the setting up specific paths. But still all the time I am getting the segmentation fault whenever I run "./valgrind ls -al". Can anybody tell me what could be the problem? Any information/steps about this issues is welcome! Best regards AMOLAK |
|
From: Melchior F. <mf...@kd...> - 2003-11-13 23:26:03
|
* Nicholas Nethercote -- Thursday 13 November 2003 23:55:
> I'm sorry, I don't understand. These errors you want to attach GDB to --
> are they being suppressed? It would help if you could explain what you're
> doing in more detail.
No. They are shown, but vg doesn't prompt me to attach gdb to them.
Here's some more detail (all mentioned files in coregrind/):
1. vg_errcontext.c:116:
after each detected error "is_action_requested" is called
2. vg_errorcontext.c:133:
res = VG_(read)(VG_(clo_input_fd), &ch, 1);
checks for user input
3. vg_mylibc.c:1166:
VG_(read) calls system's "read" which does occasionally
return -EAGAIN!
4. vg_errorcontext.c:134:
goes to ioerror
5. vg_errorcontext.c:152:
disables prompting for the rest of the session, only
because of this silly EAGAIN
The following quick fix works for me (but is prone to cause
an endless loop :-)
Index: vg_mylibc.c
===================================================================
RCS file: /home/kde/valgrind/coregrind/vg_mylibc.c,v
retrieving revision 1.45
diff -u -p -r1.45 vg_mylibc.c
--- vg_mylibc.c 6 Jul 2003 01:14:42 -0000 1.45
+++ vg_mylibc.c 13 Nov 2003 23:11:45 -0000
@@ -31,6 +31,7 @@
*/
#include "vg_include.h"
+#include <errno.h>
@@ -1167,7 +1168,9 @@ Int VG_(read) ( Int fd, void* buf, Int c
{
Int res;
/* res = read( fd, buf, count ); */
- res = vg_do_syscall3(__NR_read, fd, (UInt)buf, count);
+ do {
+ res = vg_do_syscall3(__NR_read, fd, (UInt)buf, count);
+ } while (res == -EAGAIN);
if (VG_(is_kerror)(res)) res = -1;
return res;
}
m.
PS: this is Linux 2.4.20, gcc 3.3, libc 2.3.2, SuSE 8.1
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-13 22:55:49
|
On Thu, 13 Nov 2003, Melchior FRANZ wrote:
> There's an annoying bug in valgrind 2.0.0 (and probably older
> versions). I'm memchecking a program with --gdb-attach=yes and
> --suppressions=file, and with (among other rules) this in my
> suppressions file:
>
> {
> <foo>
> Memcheck:Cond
> fun:_ZNSt13basic_filebufIcSt11char_traitsIcEE18_M_really_overflowEi
> fun:_ZNSt13basic_filebufIcSt11char_traitsIcEE8overflowEi
> fun:_ZNSt15basic_streambufIcSt11char_traitsIcEE5sputcEc
> fun:_ZN6logbuf8overflowEi
> }
>
> But valgrind doesn't stop after displaying bugs, instead everything
> rushes by without prompting me to start gdb. If, however, I change
> any of the "fun:" lines so that the mangled symbol doesn't match
> any more, then valgrind will stop after the next bug.
I'm sorry, I don't understand. These errors you want to attach GDB to --
are they being suppressed? It would help if you could explain what you're
doing in more detail. Thanks.
N
|
|
From: Melchior F. <mf...@kd...> - 2003-11-13 21:38:15
|
There's an annoying bug in valgrind 2.0.0 (and probably older
versions). I'm memchecking a program with --gdb-attach=yes and
--suppressions=file, and with (among other rules) this in my
suppressions file:
{
<foo>
Memcheck:Cond
fun:_ZNSt13basic_filebufIcSt11char_traitsIcEE18_M_really_overflowEi
fun:_ZNSt13basic_filebufIcSt11char_traitsIcEE8overflowEi
fun:_ZNSt15basic_streambufIcSt11char_traitsIcEE5sputcEc
fun:_ZN6logbuf8overflowEi
}
But valgrind doesn't stop after displaying bugs, instead everything
rushes by without prompting me to start gdb. If, however, I change
any of the "fun:" lines so that the mangled symbol doesn't match
any more, then valgrind will stop after the next bug.
m. ??
|
|
From: David J. <dj...@ho...> - 2003-11-13 16:10:22
|
I have a problem running a program under valgrind on RH9. The application is multi-threaded. When run under valgrind, one of the threads call munmap on the memory segment of a shared library. Subsequently, another thread needs a symbol in the library and tries to reload it. However the dlopen library becomes very confused, probably because it doesn't realize that the original copy of the library is unmapped. Things go rapdily downhill from there. This problem does not happen when using valgrind on RH 7.2 When I run the program on RH9 using gdb, there is no call to munmap at this part of the program. To track this down, I would like to determine where the call to munmap is being made. How can I temporarily modify valgrind to produce a stack dump when munmap is called? |
|
From: Dan K. <da...@ke...> - 2003-11-13 09:25:32
|
http://valgrind.kde.org/docs.html has two links, and both are broken. Other than that, the new site is quite nice. |
|
From: Nicholas N. <nj...@ca...> - 2003-11-13 09:13:39
|
On Thu, 13 Nov 2003, Anders Torger wrote: > I'm using valgrind-20031012 as distributed in debian unstable. > > I got this warning, and I think it is invalid: > > ==8200== Source and destination overlap in strncpy(0x412deab0,0x412dea78,256) > ==8200== at 0x400240ED: strncpy (mac_replace_strmem.c:95) > > As you can see, the source address is before the destination address, closer > than 256 bytes, which is the strncpy limit in this call. This can happen when > the source string is shorter than 256 bytes (which it is in this case), but > valgrind reports it as an error anyway. > > Since the source address contains a string which is shorter than 256 bytes, > malloc happened to put the block closer than that to the destination. The way > strncpy works, there can never be a an overlap in this situation if indeed > the string is short enough to fit. The copying from the source will stop > where the string ends, if it ends before the 256 byte limit. > > However, if the source and destination addresses had been swapped in the above > example, the Valgrind report would have been correct. It's been fixed in 2.0.0, which you can get from the new website, at valgrind.kde.org. Thanks for the report. N |
|
From: Anders T. <to...@lu...> - 2003-11-13 08:56:53
|
I'm using valgrind-20031012 as distributed in debian unstable. I got this warning, and I think it is invalid: ==8200== Source and destination overlap in strncpy(0x412deab0,0x412dea78,256) ==8200== at 0x400240ED: strncpy (mac_replace_strmem.c:95) As you can see, the source address is before the destination address, closer than 256 bytes, which is the strncpy limit in this call. This can happen when the source string is shorter than 256 bytes (which it is in this case), but valgrind reports it as an error anyway. Since the source address contains a string which is shorter than 256 bytes, malloc happened to put the block closer than that to the destination. The way strncpy works, there can never be a an overlap in this situation if indeed the string is short enough to fit. The copying from the source will stop where the string ends, if it ends before the 256 byte limit. However, if the source and destination addresses had been swapped in the above example, the Valgrind report would have been correct. /Anders Torger |
|
From: Tom H. <th...@cy...> - 2003-11-12 22:30:50
|
In message <3FB...@sa...>
"Ralph R. Peters" <rr...@sa...> wrote:
> Valgrind was suggested to me as an superior alternative to purify, which
> isn't avaliable for linux systems! I installed it and it worked on
> simple stuff. However, it will not work on the software that I have
> spent the last 4 years developing (Rapid World Modeler).
>
> I thought that I would forward the error to this group in hopes that
> someone might write the bit of code to fix the problem. I don't have
> the expertise to do the right thing to fix it.
>
> I am running RedHat 9 and using valgrind 2.0.0.
You're using RedHat 9 so this could be an NPTL related problem, as
the set_thread_area system call is part of the new threading model.
That said, this isn't the normal failure mode for NPTL and from the
filenames in stack trace it looks like valgrind has correctly forced
a fallback to the older threading model.
Do you perhaps have some custom threading code of your own that is
using this system call? or perhaps a library that you are using does?
Unfortunately simply implenting a wrapper for the system call is
unlikely to help much in this case, as being able to set the thread
area is much use on it's own.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Ralph R. P. <rr...@sa...> - 2003-11-12 22:11:51
|
Hello! Valgrind was suggested to me as an superior alternative to purify, which isn't avaliable for linux systems! I installed it and it worked on simple stuff. However, it will not work on the software that I have spent the last 4 years developing (Rapid World Modeler). I thought that I would forward the error to this group in hopes that someone might write the bit of code to fix the problem. I don't have the expertise to do the right thing to fix it. I am running RedHat 9 and using valgrind 2.0.0. Thanks Ralph Peters Intelligent Systems and Robotics Center Sandia National Laboratories Albuquerque, NM USA 87112 &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& [rrpeter@toumeya rwm]$ /usr/local/bin/valgrind -v wish viewer_scripts/viewer_CDF ==31902== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==31902== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==31902== Using valgrind-2.0.0, a program supervision framework for x86-linux. ==31902== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==31902== Command line: ==31902== wish ==31902== viewer_scripts/viewer_CDF ==31902== Startup, with flags: ==31902== --suppressions=/usr/local/lib/valgrind/default.supp ==31902== -v ==31902== Reading syms from /usr/bin/wish8.3 ==31902== object doesn't have a symbol table ==31902== object doesn't have any debug info ==31902== Reading syms from /lib/ld-2.3.2.so ==31902== object doesn't have any debug info ==31902== Reading syms from /usr/local/lib/valgrind/vgskin_memcheck.so ==31902== Reading syms from /usr/local/lib/valgrind/valgrind.so ==31902== Reading syms from /usr/lib/libtk8.3.so ==31902== object doesn't have a symbol table ==31902== object doesn't have any debug info ==31902== Reading syms from /usr/lib/libtcl8.3.so ==31902== object doesn't have a symbol table ==31902== object doesn't have any debug info ==31902== Reading syms from /usr/X11R6/lib/libX11.so.6.2 ==31902== object doesn't have a symbol table ==31902== object doesn't have any debug info ==31902== Reading syms from /lib/libdl-2.3.2.so ==31902== object doesn't have any debug info ==31902== Reading syms from /lib/libm-2.3.2.so ==31902== object doesn't have any debug info ==31902== Reading syms from /lib/libc-2.3.2.so ==31902== object doesn't have any debug info ==31902== Reading suppressions file: /usr/local/lib/valgrind/default.supp ==31902== Estimated CPU clock rate is 3088 MHz ==31902== ==31902== Reading syms from /usr/X11R6/lib/X11/locale/lib/common/xlcUTF8Load.so.2 ==31902== object doesn't have a symbol table ==31902== object doesn't have any debug info ==31902== Reading syms from /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 ==31902== object doesn't have a symbol table ==31902== object doesn't have any debug info ==31902== Reading syms from /usr/X11R6/lib/libXcursor.so.1.0 ==31902== object doesn't have a symbol table ==31902== object doesn't have any debug info ==31902== Reading syms from /usr/X11R6/lib/libXrender.so.1.2 ==31902== object doesn't have a symbol table ==31902== object doesn't have any debug info ==31902== Reading syms from /usr/X11R6/lib/libXext.so.6.4 ==31902== object doesn't have a symbol table ==31902== object doesn't have any debug info ==31902== Reading syms from /home/rrpeter/code/C++-code/umbra/lib/libslu.so ==31902== Reading syms from /usr/lib/libstdc++.so.5.0.3 ==31902== object doesn't have a symbol table ==31902== object doesn't have any debug info ==31902== Reading syms from /lib/libgcc_s-3.2.2-20030225.so.1 ==31902== object doesn't have a symbol table ==31902== object doesn't have any debug info ==31902== Reading syms from /home/rrpeter/code/C++-code/umbra/lib/libumbra.so ==31902== Reading syms from /home/rrpeter/code/C++-code/umbra/lib/libusv.so ==31902== Reading syms from /usr/lib/libpng12.so.0.1.2.2 ==31902== object doesn't have a symbol table ==31902== object doesn't have any debug info --31902-- FATAL: unhandled syscall: 243 --31902-- Do not panic. You may be able to fix this easily. --31902-- Read the file README_MISSING_SYSCALL_OR_IOCTL. ==31902== ==31902== Valgrind detected that your program requires ==31902== the following unimplemented functionality: ==31902== no wrapper for the above system call ==31902== This may be because the functionality is hard to implement, ==31902== or because no reasonable program would behave this way, ==31902== or because nobody has yet needed it. In any case, let me know ==31902== (js...@ac...) and/or try to work around the problem, if you can. ==31902== ==31902== Valgrind has to exit now. Sorry. Bye! ==31902== sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==31902== at 0x40006150: _dl_map_object_from_fd (in /lib/ld-2.3.2.so) ==31902== by 0x4000468A: _dl_map_object_internal (in /lib/ld-2.3.2.so) ==31902== by 0x4000BC27: openaux (in /lib/ld-2.3.2.so) ==31902== by 0x4000C265: _dl_catch_error_internal (in /lib/ld-2.3.2.so) [rrpeter@toumeya rwm]$ grep 243 /usr/include/asm/unistd.h #define __NR_set_thread_area 243 [rrpeter@toumeya rwm]$ man 2 set_thread_area No entry for set_thread_area in section 2 of the manual |
|
From: John R.
|
> ==11556== Conditional jump or move depends on uninitialised value(s)
> ==11556== at 0x40008A4A: elf_dynamic_do_rela.8 (in /lib/ld-2.2.93.so)
> ==11556== by 0x40008CBA: _dl_relocate_object_internal (in
> /lib/ld-2.2.93.so)
Glibc/elf uses some uninitialized values that happen to work because
the same uninit value is used twice and "cancels." This reveals
an opportunity for enhancement in memcheck, and sleazy code in glibc.
Look at this code for elf_dynamic_do_rela() in elf/dynamic-link.h:
-----
struct { ElfW(Addr) start, size; int lazy; } ranges[2]; \
ranges[0].lazy = 0; \
ranges[0].size = ranges[1].size = 0; \
ranges[0].start = 0; \
-----
and notice that ranges[1].lazy and .start are not initialized. Later:
-----
for (ranges_index = 0; ranges_index < 2; ++ranges_index) \
elf_dynamic_do_##reloc ((map), \
ranges[ranges_index].start, \
ranges[ranges_index].size, \
ranges[ranges_index].lazy); \
-----
and for elf_dynamic_do_rela in elf/do-rel.h:
-----
const ElfW(Rel) *r = (const void *) reladdr; ## .start
const ElfW(Rel) *end = (const void *) (reladdr + relsize); ## .start + .size
-----
and later in elf_dynamic_do_rela:
-----
for (; r < end; ++r)
-----
Valgrind notices that "r < end" depends on reladdr, and reladdr is
uninitialized. The C standard says that therefore _any_ behavior
is allowed: infinite loop, wrong answer, random answer, "correct"
answer. It just happens that gcc-compiled code works.
Several years ago, the maintainer of glibc boasted of pride in this code.
All executables that are supervised by ld-linux.so.2 suffer this, but
vagrind [memcheck] usually does not notice because it happens before
any LD_PRELOAD module gets control. Memcheck does see the problem
on some subsequent dynamic loads, as here.
--
|
|
From: Peter S. <sne...@no...> - 2003-11-12 16:17:12
|
I'm getting a warning about an "uninitialized value" when I run valgrind on a program which uses "gethostbyname_r", on a RH8.0 system. I was using valgrind-20031012, but I've just upgraded to 2.0.0 and see the same thing. The output is: ==11556== Startup, with flags: ==11556== --suppressions=/usr/local/lib/valgrind/default.supp ==11556== -v ==11556== --num-callers=12 ... ==11556== Conditional jump or move depends on uninitialised value(s) ==11556== at 0x40008A4A: elf_dynamic_do_rela.8 (in /lib/ld-2.2.93.so) ==11556== by 0x40008CBA: _dl_relocate_object_internal (in /lib/ld-2.2.93.so) ==11556== by 0x42109863: dl_open_worker (in /lib/i686/libc-2.2.93.so) ==11556== by 0x4000A425: _dl_catch_error_internal (in /lib/ld-2.2.93.so) ==11556== by 0x421092BE: __GI__dl_open (in /lib/i686/libc-2.2.93.so) ==11556== by 0x4210A6B9: do_dlopen (in /lib/i686/libc-2.2.93.so) ==11556== by 0x4000A425: _dl_catch_error_internal (in /lib/ld-2.2.93.so) ==11556== by 0x4210A587: __libc_dlopen (in /lib/i686/libc-2.2.93.so) ==11556== by 0x420EA677: __nss_lookup_function (in /lib/i686/libc-2.2.93.so) ==11556== by 0x420EB1DA: __nss_lookup (in /lib/i686/libc-2.2.93.so) ==11556== by 0x420EC3B8: __GI___nss_hosts_lookup (in /lib/i686/libc-2.2.93.so) ==11556== by 0x420EE174: gethostbyname_r@@GLIBC_2.1.2 (in /lib/i686/libc-2.2. My code calls gethostbyname_r, but even when I initialized *all* the parameters, valgrind still reported this error. Should this be supressed, or is it really telling me something? -- Peter Snelling |
|
From: Jeremy F. <je...@go...> - 2003-11-12 00:49:52
|
On Tue, 2003-11-11 at 15:17, Dennis Lubert wrote: > Here is what valgrind says (Valgrind from HEAD, 10 mins ago) > > ==27046== > disInstr: unhandled instruction bytes: 0xF 0x5 0xA 0x0 > at 0x4145836C: ??? It seems to me you've jumped through a bad function pointer: the pointer value itself looks like text: 'l' 0x83 'E' 'A'. > Then some other strange memory errors and a Segmentation Fault. > > Ok, I have done a bit disassembly and found this : > 0F 05 syscall > 0A 00 or al,[eax] > > but I thought syscall is for amd-64 only, not for Pentium4 / x86. I think it's junk. J |
|
From: Tom H. <th...@cy...> - 2003-11-11 23:46:36
|
In message <6.0...@po...>
Dennis Lubert <pla...@gm...> wrote:
> I have a program using a rather complex set of template classes. At one
> point I have a
> enum avl_tree_skew { avl_left, avl_right, avl_none = 0};
> so, note the 0. The program behaves totally fine when the = 0 is not there,
> but with, it behaves really really strange (Even segfault without valgrind).
You do realise that with the zero in there you are giving avl_left and
avl_none the same value, don't you?
Yom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2003-11-11 23:20:11
|
On Tue, 2003-11-11 at 14:43, Randall Hopper wrote: > Switching to KDE, --assume-2.4=yes gets me past that error, but then after > some minutes valgrinding this app locks my machine hard; it's completely > net dead and console dead. Don't see this with my 9/23 CVS snapshot. > > BTW, this is on SuSE 8.2. Ah, well, that's what we like to call a kernel bug. No matter what junk Valgrind does, it shouldn't lock the kernel like that. Obviously it could be a Valgrind bug too, and we'd like to fix it, but I wonder if there's a kernel update from SuSE, or perhaps you could try just installing a stock 2.4 kernel? What does your app do? Does it have lots of threads? Do lots of syscalls? Does it seem to be all working fine, and then it all falls over, or does it gradually collapse? Any oopses or other kernel messages on the console? Thanks, J |
|
From: Dennis L. <pla...@gm...> - 2003-11-11 23:17:53
|
Hello,
this is actually not a problem with valgrind, but I wonder if anyone ever
ran into such a thing, or give me any hint how to resolv it.
I have a program using a rather complex set of template classes. At one
point I have a
enum avl_tree_skew { avl_left, avl_right, avl_none = 0};
so, note the 0. The program behaves totally fine when the = 0 is not there,
but with, it behaves really really strange (Even segfault without valgrind).
Here is what valgrind says (Valgrind from HEAD, 10 mins ago)
==27046==
disInstr: unhandled instruction bytes: 0xF 0x5 0xA 0x0
at 0x4145836C: ???
==27046== Invalid read of size 1
==27046== at 0x41458214: ???
==27046== Address 0x41454D66 is 14 bytes before a block of size 20 alloc'd
==27046== at 0x4002906F: operator new(unsigned) (vg_replace_malloc.c:165)
==27046== by 0x8050D19: avltree<int, int>::add(int const&, int const&)
(../include/avlt
ree.h:124)
==27046== by 0x80509A8: main (rsaclient.cpp:29)
==27046== by 0x40386856: __libc_start_main (in /lib/libc.so.6)
==27046==
Then some other strange memory errors and a Segmentation Fault.
Ok, I have done a bit disassembly and found this :
0F 05 syscall
0A 00 or al,[eax]
but I thought syscall is for amd-64 only, not for Pentium4 / x86.
Whe I run it under gdb/ddd it tells me for the position in disassembly
(adress as displayed by bt):
0x08058ea5: test %al,0x8
All stuff strange, anyone can try an explanation, or even hint how to fix ?
greets
Dennis
Carpe quod tibi datum est
|
|
From: Randall H. <lis...@ch...> - 2003-11-11 22:43:04
|
Nicholas Nethercote: |Randall Hopper: |> |Try --assume-2.4=yes. | |> valgrind (from CVS from this morning) won't take this on the command-line, |> configure doesn't take it, and I don't find the string "assume-2.4" |> anywhere in the source. | |Did you check out the HEAD? From the new KDE repository (we moved away |from SourceForge, although it hasn't been well publicised). But if you |didn't use the KDE repository, I don't know how you're getting this |problem... Thanks. I'd pulled from sourceforge. Switching to KDE, --assume-2.4=yes gets me past that error, but then after some minutes valgrinding this app locks my machine hard; it's completely net dead and console dead. Don't see this with my 9/23 CVS snapshot. BTW, this is on SuSE 8.2. Randall |
|
From: Nicholas N. <nj...@ca...> - 2003-11-10 20:33:22
|
On Fri, 7 Nov 2003, Brian Akins wrote:
> I have an apache 2 module which I suspect is leaking memory, but
> valgrind never reports it.
>
> To test this I included "valgrind/memcheck.h" and call
> VALGRIND_DO_LEAK_CHECK for every request in this module. Valgrind does
> a memory leak test, but doesn't seem to catch anything in this modules.
>
> Example:
>
> char *p;
>
> p = malloc(128);
> p = NULL;
>
> This never gets caught.
I just tried this with a small test program:
#include <stdlib.h>
#include "memcheck.h"
int main(void)
{
char *p;
p = malloc(128);
p = NULL;
VALGRIND_DO_LEAK_CHECK;
return 0;
}
And the leak was found:
==22840== searching for pointers to 1 not-freed blocks.
==22840== checked 3534372 bytes.
==22840==
==22840== 128 bytes in 1 blocks are definitely lost in loss record 1 of 1
==22840== at 0x400296A6: malloc (vg_replace_malloc.c:153)
==22840== by 0x80483FD: main (a.c:8)
==22840== by 0x40242A06: __libc_start_main (in /lib/i686/libc-2.3.2.so)
==22840== by 0x8048298: ??? (start.S:81)
Can you give us a sample program, the smaller the better, that exhibits
the problem?
Thanks.
N
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-10 15:49:27
|
On Mon, 10 Nov 2003, Randall Hopper wrote: > |Try --assume-2.4=yes. > > Where do I put it? Command-line, eg. valgrind --assume-2.4=yes myprogram > valgrind (from CVS from this morning) won't take this on the command-line, > configure doesn't take it, and I don't find the string "assume-2.4" > anywhere in the source. Did you check out the HEAD? From the new KDE repository (we moved away from SourceForge, although it hasn't been well publicised). But if you didn't use the KDE repository, I don't know how you're getting this problem... Either way, --assume-2.4=yes didn't fix the problem for me. N |
|
From: Randall H. <lis...@ch...> - 2003-11-10 15:39:25
|
Josef Weidendorfer: |On Monday 10 November 2003 15:48, Randall Hopper wrote: |> Updated to valgrind from CVS this weekend, and the current emits errors for |> just about any program now. I backed up to the 20031012 snap and |> everything works. Here's the error from 20031108. |> |> This is on SuSE 8.2 BTW. | |Try --assume-2.4=yes. Where do I put it? valgrind (from CVS from this morning) won't take this on the command-line, configure doesn't take it, and I don't find the string "assume-2.4" anywhere in the source. Randall |
|
From: Josef W. <Jos...@gm...> - 2003-11-10 15:08:23
|
On Monday 10 November 2003 15:48, Randall Hopper wrote: > Updated to valgrind from CVS this weekend, and the current emits errors for > just about any program now. I backed up to the 20031012 snap and > everything works. Here's the error from 20031108. > > This is on SuSE 8.2 BTW. Try --assume-2.4=yes. Josef |
|
From: Randall H. <lis...@ch...> - 2003-11-10 14:48:32
|
Updated to valgrind from CVS this weekend, and the current emits errors for just about any program now. I backed up to the 20031012 snap and everything works. Here's the error from 20031108. This is on SuSE 8.2 BTW. ---------------------------------------------------------------------------- > /opt/pkg/valgrind-cvs-20031108/bin/valgrind ls ... ==5160== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==5160== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==5160== Using valgrind-20030725, a program supervision framework for x86-linux. ==5160== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==5160== Estimated CPU clock rate is 1203 MHz ==5160== For more details, rerun with: -v ==5160== <ls output> TID 1: proxy LWP 0 exited with status 0 valgrind: vg_proxylwp.c:1331 (vgPlain_proxy_sanity): Assertion `sane' failed. ==5160== at 0x4016D5FB: vgPlain_skin_assert_fail (vg_mylibc.c:1103) ==5160== by 0x4016D5FA: assert_fail (vg_mylibc.c:1099) ==5160== by 0x4016D655: vgPlain_core_assert_fail (vg_mylibc.c:1110) ==5160== by 0x40170E2A: vgPlain_proxy_sanity (vg_proxylwp.c:1331) sched status: Thread 1: status = WaitSys, associated_mx = 0x0, associated_cv = 0x0 ==5160== at 0x4031A3A8: __GI___libc_write (in /lib/libc.so.6) ==5160== by 0x402B554F: new_do_write (in /lib/libc.so.6) ==5160== by 0x402B54ED: _IO_do_write@@GLIBC_2.1 (in /lib/libc.so.6) ==5160== by 0x402B5FF7: _IO_file_overflow@@GLIBC_2.1 (in /lib/libc.so.6) ---------------------------------------------------------------------------- Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: js...@ac... In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. Randall |
|
From: Nicholas N. <nj...@ca...> - 2003-11-10 13:27:26
|
On Mon, 3 Nov 2003, Owen O'Malley wrote: > I wrote a skin that writes an xml report and so I didn't want any > extra non-xml stuff in the log file. Fortunately, -q does a pretty > good job of keeping valgrind quiet. I just need to prevent the: > > ==11666== > ==11666== My PID = 11666, parent PID = 28045. Prog and args are: > ==11666== a.out Committed to HEAD, thanks. N |
|
From: Avery P. <ape...@ni...> - 2003-11-09 22:57:34
|
On Sun, Nov 09, 2003 at 05:11:08PM +0000, Nicholas Nethercote wrote:
> On Sun, 2 Nov 2003, Avery Pennarun wrote:
>
> > if (!setjmp)
> > VALGRIND_STOP_INVALIDATING
> > longjmp(elsewhere)
> > // else someone longjmped back to me
> > VALGRIND_START_INVALIDATING
> > printf("x is now %d\n", x);
>
> I don't think this feature is likely to be added, since it would
> only ever be used in extremely obscure circumstances, which is exactly the
> kind of feature we don't like adding. Sorry about that.
Yeah, I understand and agree with that philosophy myself, so I'll try to
keep my disappointment to a minimum. Anyway, lacking this feature only
results in false negatives (valgrind doesn't find certain unlikely kinds of
coding errors) so I'm pretty safe.
> (I still don't quite understand why you need to use this unusual
> setjmp/longjmp thing instead of switching stack in a more normal way,
> although I'm sure you have a good reason.)
Now you're just being mean. From coregeind_core.html:
* Programs which switch stacks are not well handled. Valgrind does have
support for this, but I don't have great faith in it. It's difficult --
there's no cast-iron way to decide whether a large change in %esp is as a
result of the program switching stacks, or merely allocating a large object
temporarily on the current stack -- yet Valgrind needs to handle the two
situations differently.
*My* way of switching stacks, on the other hand, should at least behave 100%
consistently in valgrind and I don't have to depend on anything except
VALGRIND_MAKE_READABLE working - because I'm not actually switching stacks,
I'm just moving the stack pointer around *inside* the stack in a
well-understood way.
I originally did this for portability (WvTask works in Turbo C++ for DOS as
well as Windows, Unix, and probably any other ANSI C system). Little did I
realize before how useful this portability would be when I started using
valgrind :)
Have fun,
Avery
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-09 17:32:55
|
On Tue, 4 Nov 2003, tmoog wrote: > I recently upgraded to 2003-10-12 and had problems so I went > to 2003-07-25. I'm finding that 2003-07-25 is reporting > many problems with stl string operations, some as simple as > > std::string foo; > ... > foo = ""; > > or > > foo += "something"; > > When I run the program under 1.0.4 the program is totallly > clean. Are others seeing this behavior ? Can you give an example program, and the output you get with both versions? > Second issue: I have send in patches for epoll operations, but > these don't seem to have migrated into the kit, when I last > checked about a month ago. What is the proper method of > submitting such changes ? There's no official method at the moment, other than emailing us or this list. We're hoping to get Bugzilla going soon. As for the patch itself, it hasn't been used because nobody's got around to looking at it carefully. Sorry for the lack of feedback, hopefully someone will get to look at it eventually. I can't say anything more concrete than that, I'm afraid. Hopefully Bugzilla will help deal with these things better. N |