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
(6) |
2
(8) |
3
(9) |
4
(4) |
|
5
(2) |
6
(9) |
7
(8) |
8
(3) |
9
(3) |
10
|
11
|
|
12
(3) |
13
(8) |
14
(2) |
15
(10) |
16
(6) |
17
(2) |
18
(4) |
|
19
(1) |
20
(1) |
21
(8) |
22
(10) |
23
|
24
(5) |
25
(2) |
|
26
|
27
(4) |
28
(17) |
29
(3) |
30
(19) |
|
|
|
From: Paul P. <pa...@pa...> - 2004-09-06 22:15:50
|
Jean Pierre wrote:
> One bug I found very annoying is this one :
>
> double array[3];
> array[3] = 0;
Surely that is *not* a static array?
> In fact, so far I only found one product who can detect this and this is
> the bounds checking patch of gcc.
FWIW, Insure++ is *supposed* to find that bug (and an equivalent
one with the static array):
$ cat junk.c
int main()
{
double array[3];
static double xyz[3];
array[3] = 0;
xyz[3] = 1;
return 0;
}
$ insure gcc -g junk.c
[junk.c:5] **WRITE_BAD_INDEX**
Writing array out of range: array[3]
>> array[3] = 0;
[junk.c:6] **WRITE_BAD_INDEX**
Writing array out of range: xyz[3]
>> xyz[3] = 0;
$ ./a.out
[junk.c:5] **WRITE_BAD_INDEX**
>> array[3] = 0;
Writing array out of range: array[3]
Index used : 3
Valid range: 0 thru 2 (inclusive)
Stack trace where the error occurred:
main() junk.c, 5
**Memory corrupted. Program may crash!!**
[junk.c:6] **WRITE_BAD_INDEX**
>> xyz[3] = 0;
Writing array out of range: xyz[3]
Index used : 3
Valid range: 0 thru 2 (inclusive)
Stack trace where the error occurred:
main() junk.c, 6
Cheers,
|
|
From: Jean P. <2s...@ma...> - 2004-09-06 21:55:27
|
Hello, I'm currently evaluating valgrind against commercial software like purify and insure++ and so far it performs well. One bug I found very annoying is this one : double array[3]; array[3] = 0; And it seems that valgrind doesn't detect this one. In fact, so far I only found one product who can detect this and this is the bounds checking patch of gcc. I wonder if valgrind can be tweaked to detect this category of problem ? Thanks for any hint ! |
|
From: Jason W. <jp...@im...> - 2004-09-06 08:45:57
|
Can anyone tell me what this error indicates? valgrind-2.2.0, Debian sid. Several similar unit tests of my project work fine. This is a larger test app. It loads several shared objects, and uses stl, boost, and OpenGL. Multithreading with mutexes and such is active, but I beleive this test runs on a single thread. -- _ ( \ _ \ /_ / _ _ Jason Weber Oceanside, CA \|(\/)())) \/\/(-/_)(-/( http://www.imonk.com/baboon ba...@im... // we...@ac... (/ ---- (I've renamed the application classes to reduce clutter.) ==11960== Callgrind-0.9.9, a call-graph generating cache profiler for x86-linux. ==11960== Copyright (C) 2002-2004, and GNU GPL'd, by J.Weidendorfer, N.Nethercote et al. ==11960== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==11960== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==11960== For more details, rerun with: -v ==11960== [...] Callgrind: bb.c:227 (vgSkin_get_bb): Assertion `bb->instr_count == n_instrs' failed. ==11960== at 0xB002FF47: vgPlain_skin_assert_fail (vg_mylibc.c:1137) ==11960== by 0xB002FF46: assert_fail (vg_mylibc.c:1133) ==11960== by 0xB002FF7E: vgPlain_skin_assert_fail (vg_mylibc.c:1138) ==11960== by 0xB125BB08: vgSkin_get_bb (in /usr/lib/valgrind/vgskin_callgrind.so) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==11960== at 0x3AF8C060: __gnu_cxx::__mt_alloc<std::_Rb_tree_node<std::pair<Class1 const, Class2> > >::allocate(unsigned, void const*) (mt_allocator.h:281) ==11960== by 0x3AF8C48A: std::_Rb_tree<Class1, std::pair<Class1 const, Class2>, std::_Select1st<std::pair<Class1 const, Class2> >, std::less<Class1 >, std::allocator<std::pair<Class1 const, Class2> > >::insert_unique(std::pair<Class1 const, Class2> const&) (stl_pair.h:85) ==11960== by 0x3AF8C5DF: std::_Rb_tree<Class1, std::pair<Class1 const, Class2>, std::_Select1st<std::pair<Class1 const, Class2> >, std::less<Class1 >, std::allocator<std::pair<Class1 const, Class2> > >::insert_unique(std::_Rb_tree_iterator<std::pair<Class1 const, Class2> >, std::pair<Class1 const, Class2> const&) (stl_tree.h:898) ==11960== by 0x3AF88A8F:Class4::signal(Class3&) (stl_map.h:384) 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: Jos...@gm... In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. |
|
From: Hannibal <spa...@go...> - 2004-09-05 23:52:49
|
Hi
I have this configure warning:
checking linux/fb.h usability... no
checking linux/fb.h presence... yes
configure: WARNING: linux/fb.h: present but cannot be compiled
configure: WARNING: linux/fb.h: check for missing prerequisite headers?
configure: WARNING: linux/fb.h: see the Autoconf documentation
configure: WARNING: linux/fb.h: section "Present But Cannot Be Compiled"
configure: WARNING: linux/fb.h: proceeding with the preprocessor's result
configure: WARNING: linux/fb.h: in the future, the compiler will take=20
precedence
configure: WARNING: ## ------------------------------------------------=
=2D--=20
##
configure: WARNING: ## Report this to val...@li...urceforge.=
net=20
##
configure: WARNING: ## ------------------------------------------------=
=2D--=20
##
checking for linux/fb.h... yes
Probably I will be ignore it, but I have also compilation problems:
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include -I../include=
=20
=2DI./x86 -DVG_LIBDIR=3D"\"/usr/local/lib/valgrind"\" -DKICKSTART_BASE=3D0x=
b0000000 =20
=2DWinline -Wall -Wshadow -O -fno-omit-frame-pointer=20
=2Dmpreferred-stack-boundary=3D2 -g -DELFSZ=3D32 -MT vg_syscalls.o -MD -MP=
-MF=20
".deps/vg_syscalls.Tpo" -c -o vg_syscalls.o vg_syscalls.c; \
then mv -f ".deps/vg_syscalls.Tpo" ".deps/vg_syscalls.Po"; else rm -f=20
".deps/vg_syscalls.Tpo"; exit 1; fi
In file included from /usr/include/linux/msg.h:5,
from vg_unsafe.h:56,
from vg_syscalls.c:35:
/usr/include/linux/list.h:700:2: warning: #warning "don't include kernel=20
headers in userspace"
In file included from /usr/include/linux/fs.h:19,
from vg_unsafe.h:68,
from vg_syscalls.c:35:
/usr/include/linux/prio_tree.h:22: error: parse error before "pgoff_t"
/usr/include/linux/prio_tree.h:27: error: parse error before "pgoff_t"
/usr/include/linux/prio_tree.h: In function `prio_tree_iter_init':
/usr/include/linux/prio_tree.h:29: error: `iter' undeclared (first use in t=
his=20
function)
/usr/include/linux/prio_tree.h:29: error: (Each undeclared identifier is=20
reported only once
/usr/include/linux/prio_tree.h:29: error: for each function it appears in.)
/usr/include/linux/prio_tree.h:29: error: `root' undeclared (first use in t=
his=20
function)
/usr/include/linux/prio_tree.h:30: error: `r_index' undeclared (first use i=
n=20
this function)
In file included from vg_unsafe.h:70,
from vg_syscalls.c:35:
/usr/include/linux/fb.h: At top level:
/usr/include/linux/fb.h:286: error: field `modelist' has incomplete type
In file included from /usr/include/linux/mii.h:12,
from vg_unsafe.h:76,
from vg_syscalls.c:35:
/usr/include/linux/if.h:95: error: redefinition of `struct ifmap'
/usr/include/linux/if.h:131: error: redefinition of `struct ifreq'
/usr/include/linux/if.h:181: error: redefinition of `struct ifconf'
make[4]: *** [vg_syscalls.o] B=B3=B1d 1
make[4]: Leaving directory `/source/valgrind-2.2.0/coregrind'
The first error is caused by missing definiton of pgoff_t. This type is=20
#defined in linux/types.h but adding it into vg_unsafe.h dosn't help.
The second error - redefinition was already reported. I found it in group=20
archive.
I waitng for patches :P
I almost forgotten, I have Slackware-current, gcc-3.3.4, glibc-2.3.2 and =20
kernel-2.6.9-rc1.
=2D-=20
Hannibal
|
|
From: Sefer T. <se...@ho...> - 2004-09-05 07:37:02
|
Hi,
I have reported Valgrind miscompilation (in the CVS head) because in some
places throughout valgrind the code includes "linux/if.h" and in some
"net/if.h" on the latest Mandrake distrubutions.
It would be probably best to make sure it is standarized (probably
"net/if.h") but for now the simplest hack I found to resolve this is to
modify "vg_unsafe.h" to include "linux/if.h" instead of "net/if.h"
Now valgrding compiles just fine and appears to run correctly. I'd
appreciate it if you could incorporate this change in the head sources.
Thanks,
Sefer.
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
|
|
From: Griffith <ubj...@ha...> - 2004-09-04 18:08:18
|
<HTML><html> <body> <P>Hello Mr. Davidson</P> <P>You can see your future wife here <A href="http://www.dbosh.net">http://www.dbosh.net</A></P> <P>If you do not want to receive this email more please go to <A href="http://www.dbosh.net">http://www.dbosh.net</A> and write Us.</P> <P>Thank you !</P> </body> </html> </HTML> |
|
From: <oli...@on...> - 2004-09-04 17:39:03
|
> On Wed, 1 Sep 2004 oli...@on... wrote: > > > I used the --db-attach=yes option and I am writing a log file to get all > > errors, that valgrind reported in a nice, east to read file. But when > > it reaches an error and it asks you what to do: > > > > ==28803== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- > > > > It does print the message to the logfile and not to the screen. IMO this > > message should be left out of the logfiles and just being print to the > > screen. > > I just waited 20minutes for my application to hit the error (was running > > in the background) and at some point I realized it stopped and opened > > the log file. ;) > > Can you file a bug report? Thanks. Done. BTW...the documentation on the webpage still points to the old 2.1.2 one, although the new 2.2.0 is already on the webserver. So long Oliver |
|
From: Nicholas N. <nj...@ca...> - 2004-09-04 15:38:59
|
On Wed, 1 Sep 2004 oli...@on... wrote: > I used the --db-attach=yes option and I am writing a log file to get all > errors, that valgrind reported in a nice, east to read file. But when > it reaches an error and it asks you what to do: > > ==28803== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- > > It does print the message to the logfile and not to the screen. IMO this > message should be left out of the logfiles and just being print to the > screen. > I just waited 20minutes for my application to hit the error (was running > in the background) and at some point I realized it stopped and opened > the log file. ;) Can you file a bug report? Thanks. N |
|
From: James A. <jam...@me...> - 2004-09-04 01:17:31
|
> Tom Hughes <thh <at> cyberscience.com> writes: > Those reads aren't crazy, .... So, any ideas why my program would be running so slow? Any ideas on how to diagnose it? -james |
|
From: <oli...@on...> - 2004-09-03 22:18:06
|
> What do you mean by "instances" exactly? How are you identifying > these instances? I meant, that it's one process all the time and suddenly I have like 8 processes running. > The point is that valgrind won"t randomly decide to start a few > extra copies your program. If your program forks then you will > appear to have multiple valgrind"s running, one for each process > that you have forked. The program doesn't fork anywhere. if this would be wanted behavior, I would have reported it at all. > Likewise if you are using ps then what you may be seeing is actually > threads rather than processes. You will always have two threads when > running under valgrind, and one more will appear each time you create > a thread in your program. Well...using "ps -x" only shows me the processes and the valgrind'd program has only one process running. And I don't get those multiple threads with addrcheck or helgrind. With addrcheck it runs for hours without any problem. > As to that error, that looks like a problem in your program. Valgrind > is simply informing you of the details when your programs dies because > of a bad memory access. I also thought so, but I debugged it and everything is fine. But when running it in valgrind with memcheck the memory gets corrupted. I used --db-attach=yes and when I got to that error and looked in the debugger the memory wasn't right. Running it without valgrind or with another tool I don't have that program. The same code also gets executed a lot of times before. And the code, that is bad is just creating a string object (string x = y) and the given string is alright. I will have a much closer look at it over the weekend, if I actually get to it. Maybe some more details will surface. |
|
From: Tom H. <th...@cy...> - 2004-09-03 21:37:34
|
In message <loo...@po...>
James Ahlborn <jam...@me...> wrote:
> i posted a little while back about newer versions of valgrind running very
> slowly. i'm still having that problem (with 2.2.0, on red hat 7.3), and i
> have some strace info to go with it. seems that my program gets hung up in
> all sorts of crazy read calls (note the repeated (resource temporarily
> unavailable). the program was useable under valgrind 2.0.0. pretty
> unuseable at this point.
Those reads aren't crazy, they're just valgrind's main thread
checking for events from the proxy LWP that handles signals and
blocking system calls. It's entirely normal to see those.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: James A. <jam...@me...> - 2004-09-03 20:53:19
|
hey,
i posted a little while back about newer versions of valgrind running very
slowly. i'm still having that problem (with 2.2.0, on red hat 7.3), and i have
some strace info to go with it. seems that my program gets hung up in all sorts
of crazy read calls (note the repeated (resource temporarily unavailable). the
program was useable under valgrind 2.0.0. pretty unuseable at this point.
rt_sigprocmask(SIG_SETMASK, NULL, ~[ILL BUS FPE KILL SEGV STOP], 8) = 0
rt_sigprocmask(SIG_SETMASK, ~[], ~[ILL BUS FPE KILL SEGV STOP], 8) = 0
rt_sigtimedwait(~[ILL BUS FPE KILL SEGV STOP], 0xbfffe9d4) = -1 EAGAIN (Resource
temporarily unavailable)
rt_sigprocmask(SIG_SETMASK, ~[ILL BUS FPE KILL SEGV STOP], NULL, 8) = 0
SYS_224(0xbfffea50, 0xb002f0a3, 0x101bc, 0xb003067f) = 4960
read(826, "\1\0\0\0\1\0\0\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 136) = 13
6
read(826, "\2\0\0\0\1\0\0\0\216\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 136) = 13
6
read(826, "\3\0\0\0\1\0\0\0\216\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 136) = 13
6
read(826, 0xbfffe9b4, 136) = -1 EAGAIN (Resource temporarily unavai
lable)
gettimeofday({1094241990, 946626}, NULL) = 0
write(829, "\1\0\0\0\10\0\0\0\30\347\32\260", 12) = 12
SYS_224(0xbfffea68, 0xb0032961, 0xbfffe9e4, 0xb0046f6d) = 4960
SYS_224(0xbfffe9c0, 0xb00306b3, 0x2, 0xb01adfc4) = 4960
rt_sigprocmask(SIG_SETMASK, NULL, ~[ILL BUS FPE KILL SEGV STOP], 8) = 0
rt_sigprocmask(SIG_SETMASK, ~[], ~[ILL BUS FPE KILL SEGV STOP], 8) = 0
rt_sigtimedwait(~[ILL BUS FPE KILL SEGV STOP], 0xbfffe9d4) = -1 EAGAIN (Resource
temporarily unavailable)
rt_sigprocmask(SIG_SETMASK, ~[ILL BUS FPE KILL SEGV STOP], NULL, 8) = 0
SYS_224(0xbfffea50, 0xb002f0a3, 0x101bc, 0xb003067f) = 4960
read(826, 0xbfffe9b4, 136) = -1 EAGAIN (Resource temporarily unavai
lable)
gettimeofday({1094241990, 947237}, NULL) = 0
write(831, "\1\0\0\0\10\0\0\0\304\352\32\260", 12) = 12
SYS_224(0xbfffea68, 0xb0032961, 0xbfffe9e4, 0xb0046f6d) = 4960
SYS_224(0xbfffe9c0, 0xb00306b3, 0x3, 0xb01adfc4) = 4960
rt_sigprocmask(SIG_SETMASK, NULL, ~[ILL BUS FPE KILL SEGV STOP], 8) = 0
rt_sigprocmask(SIG_SETMASK, ~[], ~[ILL BUS FPE KILL SEGV STOP], 8) = 0
rt_sigtimedwait(~[ILL BUS FPE KILL SEGV STOP], 0xbfffe9d4) = -1 EAGAIN (Resource
temporarily unavailable)
rt_sigprocmask(SIG_SETMASK, ~[ILL BUS FPE KILL SEGV STOP], NULL, 8) = 0
SYS_224(0xbfffea50, 0xb002f0a3, 0x101bc, 0xb003067f) = 4960
read(826, 0xbfffe9b4, 136) = -1 EAGAIN (Resource temporarily unavai
lable)
write(825, "\1\0\0\0\f\0\0\0l\343\32\260", 12) = 12
SYS_224(0xbfffea68, 0xb0032961, 0xbfffe9e4, 0xb0046f6d) = 4960
SYS_224(0xbfffe9c0, 0xb00306b3, 0x1, 0xb01adfc4) = 4960
rt_sigprocmask(SIG_SETMASK, NULL, ~[ILL BUS FPE KILL SEGV STOP], 8) = 0
rt_sigprocmask(SIG_SETMASK, ~[], ~[ILL BUS FPE KILL SEGV STOP], 8) = 0
rt_sigtimedwait(~[ILL BUS FPE KILL SEGV STOP], 0xbfffe9d4) = -1 EAGAIN (Resource
temporarily unavailable)
rt_sigprocmask(SIG_SETMASK, ~[ILL BUS FPE KILL SEGV STOP], NULL, 8) = 0
SYS_224(0xbfffea50, 0xb002f0a3, 0x101bc, 0xb003067f) = 4960
read(826, "\1\0\0\0\1\0\0\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 136) = 13
6
read(826, 0xbfffe9b4, 136) = -1 EAGAIN (Resource temporarily unavai
lable)
write(825, "\1\0\0\0 \0\0\0l\343\32\260", 12) = 12
|
|
From: Paul P. <pa...@pa...> - 2004-09-03 16:03:47
|
>>>>> On Wed, 1 Sep 2004 10:59:20 -0700 (PDT), Naveen Kumar <g_n...@ya...> said:
> ==3145== Reading syms from so-and-so-binary
> (0x8048000)
> Thats it. I dont get any output after that.
Does the app re-exec itself?
If so, you'll need to add --trace-children=yes
--
Paul Pluzhnikov pa...@pa...
|
|
From: Tom H. <th...@cy...> - 2004-09-03 14:24:10
|
In message <5074873$109...@co...>
oli...@on... wrote:
> I was running valgrind-2.2.0 with the memcheck tool. At a certain point
> of the application it does suddenly create multiple instances of the
> process (I had 8 processes of my application running out of nowhere)
> and it creashes with an error, that something si writing into unmapped
> space:
>
> ==20733== Process terminating with default action of signal 11 (SIGSEGV)
> ==20733== Access not within mapped region at address 0x2D42DFCF
What do you mean by "instances" exactly? How are you identifying
these instances?
The point is that valgrind won't randomly decide to start a few
extra copies your program. If your program forks then you will
appear to have multiple valgrind's running, one for each process
that you have forked.
Likewise if you are using ps then what you may be seeing is actually
threads rather than processes. You will always have two threads when
running under valgrind, and one more will appear each time you create
a thread in your program.
As to that error, that looks like a problem in your program. Valgrind
is simply informing you of the details when your programs dies because
of a bad memory access.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: <oli...@on...> - 2004-09-03 13:48:08
|
I was running valgrind-2.2.0 with the memcheck tool. At a certain point of the application it does suddenly create multiple instances of the process (I had 8 processes of my application running out of nowhere) and it creashes with an error, that something si writing into unmapped space: ==20733== Process terminating with default action of signal 11 (SIGSEGV) ==20733== Access not within mapped region at address 0x2D42DFCF I haven't tried memcheck of 2.1.2 with this application. The addrcheck tool does work fine since 2.2.0 and doesn't crash on my application. |
|
From: Neil Y. <nei...@wi...> - 2004-09-03 08:56:08
|
I'm seeing massif (2.2.0) crash on startup with an assertion failure on RedHat 7.3 valgrind --tool=massif --depth=8 --alloc-fn=sqlcxt --num-callers=16 ./program ==23804== Massif, a space profiler for x86-linux. ==23804== Copyright (C) 2003, Nicholas Nethercote ==23804== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==23804== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" ==23804== For more details, rerun with: -v ==23804== @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" ==23804== valgrind: vg_libpthread.c:2313 (write): Assertion `write_ptr != ((void *)0) && write_ptr != write' failed. ==23804== Please report this bug at: valgrind.kde.org ==23804== ==23804== Total spacetime: 294,134,770 ms.B ==23804== heap: 2.5% ==23804== heap admin: 0.1% ==23804== stack(s): 97.2% Neil Youngman Wirefast Limited |
|
From: Neil Y. <nei...@wi...> - 2004-09-03 08:22:20
|
The problem with building on RH7.3 is explained at http://www.ussg.iu.edu/hypermail/linux/kernel/0303.2/0189.html I was able to fix this by doing mv /usr/include/asm/ /usr/include/asm.orig; ln -s /usr/src/linux-2.4/include/asm /usr/include mv /usr/include/linux/ /usr/include/linux.orig; ln -s /usr/src/linux-2.4/include/linux /usr/include Obviously this may have knock on effects else where. Do this at your own risk. The safe alternative of configuring with "CPPFLAGS=-I/usr/src/linux-2.4/include/ ./configure" did not work for me. Neil Youngman |
|
From: smiley g. <smi...@ya...> - 2004-09-03 05:10:30
|
Hello valgrind, In reference to Bug 85756: x86 assembly prefix LOCK to guarantee atomicity has no effect http://bugs.kde.org/show_bug.cgi?id=85756 I made the following changes in coregrind/vg_to_ucode.c 3889,3902c3885 < VG_(printf)("LOCK LOCK LOCK LOCK LOCK \n"); < < /* All decode failures end up here. */ < VG_(printf)("disInstr: unhandled instruction bytes: " < "0x%x 0x%x 0x%x 0x%x\n", < (Int)eip_start[0], < (Int)eip_start[1], < (Int)eip_start[2], < (Int)eip_start[3] ); < < /* Print address of failing instruction. */ < VG_(describe_eip)((Addr)eip_start, loc_buf, M_VG_ERRTXT); < VG_(printf)(" lock at %s\n", loc_buf); < --- > /* VG_(printf)("LOCK LOCK LOCK LOCK LOCK \n"); */ When I run my application I found the following in my log files, LOCK LOCK LOCK LOCK LOCK disInstr: unhandled instruction bytes: 0xF0 0xF 0xB1 0x93 lock at 0x34D5F61B: get_proc_path (in /lib/tls/libc-2.3.2.so) ==11816== Warning: Addrcheck: ignoring lock request 34D5F619. LOCK LOCK LOCK LOCK LOCK disInstr: unhandled instruction bytes: 0xF0 0xF 0xB1 0xB3 lock at 0x34D96DB3: __GI___libc_freeres (in /lib/tls/libc-2.3.2.so) ==11785== Warning: Addrcheck: ignoring lock request 34D96DAD. Two routines in glibc use lock prefix. My doubts arise as glibc's is substituted with valgrind's own routines still is there minimal dependence on glibc. I have managed to remove all uses of lock prefix from my code, but I still face some problems can this be a reason. Thanks, Madhan. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail |
|
From: Steve A. <st...@bl...> - 2004-09-02 15:44:40
|
On Thu, Sep 02, 2004 at 03:23:20PM +0100, Nicholas Nethercote wrote: > >When running valgrind --tool=massif on some code compiled with -g > >using gcc 2.95, dynamically linked with a bunch of libraries > >valgrind throws this at startup: > > [snip] > > @@ unlikely looking definition in unparsed remains ";" > > @@ unlikely looking definition in unparsed remains ";" > > > >I'm guessing there's something hinky with the stabs parsing. Any guesses > >as to where I should look? > > Oh, I guess this hangs after it's printed these messages? If so, it looks No, it runs fine after that, and the data it displays appears valid. > like the same bug as Naveen Kumar just mentioned. Can one of you file a > bug in Bugzilla, please? BUG# 88703 added. Cheers, Steve |
|
From: Tom S. <to...@pl...> - 2004-09-02 15:15:56
|
Nicholas Nethercote wrote: > On Tue, 31 Aug 2004, Robert Walsh wrote: > >>> since supporting systems with low memory or even ulimit -v set seems >>> to be >>> a "non-goal" for valgrind, maybe valgrind itself could have an option to >>> limit the memory available to a program ? I would like to test my >>> programs >>> behaviour in low-mem conditions with valgrind, since it should run on >>> systems with much lower memory than I develop it on. So some >>> --limit-memory=16M option would be really cool. >> >> >> Great idea. > > > How would this work? Would Valgrind (Memcheck?) just abort if the > client used more than the limit? > > N That doesn't sound right. I would think that you would want to return NULL from malloc(), and print a message with the current stack. That way he can make sure that the app recovers gracefully, and if it doesn't, he knows where the app initially ran into the memory ceiling. -- Tom Schutter (mailto:to...@pl...) Platte River Associates, Inc. (http://www.platte.com) |
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 14:23:24
|
On Tue, 31 Aug 2004, Steve Atkins wrote: > When running valgrind --tool=massif on some code compiled with -g > using gcc 2.95, dynamically linked with a bunch of libraries > valgrind throws this at startup: > > ==21540== Massif, a space profiler for x86-linux. > ==21540== Copyright (C) 2003, Nicholas Nethercote > ==21540== Using valgrind-2.2.0, a program supervision framework for x86-linux. > ==21540== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. > @@ unlikely looking definition in unparsed remains ";" > @@ unlikely looking definition in unparsed remains ";" > @@ unlikely looking definition in unparsed remains ";" > @@ unlikely looking definition in unparsed remains ";" > @@ unlikely looking definition in unparsed remains ";" > @@ unlikely looking definition in unparsed remains ";" > @@ unlikely looking definition in unparsed remains ";" > @@ unlikely looking definition in unparsed remains ";" > @@ unlikely looking definition in unparsed remains ";" > ==21540== For more details, rerun with: -v > ==21540== > @@ unlikely looking definition in unparsed remains ";" > @@ unlikely looking definition in unparsed remains ";" > @@ unlikely looking definition in unparsed remains ";" > @@ unlikely looking definition in unparsed remains ";" > @@ unlikely looking definition in unparsed remains ";" > @@ unlikely looking definition in unparsed remains ";" > @@ unlikely looking definition in unparsed remains ";" > @@ unlikely looking definition in unparsed remains ";" > > I'm guessing there's something hinky with the stabs parsing. Any guesses > as to where I should look? Oh, I guess this hangs after it's printed these messages? If so, it looks like the same bug as Naveen Kumar just mentioned. Can one of you file a bug in Bugzilla, please? N |
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 14:21:49
|
On Tue, 31 Aug 2004, Robert Walsh wrote: >> since supporting systems with low memory or even ulimit -v set seems to be >> a "non-goal" for valgrind, maybe valgrind itself could have an option to >> limit the memory available to a program ? I would like to test my programs >> behaviour in low-mem conditions with valgrind, since it should run on >> systems with much lower memory than I develop it on. So some >> --limit-memory=16M option would be really cool. > > Great idea. How would this work? Would Valgrind (Memcheck?) just abort if the client used more than the limit? N |
|
From: Naveen K. <g_n...@ya...> - 2004-09-02 14:15:04
|
Oh it still hangs!!!! Naveen --- Nicholas Nethercote <nj...@ca...> wrote: > On Thu, 2 Sep 2004, Naveen Kumar wrote: > > > Oops sorry I was using Valgrind version 2.1.2. > Only > > after I wrote this email did I notice that 2.2.0 > was > > released. I used that and now I get > > > > @@ unlikely looking definition in unparsed remains > ";" > > > > on the below mentioned exec. > > Does it still hang, or does it run to completion? > > N > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 14:08:48
|
On Thu, 2 Sep 2004, Naveen Kumar wrote: > Oops sorry I was using Valgrind version 2.1.2. Only > after I wrote this email did I notice that 2.2.0 was > released. I used that and now I get > > @@ unlikely looking definition in unparsed remains ";" > > on the below mentioned exec. Does it still hang, or does it run to completion? N |
|
From: Naveen K. <g_n...@ya...> - 2004-09-02 14:03:46
|
Oops sorry I was using Valgrind version 2.1.2. Only after I wrote this email did I notice that 2.2.0 was released. I used that and now I get @@ unlikely looking definition in unparsed remains ";" on the below mentioned exec. BTW the exec was written in C++. Thanks Naveen --- Nicholas Nethercote <nj...@ca...> wrote: > On Wed, 1 Sep 2004, Naveen Kumar wrote: > > > I am running valgrind on a executable and I dont > > see any output. I put in the verbose option for > > valgrind and the last line printed is > > > > ==3145== Reading syms from so-and-so-binary > > (0x8048000) > > > > Thats it. I dont get any output after that. I then > > recompiled coregrind with some of the debug flags > set > > to true and reran the executable. It prints out > lots > > of data and thats it, it just stops at some point. > > There dont seem to be any apparent errors from > those > > logs. Any suggestion ? The linux box is running > the > > Linux-2.4.9-12 kernel. I did test valgrind on a > > simpler executable and it worked fine. On this > > particular executable though I dont have a clue. > > You don't say which Valgrind version you are using. > Is the program you > are running written in Ada? This sounds like bug > #87904 > (http://bugs.kde.org/show_bug.cgi?id=87904). > > N > _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush |