You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(11) |
|
2
(5) |
3
(11) |
4
(13) |
5
(1) |
6
(15) |
7
(1) |
8
(1) |
|
9
(2) |
10
(4) |
11
(15) |
12
(2) |
13
(12) |
14
(2) |
15
(3) |
|
16
(1) |
17
(16) |
18
(1) |
19
(32) |
20
(19) |
21
(3) |
22
|
|
23
|
24
(4) |
25
|
26
(1) |
27
(19) |
28
(4) |
29
(2) |
|
30
(3) |
|
|
|
|
|
|
|
From: Tom H. <th...@cy...> - 2003-11-20 10:20:00
|
In message <Pin...@gr...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Tue, 18 Nov 2003, Jeremy Fitzhardinge wrote:
>
>> OK, I've had even more of a look into what's happening here. The quick
>> answer is that is can probably be done without too much nastiness,
>> though our libpthread will need to know some of glibc's secret
>> knowledge.
>
> We've mentioned before the idea of dropping Valgrind's libpthread.so, and
> just doing some low-level clone() interception... would that get around
> any/all this NPTL/TLS nastiness?
It should do, yes. We would just need to track the calls being made
to set_pthread_area and clone with the TLS option.
I'm working on trying to get things going with those functions Jeremy
found anyway...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-20 09:44:53
|
CVS commit by nethercote: Link to the Valgrind RV'03 paper. M +3 -2 docs.html 1.4 --- devel-home/valgrind/docs.html #1.3:1.4 @@ -14,6 +14,7 @@ The overly-curious may want to read <a href="http://developer.kde.org/~sewardj/docs-2.0.0/mc_techdocs.html"> -detailed tech docs</a> about how -Valgrind is implemented. +detailed tech docs</a> about how Valgrind is implemented. Alternatively, you +may want to read this broader, more formal +<a href="http://www.cl.cam.ac.uk/~njn25/pubs/valgrind2003.ps.gz">overview</a>. <?php |
|
From: Nicholas N. <nj...@ca...> - 2003-11-20 09:40:55
|
On Tue, 18 Nov 2003, Jeremy Fitzhardinge wrote: > OK, I've had even more of a look into what's happening here. The quick > answer is that is can probably be done without too much nastiness, > though our libpthread will need to know some of glibc's secret > knowledge. We've mentioned before the idea of dropping Valgrind's libpthread.so, and just doing some low-level clone() interception... would that get around any/all this NPTL/TLS nastiness? That option does have some other downsides, though, particularly it makes it harder to tell tools when interesting pthread events (eg. mutex_lock) occur. N |
|
From: Nicholas N. <nj...@ca...> - 2003-11-20 09:35:33
|
CVS commit by nethercote:
We have Hungarian users
M +5 -4 overview.html 1.3
--- devel-home/valgrind/overview.html #1.2:1.3
@@ -70,8 +70,9 @@
<li><b>Valgrind is widely used.</b> Valgrind has been used by thousands
of programmers across the world. We have received feedback from
- users in over 20 countries, including: Belgium, Czech Republic,
- Denmark, Finland, France, Germany, Greece, Italy, The Netherlands,
- Norway, Poland, Russia, Sweden, Switzerland, UK, Argentina, Brazil,
- Canada, USA, Australia, Japan, New Zealand, South Africa and Israel.
+ users in over 25 countries, including: Belgium, Czech Republic,
+ Denmark, Finland, France, Germany, Greece, Hungary, Italy, The
+ Netherlands, Norway, Poland, Russia, Sweden, Switzerland, UK,
+ Argentina, Brazil, Canada, USA, Australia, Japan, New Zealand, South
+ Africa and Israel.
<p>
<li><b>Valgrind works with programs written in any language.</b>
|
|
From: Dirk M. <dm...@gm...> - 2003-11-19 23:18:33
|
On Wednesday 19 November 2003 23:29, Nicholas Nethercote wrote: > Are there instructions somewhere? How's it all work? There is the web interface, which has mostly a self-containing documentation hidden behind all the knobs on the bug forms, see http://bugs.kde.org/queryhelp.cgi There is also a mail interface which is mostly undocumented and a xml query interface (used by offline tools like kbugbuster). Anyway, if there is a more specific question, just ask. Dirk |
|
From: Nicholas N. <nj...@ca...> - 2003-11-19 22:30:32
|
Hi, It seems people are starting to use Bugzilla to report bugs. This is good. I have no idea how to use Bugzilla. This is bad. Are there instructions somewhere? How's it all work? Thanks. N |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 22:08:06
|
CVS commit by mueller:
this should fix compilation on weird kernel 2.6.x installations.
CCMAIL: 68...@bu...
M +4 -4 coregrind/vg_syscalls.c 1.59
M +0 -1 coregrind/vg_unsafe.h 1.22
M +13 -0 include/vg_kerneliface.h 1.8
--- valgrind/coregrind/vg_syscalls.c #1.58:1.59
@@ -2488,5 +2488,5 @@ PRE(ioctl)
# endif
- case IIOCGETCPS:
+ case VKI_IIOCGETCPS:
/* In early 2.4 kernels, ISDN_MAX_CHANNELS was only defined
* when KERNEL was. I never saw a larger value than 64 though */
@@ -2498,5 +2498,5 @@ PRE(ioctl)
* 2 * sizeof(unsigned long) );
break;
- case IIOCNETGPN:
+ case VKI_IIOCNETGPN:
SYSCALL_TRACK( pre_mem_read, tid, "ioctl(IIOCNETGPN)",
(UInt)&((isdn_net_ioctl_phone *)arg3)->name,
@@ -2887,5 +2887,5 @@ POST(ioctl)
# endif
- case IIOCGETCPS:
+ case VKI_IIOCGETCPS:
/* In early 2.4 kernels, ISDN_MAX_CHANNELS was only defined
* when KERNEL was. I never saw a larger value than 64 though */
@@ -2897,5 +2897,5 @@ POST(ioctl)
* 2 * sizeof(unsigned long) );
break;
- case IIOCNETGPN:
+ case VKI_IIOCNETGPN:
if (res == 0)
VG_TRACK( post_mem_write, arg3, sizeof(isdn_net_ioctl_phone) );
--- valgrind/coregrind/vg_unsafe.h #1.21:1.22
@@ -58,5 +58,4 @@
#include <linux/sem.h> /* for struct sembuf */
-#include <linux/isdn.h> /* for ISDN ioctls */
#include <scsi/sg.h> /* for the SG_* ioctls */
#include <sched.h> /* for struct sched_param */
--- valgrind/include/vg_kerneliface.h #1.7:1.8
@@ -372,4 +372,17 @@ struct vki_ucontext {
#define VKI_ERESTARTSYS 512 /* Restart the syscall */
+/* Copied from linux/isdn.h */
+
+#define VKI_IIOCGETCPS _IO( 'I',21 )
+#define VKI_IIOCNETGPN _IO( 'I',34 )
+
+#define ISDN_MSNLEN 32
+
+typedef struct {
+ char name[ 10 ];
+ char phone[ ISDN_MSNLEN ];
+ int outgoing;
+} isdn_net_ioctl_phone;
+
/* Gawd ... hack ... */
|
|
From: Dirk M. <mu...@kd...> - 2003-11-19 22:07:17
|
CVS commit by mueller:
make it compile on non-C90 compilers. Thanks for the patch.
CCMAIL: 685...@bu...
M +5 -3 vg_symtab2.c 1.59
--- valgrind/coregrind/vg_symtab2.c #1.58:1.59
@@ -673,4 +673,6 @@ void read_symtab( SegInfo* si, Char* tab
Addr sym_addr;
RiSym risym;
+ Char* t0;
+ Char* name;
if (o_strtab == NULL || o_symtab == NULL) {
@@ -785,8 +787,8 @@ void read_symtab( SegInfo* si, Char* tab
/* If we reach here, it's an interesting symbol; record it. */
- Char* t0 = sym->st_name
+ t0 = sym->st_name
? (Char*)(o_strtab+sym->st_name)
: (Char*)"NONAME";
- Char *name = VG_(addStr) ( si, t0, -1 );
+ name = VG_(addStr) ( si, t0, -1 );
vg_assert(name != NULL
/* && 0==VG_(strcmp)(t0,&vg_strtab[nmoff]) */ );
|
|
From: Dirk M. <mu...@kd...> - 2003-11-19 22:02:38
|
CVS commit by mueller:
SHUFPD support
MERGE TO STABLE
CCMAIL: 685...@bu...
M +7 -0 vg_to_ucode.c 1.109
--- valgrind/coregrind/vg_to_ucode.c #1.108:1.109
@@ -3927,4 +3927,11 @@ static Addr disInstr ( UCodeBlock* cb, A
}
+ /* SHUFPD */
+ if (sz == 2 && insn[0] == 0x0F && insn[1] == 0xC6) {
+ eip = dis_SSE3_reg_or_mem_Imm8 ( cb, sorb, eip+2, 16, "shufpd",
+ 0x66, insn[0], insn[1] );
+ goto decode_success;
+ }
+
/* SHUFPS */
if (insn[0] == 0x0F && insn[1] == 0xC6) {
|
|
From: Dirk M. <mu...@kd...> - 2003-11-19 21:50:37
|
CVS commit by mueller:
pkgconfig support. Patch by Dimitri Papadopoulos
MERGE TO STABLE
CCMAIL: 685...@bu...
A valgrind.pc.in 1.1
M +1 -0 .cvsignore 1.5
M +5 -2 Makefile.am 1.58
M +1 -0 configure.in 1.100
--- valgrind/.cvsignore #1.4:1.5
@@ -18,2 +18,3 @@
cachegrind.out.*
autom4te.cache
+valgrind.pc
--- valgrind/Makefile.am #1.57:1.58
@@ -26,5 +26,8 @@
val_DATA = $(SUPP_FILES) default.supp
-BUILT_SOURCES = default.supp
+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = valgrind.pc
+
+BUILT_SOURCES = default.supp valgrind.pc
DISTCLEANFILES = default.supp
@@ -41,5 +44,5 @@
README_KDE3_FOLKS README_PACKAGERS \
README_MISSING_SYSCALL_OR_IOCTL TODO \
- valgrind.spec valgrind.spec.in
+ valgrind.spec valgrind.spec.in valgrind.pc.in
install-exec-hook:
--- valgrind/configure.in #1.99:1.100
@@ -341,4 +341,5 @@
Makefile
valgrind.spec
+ valgrind.pc
docs/Makefile
tests/Makefile
|
|
From: Dirk M. <mu...@kd...> - 2003-11-19 21:33:37
|
CVS commit by mueller: CVS_SILENT ignore M +3 -0 .cvsignore 1.6.2.1 --- valgrind/memcheck/tests/.cvsignore #1.6:1.6.2.1 @@ -49,2 +49,5 @@ *.stdout.out *.stderr.out +metadata +realloc3 +threadederrno |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 21:31:50
|
CVS commit by mueller:
backport compile fix. sorry for the breakage in the stable branch.
M +2 -0 coregrind/vg_syscalls.c 1.40.2.9
M +0 -3 coregrind/vg_unsafe.h 1.14.2.5
M +34 -1 include/vg_kerneliface.h 1.1.2.1
--- valgrind/coregrind/vg_syscalls.c #1.40.2.8:1.40.2.9
@@ -3262,4 +3262,6 @@ void VG_(perform_assumed_nonblocking_sys
MAYBE_PRINTF("statfs64 ( %s, %p )\n", arg1,arg2);
SYSCALL_TRACK( pre_mem_read_asciiz, tid, "statfs64(path)", arg1 );
+ SYSCALL_TRACK( pre_mem_write, tid, "statfs64(buf)",
+ arg2, sizeof(struct statfs64));
KERNEL_DO_SYSCALL(tid,res);
if (!VG_(is_kerror)(res) && res == 0)
--- valgrind/coregrind/vg_unsafe.h #1.14.2.4:1.14.2.5
@@ -84,7 +84,4 @@
#include <sys/types.h>
-#include <asm/statfs.h>
-#undef statfs
-
#include <sys/sysinfo.h>
--- valgrind/include/vg_kerneliface.h #1.1:1.1.2.1
@@ -412,6 +412,39 @@ typedef struct vki_modify_ldt_ldt_s {
+/* statfs structs */
+/*
+ * bits/statfs.h
+ */
-#endif /* ndef __VG_KERNELIFACE_H */
+struct statfs {
+ unsigned int f_type;
+ unsigned int f_bsize;
+ unsigned int f_blocks;
+ unsigned int f_bfree;
+ unsigned int f_bavail;
+ unsigned int f_files;
+ unsigned int f_ffree;
+ int f_fsid[ 2 ];
+ unsigned int f_namelen;
+ unsigned int f_frsize;
+ unsigned int f_spare[5];
+};
+
+struct statfs64 {
+ unsigned int f_type;
+ unsigned int f_bsize;
+ unsigned long long f_blocks;
+ unsigned long long f_bfree;
+ unsigned long long f_bavail;
+ unsigned long long f_files;
+ unsigned long long f_ffree;
+ int f_fsid[ 2 ];
+ unsigned int f_namelen;
+ unsigned int f_frsize;
+ unsigned int f_spare[5];
+};
+
+
+#endif /* __VG_KERNELIFACE_H */
/*--------------------------------------------------------------------*/
|
|
From: Dirk M. <dm...@gm...> - 2003-11-19 20:20:10
|
On Wednesday 19 November 2003 21:07, Nicholas Nethercote wrote: > Much better, I find --assume-2.4 confusing. Or, to be consistent with > --workaround-gcc296-bugs, --workaround-suse81-bugs (or whatever the > version is)? I agree, but can we first investigate if this is really a bug in the SuSE kernel? If I'd have a test app I could pass it to the kernel developers or verify it against the spec. I might try building one myself, just in case somebody has already done this work.. |
|
From: Nicholas N. <nj...@ca...> - 2003-11-19 20:11:41
|
CVS commit by nethercote: Fix regtest for change of error message. M +0 -1 dlclose.stderr.exp 1.5 --- valgrind/cachegrind/tests/dlclose.stderr.exp #1.4:1.5 @@ -1,4 +1,3 @@ -discard syms in /.../tests/myprint.so due to munmap() I refs: |
|
From: Nicholas N. <nj...@ca...> - 2003-11-19 20:10:41
|
On Wed, 19 Nov 2003, Dirk Mueller wrote: > trying to fix compilation. Does it work now for everybody? yep, thanks. I just fixed cachegrind/tests/dlclose, which had broken due to the "discard" message no longer being shown. N |
|
From: Nicholas N. <nj...@ca...> - 2003-11-19 20:07:06
|
On Wed, 19 Nov 2003, Jeremy Fitzhardinge wrote: > Perhaps I should rename the option to --broken-suse-kernel=yes. Much better, I find --assume-2.4 confusing. Or, to be consistent with --workaround-gcc296-bugs, --workaround-suse81-bugs (or whatever the version is)? N |
|
From: Jeremy F. <je...@go...> - 2003-11-19 18:44:45
|
On Wed, 2003-11-19 at 09:47, Dirk Mueller wrote: > On Wednesday 19 November 2003 18:44, Jeremy Fitzhardinge wrote: > > > The intent is that the valgrind wrapper script use --assume-2.4=yes when > > it detects a SuSE kernel - I hadn't got around to it. Perhaps I should > > rename the option to --broken-suse-kernel=yes. > > Maybe you can elaborate in more detail what is broken? V does a feature test to see if its running on a 2.6-like kernel, which is what it would prefer. SuSE passes those feature tests because they've extended their 2.4 kernel to include the new NPTL syscalls (like RH). Unfortunately they seem subtly broken, and even though the syscalls works and take the new args, they behave differently. The message you posted suggests that at least one proxy LWP just evaporated without notifying anyone of its death. On standard 2.4 kernels and RH 2.4 kernels it works OK without --assume-2.4=yes - it really is just for SuSE kernels (and perhaps other vendors with hacked up 2.4 kernels). J |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 17:47:44
|
On Wednesday 19 November 2003 18:44, Jeremy Fitzhardinge wrote: > The intent is that the valgrind wrapper script use --assume-2.4=yes when > it detects a SuSE kernel - I hadn't got around to it. Perhaps I should > rename the option to --broken-suse-kernel=yes. Maybe you can elaborate in more detail what is broken? |
|
From: Jeremy F. <je...@go...> - 2003-11-19 17:44:47
|
On Wed, 2003-11-19 at 09:11, Dirk Mueller wrote: > It works when I use --assume-2.4=yes, but I don't consider this switch to be a > good idea. can't we detect whatever weird kernel feature we now need at > runtime? The intent is that the valgrind wrapper script use --assume-2.4=yes when it detects a SuSE kernel - I hadn't got around to it. Perhaps I should rename the option to --broken-suse-kernel=yes. J |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 17:11:39
|
On Wednesday 19 November 2003 16:18, Nicholas Nethercote wrote: > What's the problem with HEAD -- it doesn't work on your machine at all? > Have you told Jeremy? (well, I guess he knows now...) This happens: ==25531== Memcheck, a memory error detector for x86-linux. ==25531== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==25531== Using valgrind-HEAD, a program supervision framework for x86-linux. ==25531== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==25531== Estimated CPU clock rate is 1540 MHz ==25531== For more details, rerun with: -v ==25531== ==25531== ==25531== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==25531== malloc/free: in use at exit: 0 bytes in 0 blocks. ==25531== malloc/free: 103 allocs, 103 frees, 7925 bytes allocated. ==25531== For a detailed leak analysis, rerun with: --leak-check=yes ==25531== For counts of detected errors, rerun with: -v --25531-- TID 1: proxy LWP 0 exited with status 0 valgrind: vg_proxylwp.c:1360 (vgPlain_proxy_sanity): Assertion `sane' failed. ==25531== at 0x4017A01E: vgPlain_skin_assert_fail (vg_mylibc.c:1102) ==25531== by 0x4017A01D: assert_fail (vg_mylibc.c:1098) ==25531== by 0x4017A0A8: vgPlain_core_assert_fail (vg_mylibc.c:1109) ==25531== by 0x4017E89B: vgPlain_proxy_sanity (vg_proxylwp.c:1360) ==25531== by 0x40175060: vgPlain_do_sanity_checks (vg_main.c:2051) ==25531== by 0x4017484A: vgPlain_main (vg_main.c:1699) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==25531== at 0x40171A33: vgPlain___libc_freeres_wrapper (vg_intercept.c:177) ==25531== by 0x40271057: __GI_exit (in /lib/i686/libc.so.6) ==25531== by 0x8048A9D: (within /bin/true) ==25531== by 0x4025AD16: __libc_start_main (in /lib/i686/libc.so.6) ==25531== by 0x80488C0: (within /bin/true) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: js...@ac... In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. It works when I use --assume-2.4=yes, but I don't consider this switch to be a good idea. can't we detect whatever weird kernel feature we now need at runtime? |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 17:01:28
|
CVS commit by mueller:
add CVTPD2PS support, based on patch by Josef Weidendorfer
MERGE TO STABLE
M +8 -0 vg_to_ucode.c 1.108
--- valgrind/coregrind/vg_to_ucode.c #1.107:1.108
@@ -4761,4 +4761,12 @@ static Addr disInstr ( UCodeBlock* cb, A
}
+ /* CVTPD2PS -- convert two doubles to two floats. */
+ if (sz == 2 &&
+ insn[0] == 0x0F && insn[1] == 0x5A) {
+ eip = dis_SSE3_reg_or_mem ( cb, sorb, eip+2, 16, "cvtpd2ps",
+ 0x66, insn[0], insn[1] );
+ goto decode_success;
+ }
+
/* SQRTPD: square root of packed double. */
if (sz == 2
|
|
From: Dirk M. <dm...@gm...> - 2003-11-19 17:00:41
|
Hi, Hmm, any idea how to tackle this problem? |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 16:55:29
|
CVS commit by mueller:
trying to fix compilation. Does it work now for everybody?
M +0 -3 coregrind/vg_unsafe.h 1.21
M +34 -1 include/vg_kerneliface.h 1.7
--- valgrind/coregrind/vg_unsafe.h #1.20:1.21
@@ -91,7 +91,4 @@
#include <sys/types.h>
-#include <asm/statfs.h>
-#undef statfs
-
#include <sys/sysinfo.h>
--- valgrind/include/vg_kerneliface.h #1.6:1.7
@@ -672,6 +672,39 @@ struct vki_sockaddr {
};
+/* statfs structs */
+/*
+ * bits/statfs.h
+ */
-#endif /* ndef __VG_KERNELIFACE_H */
+struct statfs {
+ unsigned int f_type;
+ unsigned int f_bsize;
+ unsigned int f_blocks;
+ unsigned int f_bfree;
+ unsigned int f_bavail;
+ unsigned int f_files;
+ unsigned int f_ffree;
+ int f_fsid[ 2 ];
+ unsigned int f_namelen;
+ unsigned int f_frsize;
+ unsigned int f_spare[5];
+};
+
+struct statfs64 {
+ unsigned int f_type;
+ unsigned int f_bsize;
+ unsigned long long f_blocks;
+ unsigned long long f_bfree;
+ unsigned long long f_bavail;
+ unsigned long long f_files;
+ unsigned long long f_ffree;
+ int f_fsid[ 2 ];
+ unsigned int f_namelen;
+ unsigned int f_frsize;
+ unsigned int f_spare[5];
+};
+
+
+#endif /* __VG_KERNELIFACE_H */
/*--------------------------------------------------------------------*/
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-19 15:18:10
|
On Wed, 19 Nov 2003, Dirk Mueller wrote: > Ok, same question to you: where is statfs64 defined for you? for me its in > asm/statfs.h bits/statfs.h > Its a bit tricky to use this here since normally you're supposed to do this > via the D_FILE_OFFSET_BITS define, which we can't do since we want the old > 32bit version and the 64bit version. > > somehow we need a script that calculates the magic values of sizeof() etc and > then just import that header file with the list of #define's . Including > nonstandard kernel headers is just too unportable, even for valgrind. > > > > Also, not printing the "discarding..." message will, I think, break some > > regression tests. These problems may also apply to the stable branch. > > Well, make regtest prints 0 failures for me. do you see some? where? Sorry, my mistake. > Of course I did that. 0 failures in branch, all failed in HEAD, but thats > because HEAD does not even work on /bin/true for me. Sorry for the mis-accusation. What's the problem with HEAD -- it doesn't work on your machine at all? Have you told Jeremy? (well, I guess he knows now...) N |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 10:34:12
|
On Wednesday 19 November 2003 10:59, Nicholas Nethercote wrote: > > implement statfs64, utimes and clock_gettime > vg_syscalls.c: In function `before_statfs64': > vg_syscalls.c:4070: sizeof applied to an incomplete type Ok, same question to you: where is statfs64 defined for you? for me its in asm/statfs.h Its a bit tricky to use this here since normally you're supposed to do this via the D_FILE_OFFSET_BITS define, which we can't do since we want the old 32bit version and the 64bit version. somehow we need a script that calculates the magic values of sizeof() etc and then just import that header file with the list of #define's . Including nonstandard kernel headers is just too unportable, even for valgrind. > > Also, not printing the "discarding..." message will, I think, break some > regression tests. These problems may also apply to the stable branch. Well, make regtest prints 0 failures for me. do you see some? where? > Can you fix them? Thanks. And don't forget to run the regression tests > before committing :) Of course I did that. 0 failures in branch, all failed in HEAD, but thats because HEAD does not even work on /bin/true for me. |