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
(18) |
2
(6) |
|
3
(2) |
4
(2) |
5
(5) |
6
(12) |
7
(2) |
8
(1) |
9
(2) |
|
10
(6) |
11
(11) |
12
(12) |
13
(3) |
14
(3) |
15
(2) |
16
|
|
17
(2) |
18
(3) |
19
(43) |
20
(22) |
21
(10) |
22
(21) |
23
(5) |
|
24
|
25
(3) |
26
(12) |
27
(3) |
28
(14) |
29
(25) |
30
(5) |
|
31
(6) |
|
|
|
|
|
|
|
From: Paul P. <ppl...@gm...> - 2005-07-20 05:27:05
|
On 7/19/05, Tom Hughes <to...@co...> wrote: > > valgrind: syswrap-amd64-linux.c:720 > > (vgSysWrap_amd64_linux_sys_arch_prctl_before): Assertion 'ARG1 =3D=3D > > VKI_ARCH_SET_FS' failed. >=20 > This should be fixed now. Confirmed. > > valgrind: syswrap-main.c:814 (vgPlain_post_syscall): Assertion 'eq_Sysc= allStatus > > ( &sci->status, &test_status )' failed. >=20 > As should this.=20 Ditto. Thanks, |
|
From: Tom H. <to...@co...> - 2005-07-19 23:04:50
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Thu, 30 Jun 2005, Olly Betts wrote:
>=20
> > On 2005-06-30, Nicholas Nethercote <nj...@cs...> wrote:
> >> It would be useful to have some more people using it to help iron ou=
t
> >> remaining bugs. Thanks.
> >
> > I get this failure multiple times with some programs while others run=
fine:
> >
> > lt-btreetest: ../nptl/sysdeps/unix/sysv/linux/fork.c:132: __libc_fork=
: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) =3D=3D=
1) asm volatile ("movb %%fs:%P2,%b0" : "=3Dq" (__value) : "0" (0), "i" (=
((size_t) &((struct pthread *)0)->tid))); else if (sizeof (__value) =3D=3D=
4) asm volatile ("movl %%fs:%P1,%0" : "=3Dr" (__value) : "i" (((size_t) =
&((struct pthread *)0)->tid))); else { if (sizeof (__value) !=3D 8) abort=
(); asm volatile ("movq %%fs:%P1,%q0" : "=3Dr" (__value) : "i" (((size_t=
) &((struct pthread *)0)->tid))); } __value; }) !=3D ppid' failed.
>=20
> This is now logged as bug report #109358.
It should now be fixed - the last two arguments to clone need to be
reversed on amd64 as the kernel expects them the other way round...
> > According to strace the program doesn't call fork when run normally (=
not
> > under valgrind).
It won't do, it will call clone. Modern glibc's use clone (with the
appropriate flags) to implement fork.
Tom
--=20
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dennis L. <pla...@in...> - 2005-07-19 22:54:54
|
At 20:37 19.07.2005, Nicholas Nethercote wrote: >On Tue, 19 Jul 2005, Dennis Lubert wrote: > >This is good to know... very few others have said things like this which >is why Helgrind has always been a lower priority thing. Generally, >feedback indicates to us that people really hate false positives, and >Helgrind's high number of them is a big problem for most people. Yeah, false positives are always nasty. The problem with multithreading is that locking there is a really complex field, and more complex is effective programming where no locking is needed sometimes because of program flow prevents concurrent access. On the one hand I doubt that there will be ever an effective algorithm that will eliminate all those false positives. On the other hand I dont think that it will be necessary, since people who write multithreaded programs should be able to identify false positives. One thing that comes to my mind here is some kind of online-auto-suppression. In the current suppression mechanism, you ask for generating suppression, copy/paste it into some suppression file, and use this at the command line to re-run the program. Better would be some mechanism, where the currently generated suppresion can be chosen to be suppressed for the further program run, and automagically entered into some program-specific suppression file. So "disabling" the false positives would be rather fast and filtering the real bad situations should be faster and more straightforward... >Maybe a brief description of each one in the usage question would be useful. Yeah, great idea... of every installed tool if this is possible, so additionally installed tools can advertise themselves too... Carpe quod tibi datum est |
|
From: Tom H. <to...@co...> - 2005-07-19 22:45:23
|
In message <2a2...@ma...>
Paul Pluzhnikov <ppl...@gm...> wrote:
> On 7/19/05, Tom Hughes <to...@co...> wrote:
>
> > Can you run with --trace-syscalls=yes so we can see what arguments are
> > being given to prctl.
>
> SYSCALL[8307,1](158) arch_prctl ( 4099, 349FDDA8 )
> valgrind: syswrap-amd64-linux.c:720
> (vgSysWrap_amd64_linux_sys_arch_prctl_before): Assertion 'ARG1 ==
> VKI_ARCH_SET_FS' failed.
This should be fixed now.
> > > > > On FC2-i686 the same test triggers:
> >
> > Once again, can you run with --trace-syscalls=yes so we can see what
> > the last system call made was as that will be what caused the assertion.
>
> SYSCALL[17749,1](244) sys_get_thread_area ( 0x52BFE984 ) -->
> [pre-fail] Failure(0x0)
>
> valgrind: syswrap-main.c:814 (vgPlain_post_syscall): Assertion 'eq_SyscallStatus
> ( &sci->status, &test_status )' failed.
As should this. Thanks for the traces and test cases.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-19 22:22:00
|
On Tue, 19 Jul 2005, Julian Seward wrote: > I must say I find helgrind perplexing and frustrating, because it's > potentially such an incredibly useful tool, yet we have never really > made it work as convincingly as I'd like, and now we seem to be > slipping away from being able to support it. I'd love to be able to > make a good showing with Helgrind in the future, but it strikes me > that the difficulties with it put it right at the edge of the > state-of-the-art. I think data race detection is definitely not a solved problem. As Arndt pointed out, being able to use Valgrind/Helgrind as a platform for research in this area is a worthy goal. N |
|
From: Nicholas N. <nj...@cs...> - 2005-07-19 21:32:25
|
On Thu, 30 Jun 2005, Olly Betts wrote:
> On 2005-06-30, Nicholas Nethercote <nj...@cs...> wrote:
>> It would be useful to have some more people using it to help iron out
>> remaining bugs. Thanks.
>
> I get this failure multiple times with some programs while others run fine:
>
> lt-btreetest: ../nptl/sysdeps/unix/sysv/linux/fork.c:132: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (((size_t) &((struct pthread *)0)->tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (((size_t) &((struct pthread *)0)->tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (((size_t) &((struct pthread *)0)->tid))); } __value; }) != ppid' failed.
This is now logged as bug report #109358.
N
> According to strace the program doesn't call fork when run normally (not under
> valgrind).
>
> The program uses valgrind client requests, and is written in C++. Nothing
> particularly unusual about it otherwise. I'm running Ubuntu Linux 5.04
> (kernel 2.6.10).
>
> In the (probably likely) event that you need more information, let me know
> what.
>
> Or you can download the code yourself to try if you wish - it's the Xapian
> search engine library:
>
> http://www.xapian.org/download.php
>
> Download "xapian-core", untar and:
>
> cd xapian-core-0.9.1
> ./configure
> make
> cd tests
> ./runtest ./btreetest
>
> (runtest is just a wrapper shell script to encapsulate the runes required to
> run valgrind "through" libtool).
>
> The valgrind client requests are in testsuite/testsuite.cc (from the top
> level).
>
> Cheers,
> Olly
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|
|
From: Paul P. <ppl...@gm...> - 2005-07-19 20:28:50
|
On 7/19/05, Tom Hughes <to...@co...> wrote:
> Can you run with --trace-syscalls=3Dyes so we can see what arguments are
> being given to prctl.
SYSCALL[8307,1](158) arch_prctl ( 4099, 349FDDA8 )
valgrind: syswrap-amd64-linux.c:720
(vgSysWrap_amd64_linux_sys_arch_prctl_before): Assertion 'ARG1 =3D=3D
VKI_ARCH_SET_FS' failed.
This trivial test reproduces the problem:
--- cut ---
#include <asm/prctl.h>
int main()
{
unsigned long x;
return arch_prctl(ARCH_GET_FS, &x);
}
--- cut ---
> > > > On FC2-i686 the same test triggers:
>=20
> Once again, can you run with --trace-syscalls=3Dyes so we can see what
> the last system call made was as that will be what caused the assertion.
SYSCALL[17749,1](244) sys_get_thread_area ( 0x52BFE984 ) -->
[pre-fail] Failure(0x0)
valgrind: syswrap-main.c:814 (vgPlain_post_syscall): Assertion 'eq_SyscallS=
tatus
( &sci->status, &test_status )' failed.
The test case:
--- cut ---
#include <unistd.h>
#include <syscall.h>
typedef struct {
unsigned int entry_number;
unsigned long int base_addr;
unsigned int limit;
unsigned int seg_32bit:1;
unsigned int contents:2;
unsigned int read_exec_only:1;
unsigned int limit_in_pages:1;
unsigned int seg_not_present:1;
unsigned int useable:1;
unsigned int empty:25;
} LDT;
int main()
{
LDT ldt;
ldt.entry_number =3D 6;
return syscall(SYS_get_thread_area, &ldt);
}
--- cut ---
Cheers,
|
|
From: Dirk M. <dm...@gm...> - 2005-07-19 19:14:07
|
On Tuesday 19 July 2005 14:04, Allin Cottrell wrote: > Has anyone else seen this with 2.4.0? Does anyone have a suggestion > on how I could produce a more useful report? configure with --disable-pie Dirk |
|
From: Julian S. <js...@ac...> - 2005-07-19 19:11:40
|
> goes down on an assertion failure while reading in the symtab. 2.4 has no > problem running this example. 3.0 is reading stuff from the symtab that 2.4 doesn't even try to. > /home/bill/dev/others/oa/tools.lnx86/lib/liboaDB.so (0x1B908000) > > valgrind: symtab.c:884 (canonicaliseCfiSI): Assertion 'si->cfisi[i].base < > si->cfisi[i+1].base' failed. Could you send me a bzip2'd copy of liboaDB.so so I can see what goes wrong when V reads stuff (the call frame info) from it? Thanks J |
|
From: Nicholas N. <nj...@cs...> - 2005-07-19 18:56:19
|
On Tue, 19 Jul 2005, Dirk Mueller wrote: >> Good point. Dirk, can you please add a 3.0 entry to Bugzilla? > > done. Thanks. I guess we should have a 3.0.0 entry as well as a 3.0 SVN entry; sorry, I should have been clearer. N |
|
From: Dirk M. <dm...@gm...> - 2005-07-19 18:54:52
|
On Tuesday 19 July 2005 20:42, Nicholas Nethercote wrote: > Good point. Dirk, can you please add a 3.0 entry to Bugzilla? done. |
|
From: Nicholas N. <nj...@cs...> - 2005-07-19 18:42:16
|
On Tue, 19 Jul 2005, Bill Hoover wrote: > I looked in bugzilla, but it doesn't look like that is set up for the > 3.0 version Good point. Dirk, can you please add a 3.0 entry to Bugzilla? Thanks. N |
|
From: Nicholas N. <nj...@cs...> - 2005-07-19 18:37:19
|
On Tue, 19 Jul 2005, Dennis Lubert wrote: > I personally used helgrind in the "old days" quite often. Although it gave > tons of (more or less) false positives (sometimes program flow does prevent > concurrent access which cant be detected by helgrind of course) it was really > very useful and I found many bugs. This is good to know... very few others have said things like this which is why Helgrind has always been a lower priority thing. Generally, feedback indicates to us that people really hate false positives, and Helgrind's high number of them is a big problem for most people. > I check rather often if something is done at the helgrind front since there > is no similar free tool. I think a big problem why not many people use > helgrind is because they know valgrind as "memory overflow, leak check and > uninitialized value detection tool" but not as the powerful framework for > many other tools (massif is of great use sometimes too) that it actually is. > Perhaps more advertising other feature tools of valgrind will increase > knowledge and thus usage too. Perhaps the next survey should include (if the > old didnt already) a "have you heard about tool xxx previously" question > before asking fo its usage... Maybe a brief description of each one in the usage question would be useful. N |
|
From: Bill H. <ho...@de...> - 2005-07-19 18:14:32
|
After Julian's recent message asking us to try things prior to a release, I grabbed the current svn 3.0 code and built it on an FC4 machine (using the default gcc 4). Most things seem to work well, but one example I tried goes down on an assertion failure while reading in the symtab. 2.4 has no problem running this example. I looked in bugzilla, but it doesn't look like that is set up for the 3.0 version, so here is the info. If there is anything I can do to help look into this, please let me know. (liboaDB.so is about 5MiB and is an older C++ library). [bill@lumwork2 pwtest]$ valgrind -v oainfo ==6888== Memcheck, a memory error detector. ==6888== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==6888== Using LibVEX rev 1277, a library for dynamic binary translation. ==6888== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==6888== Using valgrind-3.0.0.SVN, a dynamic binary instrumentation framework. ==6888== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. --6888-- Valgrind library directory: /home/bill/donotbackup/valgrind/install/lib/valgrind --6888-- Command line --6888-- oainfo --6888-- Startup, with flags: --6888-- --tool=memcheck --6888-- --trace-children=no --6888-- --demangle=yes --6888-- --num-callers=16 --6888-- --error-limit=no --6888-- --run-libc-freeres=no --6888-- -v --6888-- -- --6888-- Contents of /proc/version: --6888-- Linux version 2.6.12-1.1390_FC4smp (bhc...@de...) (gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)) #1 SMP Tue Jul 5 20:21:11 EDT 2005 --6888-- Reading syms from /home/bill/dev/bin/oainfo (0x8048000) --6888-- Reading syms from /lib/ld-2.3.5.so (0x1B8E4000) --6888-- Reading syms from /home/bill/donotbackup/valgrind/install/lib/valgrind/stage2 (0xB0000000) --6888-- Reading suppressions file: /home/bill/donotbackup/valgrind/install/lib/valgrind/default.supp ==6888== --6888-- Reading syms from /home/bill/donotbackup/valgrind/install/lib/valgrind/vg_preload_core.so (0x1B901000) --6888-- Reading syms from /home/bill/donotbackup/valgrind/install/lib/valgrind/vgpreload_memcheck.so (0x1B903000) --6888-- REDIR: 0x1B8F9B50 (index) redirected to 0x1B9060DC (index) --6888-- Reading syms from /home/bill/dev/others/oa/tools.lnx86/lib/liboaDB.so (0x1B908000) valgrind: symtab.c:884 (canonicaliseCfiSI): Assertion 'si->cfisi[i].base < si->cfisi[i+1].base' failed. |
|
From: Tom H. <to...@co...> - 2005-07-19 18:06:03
|
In message <2a2...@ma...>
Paul Pluzhnikov <ppl...@gm...> wrote:
> > > Finally, Insure++-instrumented binaries trigger:
> > > valgrind: syswrap-amd64-linux.c:718
> > > (vgSysWrap_amd64_linux_sys_arch_prctl_before): Assertion 'ARG1 ==
> > > VKI_ARCH_SET_FS' failed.
>
> The same assert still fails, now on line 720.
Can you run with --trace-syscalls=yes so we can see what arguments are
being given to prctl.
> Running 'autogen.sh' on FC2-i686 produces (valgrind svn rev. 4191)
> $ ./autogen.sh
> running: aclocal
> /usr/share/aclocal/vorbis.m4:9: warning: underquoted definition of
> XIPH_PATH_VORBIS
> run info '(automake)Extending aclocal'
> or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal
> /usr/share/aclocal/pkg.m4:5: warning: underquoted definition of
> PKG_CHECK_MODULES
> /usr/share/aclocal/ogg.m4:8: warning: underquoted definition of XIPH_PATH_OGG
> /usr/share/aclocal/libmikmod.m4:11: warning: underquoted definition of
> AM_PATH_LIBMIKMOD
Those don't matter, and they're an issue with your local installation
of the ogg/vorbis development packages.
> > > On FC2-i686 the same test triggers:
> > > valgrind: syswrap-main.c:812 (vgPlain_post_syscall): Assertion
> > > 'eq_SyscallStatus( &sci->status, &test_status )' failed.
>
> That assert also fails, now on line 814.
Once again, can you run with --trace-syscalls=yes so we can see what
the last system call made was as that will be what caused the assertion.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Paul P. <ppl...@gm...> - 2005-07-19 17:57:02
|
On 7/18/05, Nicholas Nethercote <nj...@cs...> wrote: > Paul, >=20 > Are you still seeing the problems you reported below? Thanks. > On Sat, 2 Jul 2005, Paul Pluzhnikov wrote: >=20 > > Today's SVN checkout fails to build on > > Red Hat Enterprise Linux AS release 3 (Taroon Update 2) x86_64 with > > gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-39), binutils-2.14.90.0.4= -35 The problem above is gone. > > Every program on this system produces several of these: > > =3D=3D15027=3D=3D Warning: zero-sized CIE/FDE but not at section end in= DWARF2 > > CFI reading The warning(s) above remain. > > Finally, Insure++-instrumented binaries trigger: > > valgrind: syswrap-amd64-linux.c:718 > > (vgSysWrap_amd64_linux_sys_arch_prctl_before): Assertion 'ARG1 =3D=3D > > VKI_ARCH_SET_FS' failed. The same assert still fails, now on line 720. Running 'autogen.sh' on FC2-i686 produces (valgrind svn rev. 4191) $ ./autogen.sh=20 running: aclocal /usr/share/aclocal/vorbis.m4:9: warning: underquoted definition of XIPH_PATH_VORBIS run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20acloc= al /usr/share/aclocal/pkg.m4:5: warning: underquoted definition of PKG_CHECK_MODULES /usr/share/aclocal/ogg.m4:8: warning: underquoted definition of XIPH_PATH_O= GG /usr/share/aclocal/libmikmod.m4:11: warning: underquoted definition of AM_PATH_LIBMIKMOD > > On FC2-i686 the same test triggers: > > valgrind: syswrap-main.c:812 (vgPlain_post_syscall): Assertion > > 'eq_SyscallStatus( &sci->status, &test_status )' failed. That assert also fails, now on line 814. Cheers, |
|
From: Julian S. <ju...@va...> - 2005-07-19 17:22:00
|
> - From basic tests, it appears to me that it is quite a bit slower (2.4 > SVN starts up the server in 11 seconds, whereas 3.0 SVN takes 23 > seconds). The new JIT is a lot slower than the 2.4 one, unfortunately. Most of the startup delay is likely to be translation time. > - Interestingly, 2.4 doesn't report _any_ of these uninitialised values, > and when running under 3.0 the server segfaults whereas it doesn't under > 2.4 or without valgrind. Euh, that sucks. Do you get any useful logging output just before the crash? Does it still crash with --tool=none? What about with --tool=none --vex-iropt-level=0 ? > > I am wondering if 3.0 and 2.4 report different cpu capabilities (such as > mmx, sse etc) Quite possibly. Rerun with -v -v and look for a line like this: --5075-- Host CPU: arch = X86, subarch = x86-sse2 J |
|
From: Dennis L. <pla...@in...> - 2005-07-19 17:12:19
|
At 18:47 19.07.2005, Nicholas Nethercote wrote: >On Tue, 19 Jul 2005, Duncan Sands wrote: > >Jeremy wrote some code to intercept pthread functions, which would allow >Helgrind to be reinstated. It's currently commented out in the 3.0 >version, and I'm not sure how well it was working. > >Helgrind doesn't seem very popular in general. The December 2003 survey >told us that it accounted for less than 1% of all Valgrind use, and the >feedback since then hasn't given me any indication that things have changed. > >Nonetheless, we would like to get Helgrind working again. The >pthread-interception stuff is also necessary to get the basic pthread >error checking working again. I personally used helgrind in the "old days" quite often. Although it gave tons of (more or less) false positives (sometimes program flow does prevent concurrent access which cant be detected by helgrind of course) it was really very useful and I found many bugs. I check rather often if something is done at the helgrind front since there is no similar free tool. I think a big problem why not many people use helgrind is because they know valgrind as "memory overflow, leak check and uninitialized value detection tool" but not as the powerful framework for many other tools (massif is of great use sometimes too) that it actually is. Perhaps more advertising other feature tools of valgrind will increase knowledge and thus usage too. Perhaps the next survey should include (if the old didnt already) a "have you heard about tool xxx previously" question before asking fo its usage... greets Dennis Carpe quod tibi datum est |
|
From: Julian S. <js...@ac...> - 2005-07-19 16:59:11
|
I must say I find helgrind perplexing and frustrating, because it's potentially such an incredibly useful tool, yet we have never really made it work as convincingly as I'd like, and now we seem to be slipping away from being able to support it. I'd love to be able to make a good showing with Helgrind in the future, but it strikes me that the difficulties with it put it right at the edge of the state-of-the-art. The key problem is getting observability on all the lock/unlock events that the client program does. We at least had a handle on that <= 2.2.0, but it all went south in 2.4.0. Jeremy tried valiantly to get it to go in 2.4.0, but that didn't work well enough to ship. Now I'm wondering if we could use our general redirect/intercept mechanism to catch all entries into libpthread. In 2.4.0 Jeremy tried one way of doing function wrapping, but it involved some pretty intrusive changes to the JIT which I wasn't happy about. However, we could surely do the relevant function wrapping with the mechanism we have in place in the valgrind-3 line already; we don't need fully general function wrapping to make this work. Urk. It's all complicated and nasty. J On Tuesday 19 July 2005 17:16, Duncan Sands wrote: > > What about helgrind? > > > > After dropping it in 2.4.0 are there any plans to get it up > > and running again in the 3.x line? > > > > I'm asking, because I'm currently doing some research on > > finding bugs in multi-threaded applications and helgrind > > was/would be a good start, being the only usable tool in > > this area that is free and with source available. > > > > BTW, is anybody using helgrind actually? > > Or are there just too many false reports for most applications? > > I am also interested in helgrind, though I haven't tried to use > it seriously. My impression from a few quick tests was that it > does catch real mistakes. Though it produced many false > positives, the ratio of true to false positives didn't seem too > bad. This was some time ago. > > All the best, > > Duncan. > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Crispin F. <val...@fl...> - 2005-07-19 16:54:14
|
On Tue, 2005-07-19 at 14:27 +0100, Julian Seward wrote: > - pls download, build, test, report critical bugs I downloaded this, and gave it a test with the Zeus Web Server (www.zeus.com): - From basic tests, it appears to me that it is quite a bit slower (2.4 SVN starts up the server in 11 seconds, whereas 3.0 SVN takes 23 seconds). - More seriously, 3.0 seems to have lots of: ==903== Use of uninitialised value of size 4 ==903== at 0x81AC95E: (within zeus.web) and these don't have any backtrace at all, whereas when it complains that the read was inside a malloc, I get a backtrace just fine (this is with debug builds) - Interestingly, 2.4 doesn't report _any_ of these uninitialised values, and when running under 3.0 the server segfaults whereas it doesn't under 2.4 or without valgrind. I am wondering if 3.0 and 2.4 report different cpu capabilities (such as mmx, sse etc) and one of the libraries we use is using different code paths. That might explain the uninitialised values, although I don't see how that could explain the lack of backtraces. I realise that this isn't 100% helpful without a testcase, but extracting the code for a testcase as the library I believe is causing problems is something we don't have the code for :-( (Linux/x86) Crispin |
|
From: Nicholas N. <nj...@cs...> - 2005-07-19 16:47:32
|
On Tue, 19 Jul 2005, Duncan Sands wrote: >> What about helgrind? >> >> After dropping it in 2.4.0 are there any plans to get it up >> and running again in the 3.x line? >> >> I'm asking, because I'm currently doing some research on >> finding bugs in multi-threaded applications and helgrind >> was/would be a good start, being the only usable tool in >> this area that is free and with source available. >> >> BTW, is anybody using helgrind actually? >> Or are there just too many false reports for most applications? > > I am also interested in helgrind, though I haven't tried to use > it seriously. My impression from a few quick tests was that it > does catch real mistakes. Though it produced many false > positives, the ratio of true to false positives didn't seem too > bad. This was some time ago. Jeremy wrote some code to intercept pthread functions, which would allow Helgrind to be reinstated. It's currently commented out in the 3.0 version, and I'm not sure how well it was working. Helgrind doesn't seem very popular in general. The December 2003 survey told us that it accounted for less than 1% of all Valgrind use, and the feedback since then hasn't given me any indication that things have changed. Nonetheless, we would like to get Helgrind working again. The pthread-interception stuff is also necessary to get the basic pthread error checking working again. N |
|
From: Duncan S. <bal...@fr...> - 2005-07-19 16:16:25
|
> What about helgrind? > > After dropping it in 2.4.0 are there any plans to get it up > and running again in the 3.x line? > > I'm asking, because I'm currently doing some research on > finding bugs in multi-threaded applications and helgrind > was/would be a good start, being the only usable tool in > this area that is free and with source available. > > BTW, is anybody using helgrind actually? > Or are there just too many false reports for most applications? I am also interested in helgrind, though I haven't tried to use it seriously. My impression from a few quick tests was that it does catch real mistakes. Though it produced many false positives, the ratio of true to false positives didn't seem too bad. This was some time ago. All the best, Duncan. |
|
From: Arndt M. <amu...@is...> - 2005-07-19 15:40:52
|
Its great to see such good work go on! What about helgrind? After dropping it in 2.4.0 are there any plans to get it up and running again in the 3.x line? I'm asking, because I'm currently doing some research on finding bugs in multi-threaded applications and helgrind was/would be a good start, being the only usable tool in this area that is free and with source available. BTW, is anybody using helgrind actually? Or are there just too many false reports for most applications? Greetings, Arndt |
|
From: Konstantin K. <ko...@is...> - 2005-07-19 15:15:15
|
Hello all, I've just downloaded & installed valgrind (ver. 2.4.0) on RedHat 6.0 box. But all it can say is "valgrind: we didn't see enough auxv entries (seen=0)" (even when called as "valgrind --version"). As I've said, it is a RedHat Linux 6.0, kernel version 2.4.2-2smp, libc-2.2.2. What seem to be the problem? Thanks in advance. Konstantin. |
|
From: Dallman, J. <jg...@ug...> - 2005-07-19 14:42:05
|
Dennis Lubert writes: > ... I think most applications and developers don't use 64Bit=20 > because of the big address space.=20 Well, actually, that is the whole point of 64-bit - the address=20 space. However, since all our routine test cases have to be able=20 to run on 32-bit platforms as well, a 64-bit Valgrind with=20 about as much usable memory as for a 32-bit platform would be=20 useful.=20 > and even if, most of them will be able to split up their programs=20 > into little test cases for which valgrind3 will be of great use. I think you're being just a wee bit optimistic here.=20 --=20 John Dallman, Parasolid Porting Engineer, +44-1223-371554=20 |