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
(15) |
|
2
(24) |
3
(16) |
4
(17) |
5
(11) |
6
(20) |
7
(11) |
8
(15) |
|
9
(10) |
10
(9) |
11
(10) |
12
(24) |
13
(16) |
14
(15) |
15
(8) |
|
16
(13) |
17
(15) |
18
(35) |
19
(11) |
20
(10) |
21
(11) |
22
(9) |
|
23
(10) |
24
(9) |
25
(9) |
26
(9) |
27
(9) |
28
(12) |
29
(16) |
|
30
(12) |
|
|
|
|
|
|
|
From: Tom H. <to...@co...> - 2006-04-29 19:14:24
|
In message <2f7...@ma...>
"David Kimdon" <dw...@de...> wrote:
> The attached patch changes the expected output of none/tests/x86/int
> to match what valgrind emits on my system (currnet Debian unstable).
> Based on my reading of the revision history of this test, initially
> added here:
>
> http://websvn.kde.org/trunk/valgrind/none/tests/x86/int.c?rev=356199&view=log
>
> and the bug that caused this test to be added to the testsuite in the
> first place:
>
> http://bugs.kde.org/show_bug.cgi?id=76839
>
> all we want valgrind to do is to emit a clear message indicating that
> the program has tried to execute an illegal instruction. It looks to
> me like valgrinds behavior in this case is now correct.
Actually ideally we want valgrind to raise the same signal to the
programs that it would normally get without valgrind, and I believe
that is what the test currently expects.
The fact that valgrind currently behaves different to the OS here
is arguably a bug.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <sv...@va...> - 2006-04-29 18:03:20
|
Author: sewardj
Date: 2006-04-29 19:03:14 +0100 (Sat, 29 Apr 2006)
New Revision: 5868
Log:
Get rid of VG_(x86_linux_REDIR_FOR__dl_sysinfo_int80) and do the x86-linu=
x
stack unwind kludge another way. This is believed to fix #108258.
Modified:
trunk/coregrind/m_clientstate.c
trunk/coregrind/m_redir.c
trunk/coregrind/m_signals.c
trunk/coregrind/m_stacktrace.c
trunk/coregrind/m_trampoline.S
trunk/coregrind/pub_core_clientstate.h
trunk/coregrind/pub_core_trampoline.h
Modified: trunk/coregrind/m_clientstate.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_clientstate.c 2006-04-29 18:01:46 UTC (rev 5867)
+++ trunk/coregrind/m_clientstate.c 2006-04-29 18:03:14 UTC (rev 5868)
@@ -91,7 +91,13 @@
/* Where is the __libc_freeres_wrapper routine we made? */
Addr VG_(client___libc_freeres_wrapper) =3D 0;
=20
+/* x86-linux only: where is glibc's _dl_sysinfo_int80 function?
+ Finding it isn't essential, but knowing where it is does sometimes
+ help produce better back traces. See big comment in
+ VG_(get_StackTrace) in m_stacktrace.c for further info. */
+Addr VG_(client__dl_sysinfo_int80) =3D 0;
=20
+
/*--------------------------------------------------------------------*/
/*--- end ---*/
/*--------------------------------------------------------------------*/
Modified: trunk/coregrind/m_redir.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_redir.c 2006-04-29 18:01:46 UTC (rev 5867)
+++ trunk/coregrind/m_redir.c 2006-04-29 18:03:14 UTC (rev 5868)
@@ -273,7 +273,8 @@
static void show_redir_state ( HChar* who );
static void show_active ( HChar* left, Active* act );
=20
-static void handle_maybe_load_notifier( HChar* symbol, Addr addr );
+static void handle_maybe_load_notifier( const UChar* soname,=20
+ HChar* symbol, Addr addr=
);
=20
=20
/*------------------------------------------------------------*/
@@ -310,8 +311,11 @@
HChar demangled_sopatt[N_DEMANGLED];
HChar demangled_fnpatt[N_DEMANGLED];
=20
+ const UChar* newsi_soname;
+
vg_assert(newsi);
- vg_assert(VG_(seginfo_soname)(newsi) !=3D NULL);
+ newsi_soname =3D VG_(seginfo_soname)(newsi);
+ vg_assert(newsi_soname !=3D NULL);
=20
/* stay sane: we don't already have this. */
for (ts =3D topSpecs; ts; ts =3D ts->next)
@@ -330,7 +334,7 @@
if (!ok) {
/* It's not a full-scale redirect, but perhaps it is a load-not=
ify
fn? Let the load-notify department see it. */
- handle_maybe_load_notifier( sym_name, sym_addr );
+ handle_maybe_load_notifier( newsi_soname, sym_name, sym_addr );
continue;=20
}
spec =3D symtab_alloc(sizeof(Spec));
@@ -726,13 +730,6 @@
// The rest of this function just adds initial Specs. =20
=20
# if defined(VGP_x86_linux)
- /* Redirect _dl_sysinfo_int80, which is glibc's default system call
- routine, to our copy so that the special sysinfo unwind hack in
- m_stacktrace.c will kick in. */
- add_hardwired_spec(
- "ld-linux.so.2", "_dl_sysinfo_int80",
- (Addr)&VG_(x86_linux_REDIR_FOR__dl_sysinfo_int80)=20
- );
/* If we're using memcheck, use this intercept right from the
start, otherwise ld.so (glibc-2.3.5) makes a lot of noise. */
if (0=3D=3DVG_(strcmp)("Memcheck", VG_(details).name)) {
@@ -827,8 +824,25 @@
/*--- NOTIFY-ON-LOAD FUNCTIONS ---*/
/*------------------------------------------------------------*/
=20
-static void handle_maybe_load_notifier( HChar* symbol, Addr addr )
+static=20
+void handle_maybe_load_notifier( const UChar* soname,=20
+ HChar* symbol, Addr addr )
{
+# if defined(VGP_x86_linux)
+ /* x86-linux only: if we see _dl_sysinfo_int80, note its address.
+ See comment on declaration of VG_(client__dl_sysinfo_int80) for
+ the reason. As far as I can tell, the relevant symbol is always
+ in object with soname "ld-linux.so.2". */
+ if (symbol && symbol[0] =3D=3D '_'=20
+ && 0 =3D=3D VG_(strcmp)(symbol, "_dl_sysinfo_int80")
+ && 0 =3D=3D VG_(strcmp)(soname, "ld-linux.so.2")) {
+ if (VG_(client__dl_sysinfo_int80) =3D=3D 0)
+ VG_(client__dl_sysinfo_int80) =3D addr;
+ }
+# endif
+
+ /* Normal load-notifier handling after here. First, ignore all
+ symbols lacking the right prefix. */
if (0 !=3D VG_(strncmp)(symbol, VG_NOTIFY_ON_LOAD_PREFIX,=20
VG_NOTIFY_ON_LOAD_PREFIX_LEN))
/* Doesn't have the right prefix */
@@ -836,9 +850,6 @@
=20
if (VG_(strcmp)(symbol, VG_STRINGIFY(VG_NOTIFY_ON_LOAD(freeres))) =3D=
=3D 0)
VG_(client___libc_freeres_wrapper) =3D addr;
-// else
-// if (VG_(strcmp)(symbol, STR(VG_WRAPPER(pthread_startfunc_wrapper))) =3D=
=3D 0)
-// VG_(pthread_startfunc_wrapper)((Addr)(si->offset + sym->st_value))=
;
else
vg_assert2(0, "unrecognised load notification function: %s", symbo=
l);
}
Modified: trunk/coregrind/m_signals.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_signals.c 2006-04-29 18:01:46 UTC (rev 5867)
+++ trunk/coregrind/m_signals.c 2006-04-29 18:03:14 UTC (rev 5868)
@@ -905,9 +905,11 @@
vg_assert(VG_(is_valid_tid)(tid));
tst =3D & VG_(threads)[tid];
=20
- if (VG_(clo_trace_signals))
+ if (VG_(clo_trace_signals)) {
VG_(message)(Vg_DebugMsg,=20
"push_signal_frame (thread %d): signal %d", tid, sigNo);
+ VG_(get_and_pp_StackTrace)(tid, 10);
+ }
=20
if (/* this signal asked to run on an alt stack */
(scss.scss_per_sig[sigNo].scss_flags & VKI_SA_ONSTACK )
Modified: trunk/coregrind/m_stacktrace.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_stacktrace.c 2006-04-29 18:01:46 UTC (rev 5867)
+++ trunk/coregrind/m_stacktrace.c 2006-04-29 18:03:14 UTC (rev 5868)
@@ -38,6 +38,7 @@
#include "pub_core_machine.h"
#include "pub_core_options.h"
#include "pub_core_stacktrace.h"
+#include "pub_core_clientstate.h" // VG_(client__dl_sysinfo_int80)
#include "pub_core_trampoline.h"
=20
/*------------------------------------------------------------*/
@@ -344,16 +345,26 @@
Addr stack_highest_word =3D VG_(threads)[tid].client_stack_highest_wo=
rd;
=20
# if defined(VGP_x86_linux)
- /* Nasty little hack to deal with sysinfo syscalls - if libc is
- using the sysinfo page for syscalls (the TLS version does), then
- ip will always appear to be in that page when doing a syscall,
- not the actual libc function doing the syscall. This check sees
- if IP is within the syscall code, and pops the return address
- off the stack so that ip is placed within the library function
- calling the syscall. This makes stack backtraces much more
- useful. */
- if (ip >=3D (Addr)&VG_(trampoline_stuff_start)=20
- && ip < (Addr)&VG_(trampoline_stuff_end)
+ /* Nasty little hack to deal with syscalls - if libc is using its
+ _dl_sysinfo_int80 function for syscalls (the TLS version does),
+ then ip will always appear to be in that function when doing a
+ syscall, not the actual libc function doing the syscall. This
+ check sees if IP is within that function, and pops the return
+ address off the stack so that ip is placed within the library
+ function calling the syscall. This makes stack backtraces much
+ more useful.
+
+ The function is assumed to look like this (from glibc-2.3.6 source=
s):
+ _dl_sysinfo_int80:
+ int $0x80
+ ret
+ That is 3 (2+1) bytes long. We could be more thorough and check
+ the 3 bytes of the function are as expected, but I can't be
+ bothered.
+ */
+ if (VG_(client__dl_sysinfo_int80) !=3D 0 /* we know its address */
+ && ip >=3D VG_(client__dl_sysinfo_int80)
+ && ip < VG_(client__dl_sysinfo_int80)+3
&& VG_(am_is_valid_for_client)(sp, sizeof(Addr), VKI_PROT_READ)) =
{
ip =3D *(Addr *)sp;
sp +=3D sizeof(Addr);
Modified: trunk/coregrind/m_trampoline.S
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_trampoline.S 2006-04-29 18:01:46 UTC (rev 5867)
+++ trunk/coregrind/m_trampoline.S 2006-04-29 18:03:14 UTC (rev 5868)
@@ -55,7 +55,9 @@
.global VG_(x86_linux_SUBST_FOR_sigreturn)
VG_(x86_linux_SUBST_FOR_sigreturn):
/* This is a very specific sequence which GDB uses to
- recognize signal handler frames. */
+ recognize signal handler frames. Also gcc: see
+ x86_fallback_frame_state() in
+ gcc-4.1.0/gcc/config/i386/linux-unwind.h */
popl %eax
movl $__NR_sigreturn, %eax
int $0x80
@@ -68,12 +70,6 @@
int $0x80
ud2
=20
-.global VG_(x86_linux_REDIR_FOR__dl_sysinfo_int80)
-VG_(x86_linux_REDIR_FOR__dl_sysinfo_int80):
- /* We can point our sysinfo stuff here */
- int $0x80
- ret
-
/* There's no particular reason that this needs to be handwritten
assembly, but since that's what this file contains, here's a
simple index implementation (written in C and compiled by gcc.)
Modified: trunk/coregrind/pub_core_clientstate.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/pub_core_clientstate.h 2006-04-29 18:01:46 UTC (rev 5=
867)
+++ trunk/coregrind/pub_core_clientstate.h 2006-04-29 18:03:14 UTC (rev 5=
868)
@@ -82,6 +82,13 @@
/* Where is the __libc_freeres_wrapper routine we made? */
extern Addr VG_(client___libc_freeres_wrapper);
=20
+/* x86-linux only: where is ld.so's _dl_sysinfo_int80 function?
+ Finding it isn't essential, but knowing where it is does sometimes
+ help produce better back traces. See big comment in
+ VG_(get_StackTrace) in m_stacktrace.c for further info. */
+extern Addr VG_(client__dl_sysinfo_int80);
+
+
#endif // __PUB_CORE_CLIENTSTATE_H
=20
/*--------------------------------------------------------------------*/
Modified: trunk/coregrind/pub_core_trampoline.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/pub_core_trampoline.h 2006-04-29 18:01:46 UTC (rev 58=
67)
+++ trunk/coregrind/pub_core_trampoline.h 2006-04-29 18:03:14 UTC (rev 58=
68)
@@ -37,6 +37,15 @@
// stubs for signal returns. Note, all the code within runs on the
// simulated CPU. The vsyscall stubs are gotten to by use of the=20
// redirect mechanism.
+//
+// Note: generally, putting replacement functions in here is a bad
+// idea, since any Dwarf frame-unwind info attached to them will not
+// be seen by the unwinder in gcc's runtime support. This means
+// unwinding during exception handling by gcc tends to fail if it
+// encounters one of these replacement functions. A better place to
+// put them is in one of the .so's preloaded into the client, since
+// the client's ld.so will know about it and so gcc's unwinder
+// (somehow) is able to get hold of it.
//--------------------------------------------------------------------
=20
/* These two delimit our handwritten assembly code, so we can tell
@@ -50,7 +59,6 @@
#if defined(VGP_x86_linux)
extern void VG_(x86_linux_SUBST_FOR_sigreturn);
extern void VG_(x86_linux_SUBST_FOR_rt_sigreturn);
-extern void VG_(x86_linux_REDIR_FOR__dl_sysinfo_int80);
extern Char* VG_(x86_linux_REDIR_FOR_index) ( const Char*, Int );
#endif
=20
|
|
From: <sv...@va...> - 2006-04-29 18:01:57
|
Author: sewardj
Date: 2006-04-29 19:01:46 +0100 (Sat, 29 Apr 2006)
New Revision: 5867
Log:
Update
Modified:
trunk/docs/internals/3_1_BUGSTATUS.txt
Modified: trunk/docs/internals/3_1_BUGSTATUS.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/docs/internals/3_1_BUGSTATUS.txt 2006-04-29 12:50:06 UTC (rev 5=
866)
+++ trunk/docs/internals/3_1_BUGSTATUS.txt 2006-04-29 18:01:46 UTC (rev 5=
867)
@@ -37,8 +37,11 @@
? 108528 NPTL pthread cleanup handlers not called=20
high 125607 amd64->IR: 0x66 0xF 0xA3 0x2 (btw etc)
high 125651 amd64->IR: 0xF8 0x49 0xFF 0xE3 (clc?)
+ high n-i-bz amd64->IR: 0xF 0xE 0xC3 0x90 (v-users, 16 Apr=
)
+? load V at 0x3000'0000 ?
+AshleyP's XML merger / XML changes ?
+memcheck/tests/stack_switch segfaulted on 2.4.24-cm32lnxi6plsd2pcsmp (x8=
6)
=20
-
------- Bugs reported prior to 3.1.1 ------
=20
TRUNK 31BRANCH BUG# WHAT
|
|
From: David K. <dw...@de...> - 2006-04-29 16:48:47
|
Hi, The attached patch changes the expected output of none/tests/x86/int to match what valgrind emits on my system (currnet Debian unstable).=20 Based on my reading of the revision history of this test, initially added here: http://websvn.kde.org/trunk/valgrind/none/tests/x86/int.c?rev=3D356199&view= =3Dlog and the bug that caused this test to be added to the testsuite in the first place: http://bugs.kde.org/show_bug.cgi?id=3D76839 all we want valgrind to do is to emit a clear message indicating that the program has tried to execute an illegal instruction. It looks to me like valgrinds behavior in this case is now correct. -David |
|
From: <js...@ac...> - 2006-04-29 14:19:32
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-04-29 02:00:02 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 204 tests, 12 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/stack_changes (stdout) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: <sv...@va...> - 2006-04-29 12:50:23
|
Author: sewardj Date: 2006-04-29 13:50:06 +0100 (Sat, 29 Apr 2006) New Revision: 5866 Log: Un-break 'make dist'. Modified: trunk/docs/internals/Makefile.am Modified: trunk/docs/internals/Makefile.am =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/internals/Makefile.am 2006-04-28 21:01:33 UTC (rev 5865) +++ trunk/docs/internals/Makefile.am 2006-04-29 12:50:06 UTC (rev 5866) @@ -1,5 +1,5 @@ EXTRA_DIST =3D \ - 3_0_BUGSTATUS.txt 3_1_BUGSTATUS.txt 64-bit-cleanness.txt \ + 3_0_BUGSTATUS.txt 3_1_BUGSTATUS.txt \ darwin-notes.txt darwin-syscalls.txt \ directory-structure.txt \ m_replacemalloc.txt \ |
|
From: Tom H. <to...@co...> - 2006-04-29 12:38:38
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> It seems to me the cleanest solution is to get rid of
> VG_(x86_linux_REDIR_FOR__dl_sysinfo_int80) completely.
> This makes Joe's program work properly, since the gcc
> unwinder is no longer confused by our fake replacement function
> which lacks unwind info.
As far as I can see that is the only purpose for it, yes. The
redirect was originally committed by me:
------------------------------------------------------------------------
r297912 | thughes | 2004-03-22 19:46:29 +0000 (Mon, 22 Mar 2004) | 4 lines
Redirect _dl_sysinfo_int80, which is glibc's default system call
routine, to the routine in our trampoline page so that the
special sysinfo unwind hack in vg_execontext.c will kick in.
------------------------------------------------------------------------
Strangely the unwind hack in vg_execontext.c was committed a couple
of months before that by Jeremy as part of him committing my TLS support
work. I not sure how the hack was triggered before the redirect went it.
Actually, thinking about it, we may have been redirecting the sysinfo
page which would have done the trick.
> Unfortunately this breaks our own stack unwind hack, in
> m_stacktrace, on x86-linux, creating less useful traces
> for stacks which end in a syscall. (This is the only
> purpose I could find for the redirect). Fortunately it is
> easily fixed just by looking for and noting the address of the
> real _dl_sysinfo_int80, which is easily done whilst reading
> debug info, since m_redir inspects all incoming symbols.
Sounds good to me. I think we always suppress the sysinfo page
on x86 now so we will always go though _dl_sysinfo_int80() to do
a system call.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: John R.
|
>>+// Note: generally, putting replacement functions in here is a bad >>+// idea, since any Dwarf frame-unwind info attached to them will not >>+// be seen by the unwinder in gcc's runtime support. This means >>+// unwinding during exception handling by gcc tends to fail if it >>+// encounters one of these replacement functions. A better place to >>+// put them is in one of the .so's preloaded into the client, since >>+// the client's ld.so will know about it and so gcc's unwinder >>+// (somehow) is able to get hold of it. It's no mystery. At PT_INTERP time, ld.so registers one of its own functions into the .eh_frame machinery. (Note Elf32_Phdr.p_type of GNU_EH_FRAME.) The unwinder accesses the .eh_frame machinery and calls the registered function, which then uses dl_iterate_phdr to go over all the loaded modules and supply the corresponding info for the unwinder. -- |
|
From: Julian S. <js...@ac...> - 2006-04-29 03:03:00
|
It seems to me the cleanest solution is to get rid of VG_(x86_linux_REDIR_FOR__dl_sysinfo_int80) completely. This makes Joe's program work properly, since the gcc unwinder is no longer confused by our fake replacement function which lacks unwind info. Unfortunately this breaks our own stack unwind hack, in m_stacktrace, on x86-linux, creating less useful traces for stacks which end in a syscall. (This is the only purpose I could find for the redirect). Fortunately it is easily fixed just by looking for and noting the address of the real _dl_sysinfo_int80, which is easily done whilst reading debug info, since m_redir inspects all incoming symbols. The attached patch (against the svn trunk, r5865) does all that. Joe: can you try it? J On Friday 28 April 2006 22:42, Julian Seward wrote: > On Wednesday 19 April 2006 00:31, Tom Hughes wrote: > > In message <200...@ac...> you wrote: > > > > I seem to recall that I decided that the problem was a lack > > > > of DWARF debug information for the system call frame when valgrind > > > > replaces the vDSO routines with it's own ones. The system ones > > > > delberately have DWARF unwind information and ours don't. > > > > > > That would make sense. From Joe's printout it seems like the > > > unwinder manages to unwind 6 frames before going wrong, so it's > > > not the signal delivery frame that's the problem. > > > > > > Uh .. but which of our routines did you mean? I'm unclear. > > > Is it VG_(x86_linux_REDIR_FOR__dl_sysinfo_int80) ? > > > > That's the routine I was thinking of, yes. > > Tom > > After some poking around with the information Joseph supplied, > I see that that is indeed where the glibc unwinder stops - > having managed to recreate the problem on FC5. > > I can't think of an easy way to attach unwind info to that routine > (we could add it, but glibc in the client can't see it, so no point). > > But I can't figure out why we even need this function in the first > place. What's the point? I know Jeremy added it for some reason, > but I dunno what. I disabled the redirection to it (set up in > m_redir.c) and Joseph's test program then works fine. > > J > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: <js...@ac...> - 2006-04-29 02:56:24
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2006-04-29 04:40:00 CEST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 210 tests, 6 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/ppc32/mftocrf (stdout) |
|
From: Tom H. <to...@co...> - 2006-04-29 02:46:01
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-04-29 03:30:05 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 236 tests, 7 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/sse1_memory (stdout) memcheck/tests/xml1 (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-04-29 02:33:53
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-04-29 03:15:02 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 235 tests, 21 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) memcheck/tests/xml1 (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-04-29 02:27:24
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-04-29 03:10:05 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 258 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/sse1_memory (stdout) memcheck/tests/xml1 (stderr) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-04-29 02:23:32
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2006-04-29 03:05:13 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 258 tests, 7 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) memcheck/tests/xml1 (stderr) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-04-29 02:14:43
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-04-29 03:00:02 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 258 tests, 7 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: <js...@ac...> - 2006-04-29 01:27:53
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-04-29 03:30:01 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 234 tests, 6 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |