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
(9) |
3
(11) |
4
(12) |
5
(11) |
|
6
(9) |
7
(13) |
8
(6) |
9
(7) |
10
(7) |
11
(11) |
12
(13) |
|
13
(7) |
14
(6) |
15
(7) |
16
(19) |
17
(20) |
18
(9) |
19
(9) |
|
20
(6) |
21
(7) |
22
(11) |
23
(16) |
24
(14) |
25
(24) |
26
(16) |
|
27
(20) |
28
(58) |
29
(7) |
30
(10) |
31
(15) |
|
|
|
From: <sv...@va...> - 2006-08-31 22:54:40
|
Author: weidendo
Date: 2006-08-31 23:54:36 +0100 (Thu, 31 Aug 2006)
New Revision: 6044
Log:
Callgrind: Fix annotate script for data produced with --dump-instr=3Dyes
I just noticed that this is still a little wrong, as counts for e.g.
"strcmp" from libc and "strcmp" from ld.so will make up only one entry,
with the object name randomly choosen... but otherwise, it matches
with the data shown by KCachegrind.
Modified:
trunk/callgrind/callgrind_annotate.in
Modified: trunk/callgrind/callgrind_annotate.in
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/callgrind/callgrind_annotate.in 2006-08-31 19:29:13 UTC (rev 60=
43)
+++ trunk/callgrind/callgrind_annotate.in 2006-08-31 22:54:36 UTC (rev 60=
44)
@@ -483,6 +483,7 @@
my $curr_fn;
my $curr_name;
my $curr_line_num =3D 0;
+ my $prev_line_num =3D 0;
=20
my $curr_cobj =3D "";
my $curr_cfile =3D "";
@@ -496,17 +497,19 @@
=20
# Read body of input file.
while (<INPUTFILE>) {
+ $prev_line_num =3D $curr_line_num;
+
s/#.*$//; # remove comments
- s/^\+(\d+)/$curr_line_num+$1/e;
- s/^\-(\d+)/$curr_line_num-$1/e;
- s/^\*/$curr_line_num/e;
- if (s/^(\d+|0x\w+)\s+//) {
+ s/^\+(\d+)/$prev_line_num+$1/e;
+ s/^\-(\d+)/$prev_line_num-$1/e;
+ s/^\*/$prev_line_num/e;
+ if (s/^(-?\d+|0x\w+)\s+//) {
$curr_line_num =3D $1;
if ($has_addr) {
if ($has_line) {
- s/^\+(\d+)/$curr_line_num+$1/e;
- s/^\-(\d+)/$curr_line_num-$1/e;
- s/^\*/$curr_line_num/e;
+ s/^\+(\d+)/$prev_line_num+$1/e;
+ s/^\-(\d+)/$prev_line_num-$1/e;
+ s/^\*/$prev_line_num/e;
=20
if (s/^(\d+)\s+//) { $curr_line_num =3D $1; }
}
|
|
From: Josef W. <Jos...@gm...> - 2006-08-31 22:47:10
|
Hi, I can reproduce it: when instrumentation is switched off, and you request zeroing of all counters, switching instrumentation on afterwards gives the assertion. I'll try to come up with a fix. (Could take a little as I am leaving for a trip tomorrow) A workaround could be to start callgrind with instrumentation switched off; then, all counters will stay zero until you switch instrumentation on, ie. no need to zero them via callgrind_control. Note that requesting a dump will implicitly set all counters to zero. Josef On Thursday 31 August 2006 23:12, Christoph Bartoschek wrote: > I've played around with callgrind_control. This are the last commands before > the crash: > > devel@burns:~/pview> callgrind_control -d blbu > PID 9578: ../src/src ../blockages_coarse.dip [requesting 'Dump blbu'...] > OK. > devel@burns:~/pview> callgrind_control -z > PID 9578: ../src/src ../blockages_coarse.dip [requesting 'Zero'...] > OK. > devel@burns:~/pview> callgrind_control -e > PID 9578: ../src/src ../blockages_coarse.dip [requesting 'Status'...] > No information available as instrumentation is switched off. > > devel@burns:~/pview> callgrind_control -i on > PID 9578: ../src/src ../blockages_coarse.dip > [requesting '+Instrumentation'...] > OK. > devel@burns:~/pview> > > And here the result: > > Callgrind: callstack.c:211 (vgCallgrind_push_call_stack): > Assertion 'current_entry->cxt != 0' failed. > ==9578== at 0x38019C75: report_and_quit (m_libcassert.c:136) > ==9578== by 0x38019F9F: vgPlain_assert_fail (m_libcassert.c:200) > ==9578== by 0x38011ECE: vgCallgrind_push_call_stack (callstack.c:211) > ==9578== by 0x38006F26: vgCallgrind_setup_bbcc (bbcc.c:529) > ==9578== by 0x62CEF5D3: ??? > ==9578== by 0x3802848F: vgPlain_do_syscall (m_syscall.c:258) > ==9578== by 0x624CABB3: ??? > ==9578== by 0x59: ??? > ==9578== by 0x624CAC6B: ??? > ==9578== by 0x59: ??? > > sched status: > running_tid=1 > > Thread 1: status = VgTs_Runnable > ==9578== at 0x4AC3872: > QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) > (in /home/devel/software/qt/lib/libQtCore.so.4.2.0) > ==9578== by 0x4AC6265: QCoreApplication::exec() > (in /home/devel/software/qt/lib/libQtCore.so.4.2.0) > ==9578== by 0x425FFD6: QApplication::exec() > (in /home/devel/software/qt/lib/libQtGui.so.4.2.0) > ==9578== by 0x80511AA: main (in /home/devel/pview/src/src) > |
|
From: Christoph B. <bar...@gm...> - 2006-08-31 21:12:21
|
Hi, I've played around with callgrind_control. This are the last commands befor= e=20 the crash: devel@burns:~/pview> callgrind_control -d blbu PID 9578: ../src/src ../blockages_coarse.dip [requesting 'Dump blbu'...] OK. devel@burns:~/pview> callgrind_control -z PID 9578: ../src/src ../blockages_coarse.dip [requesting 'Zero'...] OK. devel@burns:~/pview> callgrind_control -e PID 9578: ../src/src ../blockages_coarse.dip [requesting 'Status'...] No information available as instrumentation is switched off. devel@burns:~/pview> callgrind_control -i on PID 9578: ../src/src ../blockages_coarse.dip=20 [requesting '+Instrumentation'...] OK. devel@burns:~/pview> And here the result: Callgrind: callstack.c:211 (vgCallgrind_push_call_stack):=20 Assertion 'current_entry->cxt !=3D 0' failed. =3D=3D9578=3D=3D at 0x38019C75: report_and_quit (m_libcassert.c:136) =3D=3D9578=3D=3D by 0x38019F9F: vgPlain_assert_fail (m_libcassert.c:200) =3D=3D9578=3D=3D by 0x38011ECE: vgCallgrind_push_call_stack (callstack.c= :211) =3D=3D9578=3D=3D by 0x38006F26: vgCallgrind_setup_bbcc (bbcc.c:529) =3D=3D9578=3D=3D by 0x62CEF5D3: ??? =3D=3D9578=3D=3D by 0x3802848F: vgPlain_do_syscall (m_syscall.c:258) =3D=3D9578=3D=3D by 0x624CABB3: ??? =3D=3D9578=3D=3D by 0x59: ??? =3D=3D9578=3D=3D by 0x624CAC6B: ??? =3D=3D9578=3D=3D by 0x59: ??? sched status: running_tid=3D1 Thread 1: status =3D VgTs_Runnable =3D=3D9578=3D=3D at 0x4AC3872:=20 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)=20 (in /home/devel/software/qt/lib/libQtCore.so.4.2.0) =3D=3D9578=3D=3D by 0x4AC6265: QCoreApplication::exec()=20 (in /home/devel/software/qt/lib/libQtCore.so.4.2.0) =3D=3D9578=3D=3D by 0x425FFD6: QApplication::exec()=20 (in /home/devel/software/qt/lib/libQtGui.so.4.2.0) =3D=3D9578=3D=3D by 0x80511AA: main (in /home/devel/pview/src/src) |
|
From: Bryan M. <om...@br...> - 2006-08-31 20:18:51
|
Julian,
looking in readdwarf.c and storage.c, I think I can put a patch together
that adds a flag into DiSym in order to indicate "no return", "return"
or "unknown" (for when the debug isn't there and it's time to hit a
fall-back method - this would also be the default value).
Would it be of interest? I don't want to spend time doing this if its
not going to go in (pending code review etc of course).
My idea is to extend the read_unitinfo_dwarf2 function by a) passing in
the seginfo pointer in order to give access to the symtab and b) to
parse out TAG_subprogram entries.
Basically, a void function has no type (AT_type) entry. Once a
subprogram is fully parsed, search_one_symtab can be used to find the
related DiSym and then update the entry from the default "unknown".
Bryan
Bryan Meredith wrote:
> Julian Seward wrote:
>>> Looking at the two programs side by side, I think the real crux of it is
>>> the differing epilog code. I think I am falling over trying to detect
>>> when there is a value being returned through the accumulator.
>> This sounds like a dataflow/liveness problem. So, let me unwind
>> one more level. Why do you want to know whether the accumulator
>> contains a live vs dead value at the point the function returns?
>> What are you going to do with that info?
>>
>> J
>>
>
> Julian,
>
> that's exactly the problem. If the accumulator holds a pointer to a
> memory block and is live, it should be left alone and tracked out of the
> function. If it is dead, it should be culled as the function exits,
> possibly generating a leak report if it is the final pointer to that block.
>
> If the pointer is dead but is left until it is over-written, the
> location of the leak report is inaccurate.
>
> The ability to detect the dead value allows function scope related
> checking for leaks. As an example (this is scope2.c in the test directory):
>
> #include <stdlib.h>
>
> static void func1(void)
> {
> char *pointer = 0;
>
> pointer = malloc(64); /* Line 7 */
>
> return;
> } /* Leak report Line 10 */
>
> int main(int argc, char *argv[])
> {
> func1();
>
> return 0; /* Line 16 */
> }
>
> At line 7, the malloc() call returns the pointer in the accumulator
> which is then also saved into the stack variable "pointer". As the
> function exits, the stack unwinds, removing the reference in "pointer"
> but the accumulator will still hold a reference. If the accumulator is
> detected as being dead, a leak report will be generated at line 10 as we
> remove the reference it is holding and discover it is the last one. If
> we don't invalidate the accumulator, we get the leak report at line 16
> instead when the reference is overwritten by 0 in order to be returned
> by main().
>
> A report at line 16 is not only inferior to a report at line 10, it is
> not going to provide the clarity that Omega should supply in it's goal
> to assist in tracking down memory leaks: a report at line 10 makes it
> pretty obvious that something went out of scope whilst a report at line
> 16 will leave most people scratching their heads.
>
> It's pretty fundamental to the whole thing which is why I could do with
> a robust method for determining when to cull registers on exit and when
> to leave them alone - the ABI is simply not enough.
>
> Hope that explains it,
> Bryan
>
> -------------------------------------------------------------------------
> 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: <sv...@va...> - 2006-08-31 19:29:22
|
Author: weidendo
Date: 2006-08-31 20:29:13 +0100 (Thu, 31 Aug 2006)
New Revision: 6043
Log:
callgrind: Fix warning about malformed creator line in annotate script
This also changes the default filename (if not given) to callgrind.out.*
Modified:
trunk/callgrind/callgrind_annotate.in
Modified: trunk/callgrind/callgrind_annotate.in
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/callgrind/callgrind_annotate.in 2006-08-31 11:08:59 UTC (rev 60=
42)
+++ trunk/callgrind/callgrind_annotate.in 2006-08-31 19:29:13 UTC (rev 60=
43)
@@ -100,6 +100,7 @@
my $cmd =3D "";
=20
# Info on the profiled process.
+my $creator =3D "";
my $pid =3D "";
my $part =3D "";
my $thread =3D "";
@@ -310,10 +311,12 @@
}
=20
if ($input_file eq "") {
- $input_file =3D (<cachegrind.out*>)[0];
+ $input_file =3D (<callgrind.out*>)[0];
if (!defined $input_file) {
- $input_file =3D "cachegrind.out";
+ $input_file =3D (<cachegrind.out*>)[0];
}
+
+ (defined $input_file) or die($usage);
print "Reading data from '$input_file'...\n";
}
}
@@ -403,6 +406,7 @@
else { $desc .=3D "$dline\n"; }
}
elsif (/^cmd:\s+(.*)$/) { $cmd =3D $1; }
+ elsif (/^creator:\s+(.*)$/) { $creator =3D $1; }
elsif (/^positions:\s+(.*)$/) {
my $positions =3D $1;
$has_line =3D ($positions =3D~ /line/);
@@ -670,6 +674,11 @@
sub print_options ()
{
print($fancy);
+ print "Profile data file '$input_file'";
+ if ($creator ne "") { print " (creator: $creator)"; }
+ print "\n";
+
+ print($fancy);
print($desc);
my $target =3D $cmd;
if ($pid ne "") {
|
|
From: <sv...@va...> - 2006-08-31 11:09:08
|
Author: sewardj
Date: 2006-08-31 12:08:59 +0100 (Thu, 31 Aug 2006)
New Revision: 6042
Log:
Update.
Modified:
trunk/docs/internals/3_2_BUGSTATUS.txt
Modified: trunk/docs/internals/3_2_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_2_BUGSTATUS.txt 2006-08-28 22:59:58 UTC (rev 6=
041)
+++ trunk/docs/internals/3_2_BUGSTATUS.txt 2006-08-31 11:08:59 UTC (rev 6=
042)
@@ -5,6 +5,7 @@
many =3D fix composed of many commits
sse3fix =3D fixed by the SSE3 commits
[W] =3D waiting for feedback from bug reporter
+Vfd =3D fix has been verified on 3.2.X branch
=20
------- Bugs reported after (in) 3.2.0 ------
=20
@@ -16,16 +17,16 @@
v5978 v6015 n-i-bz 'c' in --gen-supps=3Dyes doesn't work
v5986 v6016 n-i-bz VG_N_SEGMENTS too low (users, 28 June)
v6030 v6031 n-i-bz VG_N_SEGNAMES too low (Stu Robinson)
-sse3fix vx1646 106852 x86->IR: fisttp (SSE3)
+sse3fix vx1646 Vfd 106852 x86->IR: fisttp (SSE3)
v5968 v6017 117172 FUTEX_WAKE does not use uaddr2
v5970 v6018 124039 Lacks support for VKI_[GP]IO_UNIMAP*
-vx1639 vx1649 127521 amd64->IR: 0xF0 0x48 0xF 0xC7 (cmpxchg8b)
-vx1632/v5987
+vx1639 vx1649 Vfd 127521 amd64->IR: 0xF0 0x48 0xF 0xC7 (cmpxchg8b)
+vx1632/v5987 Vfd
vx1643/v6032 128917 amd64->IR: 0x66 0xF 0xF6 0xC4 (psadbw,SSE=
2)
v5988 v6019 129246 JJ: ppc32/ppc64 syscalls, w/ patch
-sse3fix vx1646 129358 x86->IR: fisttpl (SSE3)
+sse3fix vx1646 Vfd 129358 x86->IR: fisttpl (SSE3)
pending pending 129390 ppc?->IR: some kind of VMX prefetch (dstt=
)
-v6003,4 v6025 129866 cachegrind/callgrind causes executable to=
die
+v6003,4 v6025 Vfd 129866 cachegrind/callgrind causes executable to=
die
pending pending 129968 amd64->IR: 0xF 0xAE 0x0 (fxsave)
v5979 v6021 130020 Can't stat .so/.exe error while reading s=
ymbols
wontfix wontfix 130358 Inconsistent 80-bit floats on x86
@@ -36,11 +37,11 @@
vx1634 vx1645 131481: (HINT_NOP) vex x86->IR: 0xF 0x1F 0x0 0xF
131298 =3D=3D131481
=20
-vx1638 vx1648 132146 Programs with long sequences of bswap[l,q=
]s
+vx1638 vx1648 Vfd 132146 Programs with long sequences of bswap[l,q=
]s
=20
pending pending [W] 132918 vex amd64->IR: 0xD9 0xF8 (fprem)
-vx1652,3 vx1654 132813 Assertion at priv/guest-x86/toIR.c:652 fa=
ils
-pending pending [W] 133051 'cfsi->len > 0 && cfsi->len < 2000000' fa=
iled
+vx1652,3 vx1654 Vfd 132813 Assertion at priv/guest-x86/toIR.c:652 fa=
ils
+v6040 v6041 133051 'cfsi->len > 0 && cfsi->len < 2000000' fa=
iled
pending pending [W] 133054 'make install' fails with syntax errors
v6036 v6037 132722 valgrind header files are not standard C
=20
@@ -66,4 +67,6 @@
vx1640,1 vx1650 n-i-bz ppc cmp reg,reg fix
vx1642 vx1651 n-i-bz x86/amd64 iropt e/rflag reduction rules
=20
-fix for make install with older bashes.
+pending wontfix 133154 crash when using client requests to=20
+ register/deregister stack
+supp for suse 10.1 ppc32
|
|
From: <js...@ac...> - 2006-08-31 10:57:10
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-08-31 09: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 == 207 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) 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: <js...@ac...> - 2006-08-31 04:10:43
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-08-31 04:30:10 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 == 237 tests, 5 stderr failures, 1 stdout failure, 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/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-08-31 03:20:02
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-08-31 03:00: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 == 268 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/tls (stdout) |
|
From: Tom H. <to...@co...> - 2006-08-31 02:45:53
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-08-31 03:30:06 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 == 239 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-08-31 02:24:58
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-08-31 03:10:04 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 == 266 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-08-31 02:24:24
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-08-31 03:15:02 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/cc0bHGkR.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc0bHGkR.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc0bHGkR.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc0bHGkR.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc0bHGkR.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc0bHGkR.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc0bHGkR.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc0bHGkR.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.19693/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.19693/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.19693/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.19693/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.19693/valgrind' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/cczCE8Ww.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cczCE8Ww.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cczCE8Ww.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cczCE8Ww.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cczCE8Ww.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cczCE8Ww.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cczCE8Ww.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cczCE8Ww.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.19693/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.19693/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.19693/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.19693/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.19693/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Aug 31 03:19:49 2006 --- new.short Thu Aug 31 03:24:32 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/cczCE8Ww.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cczCE8Ww.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cczCE8Ww.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cczCE8Ww.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cczCE8Ww.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cczCE8Ww.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cczCE8Ww.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cczCE8Ww.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 --- 7,16 ---- Last 20 lines of verbose log follow echo ! /tmp/cc0bHGkR.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc0bHGkR.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc0bHGkR.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc0bHGkR.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc0bHGkR.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc0bHGkR.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc0bHGkR.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc0bHGkR.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-08-31 02:20:01
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-08-31 03:05:03 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 == 266 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Julian S. <js...@ac...> - 2006-08-31 01:24:12
|
> No, it's (a), because the kernel leaves the 224 bytes immediately > below the current stack pointer untouched when creating a signal > frame. We did that a long time ago because we thought we might one > day want to run XCOFF programs using some sort of emulation. The > kernel also allows programs to access a short distance below the > current stack pointer, and will extend the stack mapping if necessary. Uh, ok. I'll file a glibc bug report nevertheless. J |
|
From: Paul M. <pa...@sa...> - 2006-08-31 00:03:29
|
Julian Seward writes: > Thanks. A clarification: when you say will-actually-work, do you mean > that > > (a) it does not conform to the ABI, but will always give the right > outcome, regardless of what the what the program is doing, or > > (b) it will mostly appear to work, but very occasionally will get > trashed by, or will itself trash, any signal frame(s) constructed > while the function is active > > ? > > My understanding is (b). No, it's (a), because the kernel leaves the 224 bytes immediately below the current stack pointer untouched when creating a signal frame. We did that a long time ago because we thought we might one day want to run XCOFF programs using some sort of emulation. The kernel also allows programs to access a short distance below the current stack pointer, and will extend the stack mapping if necessary. Paul. |