You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
1
(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: Nicholas N. <nj...@ca...> - 2004-09-13 11:15:03
|
On Mon, 13 Sep 2004, Nicholas Nethercote wrote:
>> I had posted earlier about valgrind stalling but
>> since nobody seemed to have encountered it I decided
>> to try investigating myself. I turned on some of the
>> debug flags and added some printf statements at some
>> points in the code. I find that valgrind is going into
>> an infinite loop in one place. These are the debug
>> statements before it stalls
>>
>> initSym(si=0xB02ED020, tab=0xB02FD120, sym=0xB17416F8,
>> kind=128, name=0xB0AC6C46 "msgbuf:Tt(0,27)=xsmsgbuf:",
>> val=0)
>>
>> initSym name="msgbuf" type=Tt(0,27)=xsmsgbuf:
>> initSym: before base type
>>
>> I added the following printfs in vg_stabs.c
>> VG_(printf)("initSym: before base type\n");
>> base = VG_(st_basetype)(sym->type, False);
>> VG_(printf)("initSym: after base type\n");
>>
>> As can be seen from the logs I dont get anything
>> printed after "..before base type..". It is just
>> spinning in VG_(st_basetype).
>
> Can you file a bug report for this please?
Actually, it might be more appropriate to add a comment to
http://bugs.kde.org/show_bug.cgi?id=88703 explaining your situation (I
think that's the bug you're talking about?)
Thanks.
N
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-13 11:12:26
|
On Thu, 9 Sep 2004, Naveen Kumar wrote:
> I had posted earlier about valgrind stalling but
> since nobody seemed to have encountered it I decided
> to try investigating myself. I turned on some of the
> debug flags and added some printf statements at some
> points in the code. I find that valgrind is going into
> an infinite loop in one place. These are the debug
> statements before it stalls
>
> initSym(si=0xB02ED020, tab=0xB02FD120, sym=0xB17416F8,
> kind=128, name=0xB0AC6C46 "msgbuf:Tt(0,27)=xsmsgbuf:",
> val=0)
>
> initSym name="msgbuf" type=Tt(0,27)=xsmsgbuf:
> initSym: before base type
>
> I added the following printfs in vg_stabs.c
> VG_(printf)("initSym: before base type\n");
> base = VG_(st_basetype)(sym->type, False);
> VG_(printf)("initSym: after base type\n");
>
> As can be seen from the logs I dont get anything
> printed after "..before base type..". It is just
> spinning in VG_(st_basetype).
Can you file a bug report for this please?
Thanks.
N
|
|
From: Dennis L. <pla...@tz...> - 2004-09-12 20:38:16
|
Am So, den 12.09.2004 schrieb Julian Seward um 21:20: > That happened to me too. Are you running a SuSE kernel? > No, but running a SuSE 9.1 system with 2.6.7 (vanilla one with acpi, acpidsdt, swsusp2 build 100 patches). Running a P4 2.53 with 512MB RAM and ~800MB swap. Any settings, stuff from /proc that would help to solve this ? overcommit_memory needs to be off for other reasons... I saw sometime that the output of /proc/self/maps helped, so its at the end greets Dennis plasmahh@speedy:/proc/self> cat maps 08048000-080b2000 r-xp 00000000 03:05 1862388 /bin/bash 080b2000-080b5000 rw-p 00069000 03:05 1862388 /bin/bash 080b5000-0817c000 rwxp 080b5000 00:00 0 40000000-40016000 r-xp 00000000 03:05 6826 /lib/ld-2.3.3.so 40016000-40017000 rw-p 00015000 03:05 6826 /lib/ld-2.3.3.so 40017000-40018000 rw-p 40017000 00:00 0 40032000-40059000 r-xp 00000000 03:05 7792 /lib/libreadline.so.4.3 40059000-4005d000 rw-p 00027000 03:05 7792 /lib/libreadline.so.4.3 4005d000-4005e000 rw-p 4005d000 00:00 0 4005e000-40064000 r-xp 00000000 03:05 140356 /lib/libhistory.so.4.3 40064000-40065000 rw-p 00005000 03:05 140356 /lib/libhistory.so.4.3 40065000-4009e000 r-xp 00000000 03:05 1862285 /lib/libncurses.so.5.4 4009e000-400a9000 rw-p 00038000 03:05 1862285 /lib/libncurses.so.5.4 400a9000-400aa000 rw-p 400a9000 00:00 0 400aa000-400ac000 r-xp 00000000 03:05 57050 /lib/libdl.so.2 400ac000-400ad000 rw-p 00002000 03:05 57050 /lib/libdl.so.2 400ad000-400ae000 rw-p 400ad000 00:00 0 400ae000-401b8000 r-xp 00000000 03:05 57069 /lib/tls/libc.so.6 401b8000-401c0000 rw-p 0010a000 03:05 57069 /lib/tls/libc.so.6 401c0000-401c3000 rw-p 401c0000 00:00 0 401c3000-401c4000 r--p 00000000 03:05 674791 /usr/lib/locale/de_DE.utf8/LC_IDENTIFICATION 401c4000-401ca000 r--s 00000000 03:05 6863 /usr/lib/gconv/gconv-modules.cache 401ca000-401cb000 r--p 00000000 03:05 675384 /usr/lib/locale/de_DE.utf8/LC_MEASUREMENT 401cb000-401cc000 r--p 00000000 03:05 295944 /usr/lib/locale/de_DE.utf8/LC_TELEPHONE 401cc000-401cd000 r--p 00000000 03:05 295941 /usr/lib/locale/de_DE.utf8/LC_ADDRESS 401cd000-401ce000 r--p 00000000 03:05 674792 /usr/lib/locale/de_DE.utf8/LC_NAME 401ce000-401cf000 r--p 00000000 03:05 674719 /usr/lib/locale/de_DE.utf8/LC_PAPER 401cf000-401d0000 r--p 00000000 03:05 1588029 /usr/lib/locale/de_DE.utf8/LC_MESSAGES/SYS_LC_MESSAGES 401d0000-401d1000 r--p 00000000 03:05 1588022 /usr/lib/locale/de_DE.utf8/LC_MONETARY 401d1000-401d2000 r--p 00000000 03:05 295947 /usr/lib/locale/de_DE.utf8/LC_TIME 401d2000-401d3000 r--p 00000000 03:05 299402 /usr/lib/locale/de_DE.utf8/LC_NUMERIC 401d3000-4020e000 r--p 00000000 03:05 1369882 /usr/lib/locale/de_DE.utf8/LC_CTYPE 40228000-4022f000 r-xp 00000000 03:05 57056 /lib/libnss_compat.so.2 4022f000-40230000 rw-p 00006000 03:05 57056 /lib/libnss_compat.so.2 40230000-40242000 r-xp 00000000 03:05 57055 /lib/libnsl.so.1 40242000-40243000 rw-p 00011000 03:05 57055 /lib/libnsl.so.1 40243000-40245000 rw-p 40243000 00:00 0 40245000-4024d000 r-xp 00000000 03:05 57060 /lib/libnss_nis.so.2 4024d000-4024e000 rw-p 00007000 03:05 57060 /lib/libnss_nis.so.2 4024e000-40256000 r-xp 00000000 03:05 57058 /lib/libnss_files.so.2 40256000-40257000 rw-p 00008000 03:05 57058 /lib/libnss_files.so.2 40257000-402b8000 rw-p 40257000 00:00 0 402dd000-402fd000 rw-p 402dd000 00:00 0 bfff6000-c0000000 rw-p bfff6000 00:00 0 ffffe000-fffff000 ---p 00000000 00:00 0 |
|
From: Julian S. <js...@ac...> - 2004-09-12 19:20:47
|
That happened to me too. Are you running a SuSE kernel? J On Sunday 12 September 2004 17:29, Dennis Lubert wrote: > Hello people, > > checked out todays valgrind from cvs and noticed that with memcheck tool > at the end of a valgrind run, it tries to allocate all my memory (and so > gets killed by kernel when swap is filled). All tools end now with this > line : > Warning: set address range perms: large range 2147483647, a 1 > > with the 6th september everything was working fine |
|
From: Dennis L. <pla...@tz...> - 2004-09-12 16:29:25
|
Hello people, checked out todays valgrind from cvs and noticed that with memcheck tool at the end of a valgrind run, it tries to allocate all my memory (and so gets killed by kernel when swap is filled). All tools end now with this line : Warning: set address range perms: large range 2147483647, a 1 with the 6th september everything was working fine greets Dennis |
|
From: Naveen K. <g_n...@ya...> - 2004-09-09 19:30:11
|
Hi folks,
I had posted earlier about valgrind stalling but
since nobody seemed to have encountered it I decided
to try investigating myself. I turned on some of the
debug flags and added some printf statements at some
points in the code. I find that valgrind is going into
an infinite loop in one place. These are the debug
statements before it stalls
initSym(si=0xB02ED020, tab=0xB02FD120, sym=0xB17416F8,
kind=128, name=0xB0AC6C46 "msgbuf:Tt(0,27)=xsmsgbuf:",
val=0)
initSym name="msgbuf" type=Tt(0,27)=xsmsgbuf:
initSym: before base type
I added the following printfs in vg_stabs.c
VG_(printf)("initSym: before base type\n");
base = VG_(st_basetype)(sym->type, False);
VG_(printf)("initSym: after base type\n");
As can be seen from the logs I dont get anything
printed after "..before base type..". It is just
spinning in VG_(st_basetype). Any suggestions on what
may be causing this ?
Thanks
Naveen
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
|
|
From: Nicholas M. L. <nm...@cs...> - 2004-09-09 01:45:12
|
hi, found the problem, it was make 3.79.1 :o(. I now have a working valgrind 2.2.0. Sorry to waste your time... cheers Nick On Thu, Sep 09, 2004 at 11:28:50AM +1000, Nicholas Maxwell Lester wrote: > hi all, > > i'm trying to build valgrind 2.2.0 on a redhat v9 machine, and i get the > following problem: > > ~/valgrind-2.2.0$ make > ... (about 20 lines) ... > Making all in demangle > make[4]: Entering directory `/home/n/nml/valgrind-2.2.0/coregrind/demangle' > if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../coregrind -I../../coregrind > -I../ > ../include -I../../include -Winline -Wall -Wshadow -O -fomit-frame-pointer -g > -Wno-unused -Wno-shadow -MT cp-demangle.o -MD -MP -MF ".deps/cp-demangle.Tpo" > -c > -o cp-demangle.o cp-demangle.c; \ > then mv -f ".deps/cp-demangle.Tpo" ".deps/cp-demangle.Po"; else rm -f > ".deps/cp-d > emangle.Tpo"; exit 1; fi > make: expand.c:489: allocated_variable_append: Assertion > `current_variable_set_list->next != 0' failed. > > i can't find the file expand.c under the valgrind source tree. The machine is > an SMP machine if that makes any difference: > > ~/valgrind-2.2.0$ uname -a > Linux xxx.xxx.xxx.xxx 2.4.20-20.9smp #1 SMP Mon Aug 18 11:32:15 EDT 2003 > i686 i686 i386 GNU/Linux > > I tried building version 2.1.2, and it seemed to have the same problem, > although i've previously had version 2.0.0 installed. > > cheers > > Nick > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas M. L. <nm...@cs...> - 2004-09-09 01:30:44
|
hi all, i'm trying to build valgrind 2.2.0 on a redhat v9 machine, and i get the following problem: ~/valgrind-2.2.0$ make ... (about 20 lines) ... Making all in demangle make[4]: Entering directory `/home/n/nml/valgrind-2.2.0/coregrind/demangle' if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../coregrind -I../../coregrind -I../ ../include -I../../include -Winline -Wall -Wshadow -O -fomit-frame-pointer -g -Wno-unused -Wno-shadow -MT cp-demangle.o -MD -MP -MF ".deps/cp-demangle.Tpo" -c -o cp-demangle.o cp-demangle.c; \ then mv -f ".deps/cp-demangle.Tpo" ".deps/cp-demangle.Po"; else rm -f ".deps/cp-d emangle.Tpo"; exit 1; fi make: expand.c:489: allocated_variable_append: Assertion `current_variable_set_list->next != 0' failed. i can't find the file expand.c under the valgrind source tree. The machine is an SMP machine if that makes any difference: ~/valgrind-2.2.0$ uname -a Linux xxx.xxx.xxx.xxx 2.4.20-20.9smp #1 SMP Mon Aug 18 11:32:15 EDT 2003 i686 i686 i386 GNU/Linux I tried building version 2.1.2, and it seemed to have the same problem, although i've previously had version 2.0.0 installed. cheers Nick |
|
From: Peter S. <sei...@ci...> - 2004-09-08 16:47:58
|
On Tue, Sep 07, 2004 at 03:51:29PM +0100, Nicholas Nethercote wrote: > On Tue, 7 Sep 2004, bruce.ferjulian wrote: > > >I receive the following message while running 'valgrind' against my > >threaded application. Any idea when the "incomplete" statement will > >become "complete"? > > > >==15011== warning: Valgrind's pthread_cond_destroy is incomplete > >==15011== (it doesn't check if the cond is waited on) > >==15011== your program may misbehave as a result > >==15011== > > When someone implements it? ;) > > Someone else asked about this recently, attached is my attempt to > implement it (patch should work vs. 2.2.0). IIRC, it didn't actually get > it right, though, and nobody else suggested what the problem was... > > N Or take a look at Bug 85629 (http://bugs.kde.org/show_bug.cgi?id=85629) and the attached patch..... Peter -- ------------------------------------------------------------------------ Peter Seiderer E-Mail: sei...@ci... |
|
From: Emmanuel A. <ma...@ab...> - 2004-09-08 10:43:58
|
This time I subscribed to the list...
I keep getting the assertion failed message when trying to run a program
using asm functions with valgrind 2.2.0 :
valgrind: vg_ldt.c:200 (vgPlain_do_useseg): Assertion `seg_selector >= 6
&& seg_selector < (6 + 3)' failed.
==14644== at 0xB002FF47: vgPlain_skin_assert_fail (vg_mylibc.c:1137)
==14644== by 0xB002FF46: assert_fail (vg_mylibc.c:1133)
==14644== by 0xB002FFB4: vgPlain_core_assert_fail (vg_mylibc.c:1144)
==14644== by 0xB0074EAA: vgPlain_do_useseg (vg_ldt.c:213)
The running thread dies on a "push esi" instruction, at the begining of
a function called the usual way ("call <function name>").
So it does not seem to make much sense, and this program does not change
directly the selectors afaik...
Help ? Hints ?
|
|
From: Emmanuel A. <ma...@ab...> - 2004-09-08 10:18:20
|
Hi ! I keep having the error message when trying to debug a program using asm functions with valgrind 2.2.0. The running thread dies on a "push esi" instruction but it does not seem to make any sense since selectors are not directly changed at all by the program... Hints, help ? (I didn't subscribe to the list) |
|
From: Alex I. <ale...@in...> - 2004-09-07 21:19:30
|
With valgrind 2.2.0, why am I getting swamped with "@@ unlikely looking definition in unparsed reamins ";"" messages when loading shared libraries? What are the implications of these warnings? Alex Julian Seward wrote: >We are pleased to announce a new stable release, valgrind-2.2.0. >It is available from the usual place: http://valgrind.kde.org. > >Happy debugging and profiling > >-- The Valgrind developers > > > >Stable release 2.2.0 (31 August 2004) -- CHANGES RELATIVE TO 2.0.0 >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >2.2.0 brings nine months worth of improvements and bug fixes. We >believe it to be a worthy successor to 2.0.0. There are literally >hundreds of bug fixes and minor improvements. There are also some >fairly major user-visible changes: > >* A complete overhaul of handling of system calls and signals, and > their interaction with threads. In general, the accuracy of the > system call, thread and signal simulations is much improved: > > - Blocking system calls behave exactly as they do when running > natively (not on valgrind). That is, if a syscall blocks only the > calling thread when running natively, than it behaves the same on > valgrind. No more mysterious hangs because V doesn't know that some > syscall or other, should block only the calling thread. > > - Interrupted syscalls should now give more faithful results. > > - Signal contexts in signal handlers are supported. > >* Improvements to NPTL support to the extent that V now works > properly on NPTL-only setups. > >* Greater isolation between Valgrind and the program being run, so > the program is less likely to inadvertently kill Valgrind by > doing wild writes. > >* Massif: a new space profiling tool. Try it! It's cool, and it'll > tell you in detail where and when your C/C++ code is allocating heap. > Draws pretty .ps pictures of memory use against time. A potentially > powerful tool for making sense of your program's space use. > >* File descriptor leakage checks. When enabled, Valgrind will print out > a list of open file descriptors on exit. > >* Improved SSE2/SSE3 support. > >* Time-stamped output; use --time-stamp=yes > > >Stable release 2.2.0 (31 August 2004) -- CHANGES RELATIVE TO 2.1.2 >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >2.2.0 is not much different from 2.1.2, released seven weeks ago. >A number of bugs have been fixed, most notably #85658, which gave >problems for quite a few people. There have been many internal >cleanups, but those are not user visible. > >The following bugs have been fixed since 2.1.2: > >85658 Assert in coregrind/vg_libpthread.c:2326 (open64) != > (void*)0 failed > This bug was reported multiple times, and so the following > duplicates of it are also fixed: 87620, 85796, 85935, 86065, > 86919, 86988, 87917, 88156 > >80716 Semaphore mapping bug caused by unmap (sem_destroy) > (Was fixed prior to 2.1.2) > >86987 semctl and shmctl syscalls family is not handled properly > >86696 valgrind 2.1.2 + RH AS2.1 + librt > >86730 valgrind locks up at end of run with assertion failure > in __pthread_unwind > >86641 memcheck doesn't work with Mesa OpenGL/ATI on Suse 9.1 > (also fixes 74298, a duplicate of this) > >85947 MMX/SSE unhandled instruction 'sfence' > >84978 Wrong error "Conditional jump or move depends on > uninitialised value" resulting from "sbbl %reg, %reg" > >86254 ssort() fails when signed int return type from comparison is > too small to handle result of unsigned int subtraction > >87089 memalign( 4, xxx) makes valgrind assert > >86407 Add support for low-level parallel port driver ioctls. > >70587 Add timestamps to Valgrind output? (wishlist) > >84937 vg_libpthread.c:2505 (se_remap): Assertion `res == 0' > (fixed prior to 2.1.2) > >86317 cannot load libSDL-1.2.so.0 using valgrind > >86989 memcpy from mac_replace_strmem.c complains about > uninitialized pointers passed when length to copy is zero > >85811 gnu pascal symbol causes segmentation fault; ok in 2.0.0 > >79138 writing to sbrk()'d memory causes segfault > >77369 sched deadlock while signal received during pthread_join > and the joined thread exited > >88115 In signal handler for SIGFPE, siginfo->si_addr is wrong > under Valgrind > >78765 Massif crashes on app exit if FP exceptions are enabled > >Additionally there are the following changes, which are not >connected to any bug report numbers, AFAICS: > >* Fix scary bug causing mis-identification of SSE stores vs > loads and so causing memcheck to sometimes give nonsense results > on SSE code. > >* Add support for the POSIX message queue system calls. > >* Fix to allow 32-bit Valgrind to run on AMD64 boxes. Note: this does > NOT allow Valgrind to work with 64-bit executables - only with 32-bit > executables on an AMD64 box. > >* At configure time, only check whether linux/mii.h can be processed > so that we don't generate ugly warnings by trying to compile it. > >* Add support for POSIX clocks and timers. > > > >------------------------------------------------------- >This SF.Net email is sponsored by BEA Weblogic Workshop >FREE Java Enterprise J2EE developer tools! >Get your free copy of BEA WebLogic Workshop 8.1 today. >http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click >_______________________________________________ >Valgrind-users mailing list >Val...@li... >https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > ------------------------------------------------------------------------ Confidentiality Notice: This e-mail transmission may contain confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you. Inet Technologies, Inc. ------------------------------------------------------------------------ |
|
From: Nicholas N. <nj...@ca...> - 2004-09-07 14:51:44
|
On Tue, 7 Sep 2004, bruce.ferjulian wrote: > I receive the following message while running 'valgrind' against my > threaded application. Any idea when the "incomplete" statement will > become "complete"? > > ==15011== warning: Valgrind's pthread_cond_destroy is incomplete > ==15011== (it doesn't check if the cond is waited on) > ==15011== your program may misbehave as a result > ==15011== When someone implements it? ;) Someone else asked about this recently, attached is my attempt to implement it (patch should work vs. 2.2.0). IIRC, it didn't actually get it right, though, and nobody else suggested what the problem was... N |
|
From: Tom H. <th...@cy...> - 2004-09-07 14:50:23
|
In message <5.2.1.1.2.20040907102023.03c8be50@api253>
bruce ferjulian <fer...@em...> wrote:
> I receive the following message while running 'valgrind' against my
> threaded application. Any idea when the "incomplete" statement will
> become "complete"?
When somebody finds the incompleteness enough of an itch to
warrant scratching it?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: bruce.ferjulian <fer...@em...> - 2004-09-07 14:23:34
|
I receive the following message while running 'valgrind' against my threaded application. Any idea when the "incomplete" statement will become "complete"? ==15011== warning: Valgrind's pthread_cond_destroy is incomplete ==15011== (it doesn't check if the cond is waited on) ==15011== your program may misbehave as a result ==15011== -Bruce- |
|
From: Tom H. <th...@cy...> - 2004-09-07 12:24:33
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> It means GCC cannot find your libc, which is very strange. This has
> come up before, but I can't remember what the solution was. Perhaps
> someone (Tom?) can remember how to handle this one.
I believe the solution was to install the glibc-devel package...
Actually, the bug was 85932 and the solution was to install the
glibc-static-devel package, which seems to be a Mandrake thing.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-07 12:02:12
|
On Tue, 7 Sep 2004, Oswald Buddenhagen wrote: >> It can't really do so - no run time only system can. >> > actually, i think a run time only solution would work to some extent, > particularly if we have debug info available. I've worked on this, and got a runtime-only tool working that could detect bounds errors on static arrays (but not stack arrays). It relies on debug information to know where the static arrays are. Unfortunately the technique is not very robust which is why it's not in the Valgrind distribution, and probably never will be. Detecting these bounds errors is really something that is best done at the source level, so GCC's bounds-checking patches or Insure++ seem the best option. N |
|
From: Nicholas N. <nj...@ca...> - 2004-09-07 11:32:11
|
[CC'ing reply to valgrind-users] On Tue, 7 Sep 2004, tikcireviva wrote: > I am having a installation problem regarding to the *make* command. My > plateform is mandrake10, with glibc.2.3.3. During the *make* command, it > beeps me with the following, I hope that you may help, please. > > gcc -Winline -Wall -Wshadow -O -fno-omit-frame-pointer > -mpreferred-stack-boundary=2 -g -DELFSZ=32 -o valgrind -static -g > -Wl,-e,_ume_entry stage1.o ume.o ume_entry.o ume_go.o > /usr/bin/ld: cannot find -lc > collect2: ld returned 1 exit status > make[4]: *** [valgrind] Error 1 > make[4]: Leaving directory `/home/eric/download/valgrind-2.2.0/coregrind' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/home/eric/download/valgrind-2.2.0/coregrind' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/home/eric/download/valgrind-2.2.0/coregrind' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/eric/download/valgrind-2.2.0' > make: *** [all] Error 2 > > I wonder if this is a problem regarding to my glibc library, and that's what > I've got from the internet. If you know any solution, could you mind please > advice? I am really appreciate your help. Thank you very much. It means GCC cannot find your libc, which is very strange. This has come up before, but I can't remember what the solution was. Perhaps someone (Tom?) can remember how to handle this one. N |
|
From: Andrew C. <and...@fr...> - 2004-09-07 10:22:58
|
Hey guys, I have a program which valgrind runs fine, until I link in a particular object file, at which point I get: ==22314== Memcheck, a memory error detector for x86-linux. ==22314== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==22314== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==22314== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. @@ unlikely looking definition in unparsed remains ";" @@ don't know what type ':' is @@ parsing :_Lock:Tt(129,76)=s1operator=::(129,77)=#(129,76),(129,78)=&(129,76),(129,79)=*(129,76),(129,80)=&(129,81)=k(129,76),(0,19);:_ZNSt24__default_alloc_templateILb1ELi0EE5_LockaSERKS1_;2A.;__base_ctor::(129,82)=#(129,76),(0,19),(129,79),(129,80),(0,19);:_ZNSt24__default_alloc_templateILb1ELi0EE5_LockC2ERKS1_;2A.;__comp_ctor::(129,82):_ZNSt24__default_alloc_templateILb1ELi0EE5_LockC1ERKS1_;2A.;__base_ctor::(129,83)=#(129,76),(0,19),(129,79),(0,19);:_ZNSt24__default_alloc_templateILb1ELi0EE5_LockC2Ev;2A.;__comp_ctor::(129,83):_ZNSt24__default_alloc_templateILb1ELi0EE5_LockC1Ev;2A.;__base_dtor::(129,83):_ZNSt24__default_alloc_templateILb1ELi0EE5_LockD2Ev;2A.;__comp_dtor::(129,83):_ZNSt24__default_alloc_templateILb1ELi0EE5_LockD1Ev;2A.;; gave NULL type (_Lock:Tt(129,76)=s1operator=::(129,77)=#(129,76),(129,78)=&(129,76),(129,79)=*(129,76),(129,80)=&(129,81)=k(129,76),(0,19);:_ZNSt24__default_alloc_templateILb1ELi0EE5_LockaSERKS1_;2A.;__base_ctor::(129,82)=#(129,76),(0,19),(129,79),(129,80),(0,19);:_ZNSt24__default_alloc_templateILb1ELi0EE5_LockC2ERKS1_;2A.;__comp_ctor::(129,82):_ZNSt24__default_alloc_templateILb1ELi0EE5_LockC1ERKS1_;2A.;__base_ctor::(129,83)=#(129,76),(0,19),(129,79),(0,19);:_ZNSt24__default_alloc_templateILb1ELi0EE5_LockC2Ev;2A.;__comp_ctor::(129,83):_ZNSt24__default_alloc_templateILb1ELi0EE5_LockC1Ev;2A.;__base_dtor::(129,83):_ZNSt24__default_alloc_templateILb1ELi0EE5_LockD2Ev;2A.;__comp_dtor::(129,83):_ZNSt24__default_alloc_templateILb1ELi0EE5_LockD1Ev;2A.;; remains) Segmentation fault The new object code isn't being used in the program at all, BTW. I can send the binary (built with debugging info) to anyone interested. -- Andrew Chapman Senior Technical Director - Framestore CFC |
|
From: Jean P. <2s...@ma...> - 2004-09-06 23:35:34
|
On Mon, 06 Sep 2004 16:27:07 -0700, Paul Pluzhnikov <pa...@pa...> wrote : > > Oops. By 'static' array, I wanted to mean a 'normal array' (as > > oppposed to dynamically allocated array). > > What you meant are arrays with automatic or static (as opposed > to dynamic) storage duration. > > > Do you know if valgrind could in theory detect this kind of problem > > too > > This has been discussed here many times before. > > The consensus appears to be that VG will never be able to reliably > catch either: > http://sourceforge.net/mailarchive/message.php?msg_id=7603767 > http://sourceforge.net/mailarchive/message.php?msg_id=8776351 > > Purify does detect (some?) static (but not automatic) array > bounds, because they insert red-zones during the link stage. > > CCured detects both, but only for C (no C++ support). Ok thanks for the information. I've looked at CCured but it seems to be quite hard to use on large projects, so I will stay with gcc bounds-checking (which does an excellent job, I wonder why it isn't more famous ?). Sorry to haven't made a search on the subject before posting... |
|
From: Paul P. <pa...@pa...> - 2004-09-06 23:28:12
|
Jean Pierre wrote: > Oops. By 'static' array, I wanted to mean a 'normal array' (as oppposed > to dynamically allocated array). What you meant are arrays with automatic or static (as opposed to dynamic) storage duration. > Do you know if valgrind could in theory detect this kind of problem too This has been discussed here many times before. The consensus appears to be that VG will never be able to reliably catch either: http://sourceforge.net/mailarchive/message.php?msg_id=7603767 http://sourceforge.net/mailarchive/message.php?msg_id=8776351 Purify does detect (some?) static (but not automatic) array bounds, because they insert red-zones during the link stage. CCured detects both, but only for C (no C++ support). Cheers, |
|
From: Oswald B. <os...@kd...> - 2004-09-06 23:16:23
|
On Tue, Sep 07, 2004 at 12:07:46AM +0100, Tom Hughes wrote: > It can't really do so - no run time only system can. > actually, i think a run time only solution would work to some extent, particularly if we have debug info available. julian, do you happen to still have the mails i sent you two years ago? :) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Jean P. <2s...@ma...> - 2004-09-06 23:15:54
|
On Tue, 07 Sep 2004 00:07:46 +0100, Tom Hughes <th...@cy...> wrote : > > 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. > > It can't really do so - no run time only system can. The only systems > that detect that problem are those that do compile time manipulations > to either add bounds checking or insert guard words between the stack > variables. > Thanks for your answer. I'm stuck with Insure++ and gcc bounds-checking then... |
|
From: Tom H. <th...@cy...> - 2004-09-06 23:07:47
|
In message <20040906235552.04af6d04@linuxcestcomplique>
Jean Pierre <2s...@ma...> wrote:
> 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.
It can't really do so - no run time only system can. The only systems
that detect that problem are those that do compile time manipulations
to either add bounds checking or insert guard words between the stack
variables.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jean P. <2s...@ma...> - 2004-09-06 22:56:51
|
On Mon, 06 Sep 2004 15:15:41 -0700, Paul Pluzhnikov <pa...@pa...> wrote : > 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? Oops. By 'static' array, I wanted to mean a 'normal array' (as oppposed to dynamically allocated 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): > Great ! I'll try their product. Do you know if valgrind could in theory detect this kind of problem too ? |