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
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(3) |
2
(5) |
3
(7) |
4
(8) |
5
(3) |
|
6
(2) |
7
|
8
(2) |
9
(20) |
10
(2) |
11
(14) |
12
(21) |
|
13
(6) |
14
(9) |
15
(31) |
16
(7) |
17
(5) |
18
(14) |
19
(3) |
|
20
(6) |
21
(9) |
22
(19) |
23
(14) |
24
(16) |
25
(10) |
26
(3) |
|
27
(2) |
28
(1) |
29
(10) |
30
(6) |
31
(16) |
|
|
|
From: Jeremy F. <je...@go...> - 2005-03-14 22:21:14
|
Christopher Gautier wrote:
>This message is about a problem I encountered with valgrind, how I
>investigated it, and how I "fixed" it. I'm not sure the "fix" is
>correct.
>
>I recently upgraded valgrind on my Debian box, and I could not
>valgrind a heavily multi-threaded project anymore (100+ threads).
>It would deadlock. strace told me that the system was regularly
>polling on a futex(FUTEX_WAIT) call.
>
>What would happen is that valgrind would run for a few seconds (so that
>most of the threads are spawned), then 2 messages like this would
>appear:
>
>
OK, that should be pretty easy to fix. Your change isn't correct, but
it isn't far off. I think the correct fix is to only look at the
arguments a particular futex operation actually uses.
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-14 22:17:32
|
Patrick Ohly wrote:
>Hi all,
>
>I ran into a problem with 2.4.0rc3 on EL3.0. The child process of
>a MPI application segfaults inside vgMemCheck_fpu_write_check.
>Unfortunately I cannot simplify the application to make running
>it easier, therefore I am reluctant to file it as a bug.
>
>
Could you try checking out CVS head? I fixed a problem in that function
over the weekend.
J
|
|
From: Christopher G. <kr...@vi...> - 2005-03-14 17:16:21
|
This message is about a problem I encountered with valgrind, how I
investigated it, and how I "fixed" it. I'm not sure the "fix" is
correct.
I recently upgraded valgrind on my Debian box, and I could not
valgrind a heavily multi-threaded project anymore (100+ threads).
It would deadlock. strace told me that the system was regularly
polling on a futex(FUTEX_WAIT) call.
What would happen is that valgrind would run for a few seconds (so that
most of the threads are spawned), then 2 messages like this would
appear:
==13761== Syscall param futex(futex2) points to unaddressable byte(s)
==13761== at 0x1B95C64D: pthread_cond_broadcast@@GLIBC_2.3.2 (in
/lib/tls/libpthread-0.60.so)
==13761== by 0x1B9415B2: PR_Unlock (in /usr/lib/libnspr4.so)
==13761== by 0x1B9CB130: skpInternalPipe::CloseW() (internalpipe.cpp:87)
==13761== by 0x1B9C2256: skpInternalFilter::CloseOutgoingInterfaces()
(ifilter.cpp:347)
(...more lines of my stack...)
==13761== Address 0x7FFFFFFF is not stack'd, malloc'd or (recently) free'd
1) Looking into /lib/tls/libpthread-0.60.so, I found:
00007600 <pthread_cond_broadcast@@GLIBC_2.3.2>:
...
7637: b9 03 00 00 00 mov $0x3,%ecx
763c: b8 f0 00 00 00 mov $0xf0,%eax
7641: be ff ff ff 7f mov $0x7fffffff,%esi
7646: ba 01 00 00 00 mov $0x1,%edx
764b: cd 80 int $0x80
Man page for futex gives the prototype:
* int futex (int *uaddr, int op, int val, const struct timespec *timeout,
int *uaddr2, int val3);
* Note that %ecx=3 corresponds to FUTEX_REQUEUE.
* %esi refers to the 4th parameters, that means timeout=$0x7fffffff.
Sure enough, this is not a valid pointer. Why libc puts such value?
2) Next step was to look into the kernel itself (I tried 2.6.9)
Reading kernel/futex.c, and do_futex() more precisely,
case FUTEX_REQUEUE:
ret = futex_requeue(uaddr, uaddr2, val, val2, NULL);
break;
The timeout parameter is ignored, therefore putting $0x7fffffff is of no
consequence.
(reading the [Futexes are tricky] paper from Ulrich Drepper,
it seems that this value should not be ignored, but this is another story..)
diff -ru valgrind-2.2.0+2.4.0rc3-orig/coregrind/linux/syscalls.c
valgrind-2.2.0+2.4.0rc3/coregrind/linux/syscalls.c
--- valgrind-2.2.0+2.4.0rc3-orig/coregrind/linux/syscalls.c 2005-03-11
07:29:41.000000000 +0100
+++ valgrind-2.2.0+2.4.0rc3/coregrind/linux/syscalls.c 2005-03-14
16:08:48.000000000 +0100
@@ -419,7 +419,7 @@
SYS_PRE_MEM_READ( "futex(futex)", arg1, sizeof(int) );
if (arg2 == VKI_FUTEX_WAIT && arg4 != 0)
SYS_PRE_MEM_READ( "futex(timeout)", arg4, sizeof(struct vki_timespec) );
- if (arg2 == VKI_FUTEX_REQUEUE)
+ if (arg2 == VKI_FUTEX_REQUEUE && arg4 != 0x7FFFFFFF)
SYS_PRE_MEM_READ( "futex(futex2)", arg4, sizeof(int) );
}
And this fixed my problem. I'm not sure why, but it did :)
A summary of my machine:
valgrind-2.2.0+2.4.0rc3
kernel 2.6.9
libc6 2.3.2.ds1-20
--
Christopher Gautier
|
|
From: Patrick O. <Pat...@in...> - 2005-03-14 16:29:13
|
On Mon, 2005-03-14 at 23:10 +0100, Patrick Ohly wrote: > I ran into a problem with 2.4.0rc3 on EL3.0. The child process of > a MPI application segfaults inside vgMemCheck_fpu_write_check. I forgot to mention that 2.2.0 works fine with the same program and reports no errors in the code which is active when the segfault occurs. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. |
|
From: Patrick O. <Pat...@in...> - 2005-03-14 15:08:56
|
Hi all,
I ran into a problem with 2.4.0rc3 on EL3.0. The child process of
a MPI application segfaults inside vgMemCheck_fpu_write_check.
Unfortunately I cannot simplify the application to make running
it easier, therefore I am reluctant to file it as a bug.
Here's what I did:
- run app
- attach to second process with gdb
- wait till it segfaults (no debug infos found - is that normal?)
Program received signal SIGSEGV, Segmentation fault.
0xb7261601 in ?? ()
(gdb) where
#0 0xb7261601 in ?? ()
#1 0x1be90000 in ?? ()
#2 0x52bfdccc in ?? ()
#3 0xb01afac0 in ?? ()
#4 0xb0acceab in ?? ()
#5 0xb007cef3 in ?? ()
#6 0xb0010000 in ?? ()
#7 0xb03fff68 in ?? ()
#8 0x00000013 in ?? ()
(gdb) disassemble 0xb72615d8 0xb7261610
Dump of assembler code from 0xb72615d8 to 0xb7261610:
0xb72615d8: push $0x2
0xb72615da: jmp 0xb72615cb
0xb72615dc: test $0x3,%eax
0xb72615e1: jne 0xb726163c
0xb72615e3: movzwl %cx,%edx
0xb72615e6: lea 0x4(%eax),%esi
0xb72615e9: shr $0x10,%eax
0xb72615ec: mov 0xb72b2400(,%eax,4),%ebx
0xb72615f3: mov %edx,%eax
0xb72615f5: shr $0x3,%eax
0xb72615f8: cmpb $0x0,(%eax,%ebx,1)
0xb72615fc: jne 0xb726163c
0xb72615fe: shr $0x2,%edx
0xb7261601: movl $0x0,0x2000(%ebx,%edx,4)
0xb726160c: mov %esi,%eax
0xb726160e: mov %esi,%edx
$ cat /proc/11924/maps
...
b7253000-b72b2000 r-xp 00000000 00:0e
2360971 /Projects/software/IA32-LIN/valgrind-2.4.0-rc3/libc6-2.3.2/lib/valgrind/vgskin_memcheck.so
b72b2000-b72b3000 rw-p 0005e000 00:0e
2360971 /Projects/software/IA32-LIN/valgrind-2.4.0-rc3/libc6-2.3.2/lib/valgrind/vgskin_memcheck.so
...
Find offset in shared object:
0xb7261601 - 0xb7253000 = 0xe601
$ objdump
-d /Projects/software/IA32-LIN/valgrind-2.4.0-rc3/libc6-2.3.2/lib/valgrind/vgskin_memcheck.so | less
...
0000e590 <vgMemCheck_fpu_write_check>:
e590: 55 push %ebp
e591: 89 e5 mov %esp,%ebp
e593: 83 fa 04 cmp $0x4,%edx
e596: 56 push %esi
e597: 53 push %ebx
e598: 89 c1 mov %eax,%ecx
e59a: 0f 84 a0 00 00 00 je e640
<vgMemCheck_fpu_write_check+0xb0>
e5a0: 83 fa 08 cmp $0x8,%edx
e5a3: 74 37 je e5dc
<vgMemCheck_fpu_write_check+0x4c>
e5a5: 83 fa 02 cmp $0x2,%edx
e5a8: 74 2e je e5d8
<vgMemCheck_fpu_write_check+0x48>
e5aa: 83 fa 10 cmp $0x10,%edx
e5ad: 74 1b je e5ca
<vgMemCheck_fpu_write_check+0x3a>
e5af: 83 fa 0a cmp $0xa,%edx
e5b2: 74 16 je e5ca
<vgMemCheck_fpu_write_check+0x3a>
e5b4: 83 fa 1c cmp $0x1c,%edx
e5b7: 74 11 je e5ca
<vgMemCheck_fpu_write_check+0x3a>
e5b9: 83 fa 6c cmp $0x6c,%edx
e5bc: 74 0c je e5ca
<vgMemCheck_fpu_write_check+0x3a>
e5be: 81 fa 00 02 00 00 cmp $0x200,%edx
e5c4: 0f 85 9c 00 00 00 jne e666
<vgMemCheck_fpu_write_check+0xd6>
e5ca: 52 push %edx
e5cb: 51 push %ecx
e5cc: e8 4f 01 00 00 call e720
<mc_fpu_write_check_SLOWLY>
e5d1: 8d 65 f8 lea 0xfffffff8(%ebp),%esp
e5d4: 5b pop %ebx
e5d5: 5e pop %esi
e5d6: c9 leave
e5d7: c3 ret
e5d8: 6a 02 push $0x2
e5da: eb ef jmp e5cb
<vgMemCheck_fpu_write_check+0x3b>
e5dc: a9 03 00 00 00 test $0x3,%eax
e5e1: 75 59 jne e63c
<vgMemCheck_fpu_write_check+0xac>
e5e3: 0f b7 d1 movzwl %cx,%edx
e5e6: 8d 70 04 lea 0x4(%eax),%esi
e5e9: c1 e8 10 shr $0x10,%eax
e5ec: 8b 1c 85 00 f4 05 00 mov 0x5f400(,%eax,4),%ebx
e5f3: 89 d0 mov %edx,%eax
e5f5: c1 e8 03 shr $0x3,%eax
e5f8: 80 3c 18 00 cmpb $0x0,(%eax,%ebx,1)
e5fc: 75 3e jne e63c
<vgMemCheck_fpu_write_check+0xac>
e5fe: c1 ea 02 shr $0x2,%edx
e601: c7 84 93 00 20 00 00 movl $0x0,0x2000(%ebx,%edx,4)
e608: 00 00 00 00
I think that is the place, but I have no idea what I should try next.
Any suggestions?
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Software & Solutions Group
Hermuelheimer Strasse 8a
50321 Bruehl
Germany
Tel: +49-2232-2090-30
Fax: +49-2232-2090-29
|
|
From: Patrick O. <Pat...@in...> - 2005-03-14 14:47:53
|
On Fri, 2005-03-11 at 16:42 -0800, Jeremy Fitzhardinge wrote: > >This is probably irrelevant given the fact that 2.4.0 won't > >implement pthread calls itself any more. However, with > >2.4.0 rc2 I ran into another problem where creating > >threads in a forked process would lead to a valgrind > >assertion. > > > This should be fixed in CVS now. I'll probably put out rc3 later today, > depending on whether anything else serious turns up. Thanks, the problem is fixed. However, now I ran into another one, please see my other email. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. |
|
From: Dennis L. <pla...@in...> - 2005-03-13 23:47:42
|
Hi, is it planned to add supporessions for xorg (6.8.2) to next valgrind release ? greets Dennis |
|
From: Peter B. <pe...@bo...> - 2005-03-13 20:32:47
|
Jeremy Fitzhardinge <je...@go...> writes: > Hm, this looks like the same problem as described in the just-filed > bug 101423. Yes, that feels very similar. > What happens if you use --pointercheck=no? No change. > Is it possible to reproduce this in a smaller piece of stand-alone code? Replacing "float" with "double" in bug 101423 generates the same error. Reducing the snes9x code to just the loop does not. It so far away from the real code that it's hard to say if it's reduced to the minimum required to trigger it or if it's another bug. I'll stay glued to 101423 and test any developments there on my code. -- Peter Bortas http://peter.bortas.org |
|
From: Jeremy F. <je...@go...> - 2005-03-13 16:47:27
|
Peter Bortas wrote:
>I'm somewhat confused by this output from 2.4.0-rc3 when used on the
>Snes9X 1.43 release:
>
>-----8<--------------------------------------------------------
>% valgrind snes9x Math\ Test.zip
>==21305== Memcheck, a memory error detector for x86-linux.
>==21305== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
>==21305== Using valgrind-2.4.0.rc3, a program supervision framework for x86-linux.
>==21305== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
>==21305== For more details, rerun with: -v
>==21305==
>Rate: 22050, Buffer size: 2048, 16-bit: yes, Stereo: yes, Encoded: no
>No ROM file header found.
>"Math Test 2.0" [bad checksum] LoROM, 2Mbits, Type: ROM+RAM+BAT, Mode: 20, TV: NTSC, S-RAM: 32KB, ROMId: SNES Company: 00 CRC32: EB7DEC6D
>==21305==
>==21305== Process terminating with default action of signal 11 (SIGSEGV)
>==21305== Bad permissions for mapped region at address 0xB127C480
>==21305== at 0x80A9217: InitDSP() (dsp1emu.c:368)
>
>
Hm, this looks like the same problem as described in the just-filed bug
101423. What happens if you use --pointercheck=no? Is it possible to
reproduce this in a smaller piece of stand-alone code?
J
|
|
From: Peter B. <pe...@bo...> - 2005-03-13 12:25:36
|
I'm somewhat confused by this output from 2.4.0-rc3 when used on the
Snes9X 1.43 release:
-----8<--------------------------------------------------------
% valgrind snes9x Math\ Test.zip
==21305== Memcheck, a memory error detector for x86-linux.
==21305== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==21305== Using valgrind-2.4.0.rc3, a program supervision framework for x86-linux.
==21305== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==21305== For more details, rerun with: -v
==21305==
Rate: 22050, Buffer size: 2048, 16-bit: yes, Stereo: yes, Encoded: no
No ROM file header found.
"Math Test 2.0" [bad checksum] LoROM, 2Mbits, Type: ROM+RAM+BAT, Mode: 20, TV: NTSC, S-RAM: 32KB, ROMId: SNES Company: 00 CRC32: EB7DEC6D
==21305==
==21305== Process terminating with default action of signal 11 (SIGSEGV)
==21305== Bad permissions for mapped region at address 0xB127C480
==21305== at 0x80A9217: InitDSP() (dsp1emu.c:368)
==21305==
==21305== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 29 from 1)
==21305== malloc/free: in use at exit: 10600342 bytes in 17 blocks.
==21305== malloc/free: 29 allocs, 12 frees, 10627986 bytes allocated.
==21305== For counts of detected errors, rerun with: -v
==21305== searching for pointers to 17 not-freed blocks.
==21305== checked 12296084 bytes.
==21305==
==21305== LEAK SUMMARY:
==21305== definitely lost: 0 bytes in 0 blocks.
==21305== possibly lost: 0 bytes in 0 blocks.
==21305== still reachable: 10600342 bytes in 17 blocks.
==21305== suppressed: 0 bytes in 0 blocks.
==21305== Reachable blocks (those to which a pointer was found) are not shown.
==21305== To see them, rerun with: --show-reachable=yes
zsh: segmentation fault valgrind snes9x Math\ Test.zip
-----8<--------------------------------------------------------
That would make the SinTable2 the culprit in this loop, and commenting
it out makes it work. The CosTable2 with the same code does work, and
if I back down to valgrind-2.2.0 shipped with Debian testing it also
works.
unsigned int i;
for (i=0; i<INCR; i++){
CosTable2[i] = (cos((double)(2*PI*i/INCR)));
> SinTable2[i] = (sin((double)(2*PI*i/INCR)));
}
It dies with i=1908.
Prerequisites from the top of dsp1emu.c:
#define INCR 2048
double CosTable2[INCR];
double SinTable2[INCR];
Ref:
http://www.lysator.liu.se/snes9x/1.43/snes9x-1.43-src.tar.gz
Compiled with --with-debug
--
Peter Bortas http://peter.bortas.org
|
|
From: overbored <ove...@ov...> - 2005-03-13 05:22:33
|
Anybody?
I just tried compiling this on another machine as well (different
distribution, RH8), and I tried 2.2.0 and 2.1.1. I always see the exact
same error. Google turns up nothing.
I also tried (to no avail) modifying that part of coregrind/Makefile
(full file attached) to:
all-local:
mkdir -p $(inplacedir); \
for i in $(val_PROGRAMS); do \
to=$(inplacedir)/$$(echo $$i | sed 's,libpthread.so,libpthread.so.0,'); \
rm -f $$$to; \
ln -sf ../$(subdir)/$$i $$to; \
done;
Can anybody please help? Thanks in advance.
Thus spake overbored on 3/2/2005 10:40 AM:
> Hi all, I just downloaded the bzip (2.2.0), and ran
>
> ./configure --prefix=$HOME/local && make
>
> During make, I get the following:
>
> ...
> make[4]: Entering directory `/coeus/yang/tmp/apps/valgrind-2.2.0/coregrind'
> mkdir -p ../.in_place
> for i in valgrind stage2 libpthread.so vg_inject.so; do \
> to=../.in_place/$(echo $i | sed
> 's,libpthread.so,libpthread.so.0,'); \
> rm -f $() { latex "all-local" && dvips "all-local" && rm
> "all-local.dvi" "all-local.aux" "all-local.log" && ps2pdf "all-local.ps"
> /bin/sh: -c: line 1: syntax error: unexpected end of file
> make[4]: *** [all-local] Error 2
> make[4]: Leaving directory
> `/coeus/yangsta/tmp/apps/valgrind-2.2.0/coregrind'
> ...
>
> I tried adding "; \" to the end of line 827 in coregrind/Makefile, but
> to no avail. Any help would be much appreciated. Thanks in advance.
>
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-13 05:05:31
|
On Sat, 12 Mar 2005, Dennis Lubert wrote: > ok, I know that the valgrind3 from svn will not be usable for the next > time Id just liket to have a look on its progress and so I tried to > check it out via "svn co http://svn.valgrind.org/" as stated on > valgrind.org but what I got is : > > speedy:~/cvs/valgrind-3.0 # svn co http://svn.valgrind.org/ > svn: PROPFIND request failed on '/' > svn: PROPFIND of '/': 200 OK (http://svn.valgrind.org) > > any idea what Im doing wrong ? I belive the instruction on the website were wrong, but have now been fixed. N |
|
From: Dennis L. <pla...@in...> - 2005-03-12 23:25:38
|
Hi, ok, I know that the valgrind3 from svn will not be usable for the next time Id just liket to have a look on its progress and so I tried to check it out via "svn co http://svn.valgrind.org/" as stated on valgrind.org but what I got is : speedy:~/cvs/valgrind-3.0 # svn co http://svn.valgrind.org/ svn: PROPFIND request failed on '/' svn: PROPFIND of '/': 200 OK (http://svn.valgrind.org) any idea what Im doing wrong ? greets Dennis |
|
From: Jeremy F. <je...@go...> - 2005-03-12 21:18:10
|
Duane Griffin wrote:
>Just FYI, the next symbol it fails on looks like this:
>
>16 PSYM 0 0 00000008 445 filename:var3;1;A12;13
>
>
I'm not sure I have any idea what that means. A parameter passed by
reference in a register?
>No time to look into it further at the moment, but I might try and come back to it later in the week.
>
>
I think the most useful fix will be to see if there's some way to get
the stabs parser to return cleanly without crashing. I don't think its
a good use of time to chase strange stabs generated by PGI Fortran,
unless you're really excited by it...
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-12 21:09:04
|
Tom Hughes wrote:
>The library isn't much use if it has dependencies. The output from
>running "objdump -G" on it might be, but only if we can work which
>stab is causing the crash.
>
I think if you just mmap the whole thing in, Valgrind will think it is
an object file and parse all the pieces, even though it isn't being used
as a library.
J
|
|
From: Duane G. <d.g...@ps...> - 2005-03-12 19:03:38
|
Tom Hughes wrote:
> The library isn't much use if it has dependencies. The output from
> running "objdump -G" on it might be, but only if we can work which
> stab is causing the crash.
OK, I've dumped the stabs info and recompiled the rc3 valgrind code with =
stabs_debug enabled to figure out where the problem is. It looks like =
the offending entry is this one:
12 GSYM 0 0 00000000 373 logical*2:t22=3D2;
I've had a bit of a look around in the code and managed to get it past =
the problem with the patch included below. Of course I have no idea if =
what I'm doing there is valid, or whether it might break anything else. =
Also, after it gets past that one, it goes on to crash on a completely =
different symbol a bit later. It seems pgf77 3.2 is generating some =
fairly idiosyncractic debugging information.
Just FYI, the next symbol it fails on looks like this:
16 PSYM 0 0 00000008 445 filename:var3;1;A12;13
No time to look into it further at the moment, but I might try and come =
back to it later in the week.
--- coregrind/vg_stabs.c.orig Sat Mar 12 19:02:30 2005
+++ coregrind/vg_stabs.c Sat Mar 12 19:02:08 2005
@@ -668,6 +668,12 @@
case 't': { /* typedef: 't' TYPE */
SymType *td =3D stabtype_parser(si, NULL, &p);
type =3D VG_(st_mktypedef)(def, NULL, td);
+
+ /* Work around problem with output from pgf77 3.2.
+ I've no idea what the spec says about this, or whether it
+ will break anything else. */
+ if (*p =3D=3D ';')
+ p++;
break;
}
|
|
From: Bob R. <bo...@br...> - 2005-03-12 16:59:11
|
On Sat, Mar 12, 2005 at 04:48:08PM +0000, Donna Robinson wrote: > On Saturday 12 March 2005 16:30, Nicholas Nethercote wrote: > > I get the following... is that a wait-for-DNS-to-update thing? > yep. valgrind.org works fine for me. > hang in there ... Wierd, it's working now. sorry for the trouble. Thanks again! Bob Rossi |
|
From: Donna R. <do...@te...> - 2005-03-12 16:48:20
|
On Saturday 12 March 2005 16:30, Nicholas Nethercote wrote: > I get the following... is that a wait-for-DNS-to-update thing? yep. valgrind.org works fine for me. hang in there ... |
|
From: Donna R. <do...@te...> - 2005-03-12 16:46:59
|
It's official: I am a moron. Commited my local path to the repo (Forbidden Thing To Do) Now fixed. Sorry! de |
|
From: Bob R. <bo...@br...> - 2005-03-12 16:37:55
|
On Sat, Mar 12, 2005 at 09:29:36AM +0000, Donna Robinson wrote: > On Saturday 12 March 2005 04:57, Bob Rossi wrote: > > Great job on the new site! Do you think it would be to much of a hassle > > to redirect valgrind.org->www.valgrind.org? > yr wish is my command: done. Thanks! BTW, you might already know, but I'm currently getting 'Internal Server Error' when going to valgring.org. The specific details are below. Bob Rossi Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, ce...@op... and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Apache/2.0.53 (FreeBSD) PHP/5.0.3 DAV/2 SVN/1.1.3 Server at valgrind.org Port 80 |
|
From: Nicholas N. <nj...@cs...> - 2005-03-12 15:17:07
|
On Fri, 11 Mar 2005, Jeremy Fitzhardinge wrote: > Hm, come to think of it, it is possible that --pointercheck isn't > completely implemented for FP instructions. I could believe this... it seems like there have been several cases where people have had problems that --pointercheck should have made impossible. (But I can't remember details now...) N |
|
From: Tom H. <to...@co...> - 2005-03-12 14:04:12
|
In message <E0D...@pe...>
"Duane Griffin" <d.g...@ps...> wrote:
> Jeremy Fitzhardinge wrote:
> >Tom Hughes wrote:
> >>
> >>I put a patch u plast night, although I'm worried it might break
> >>with stabs from other compilers. I agree this probably shouldn't
> >>hold up the release.
> >>
> >>
> >Looks fine to me; I just checked it in. We'll see if it breaks someone
> >else. I'm not sure where the 3rd parameter to R came from.
>
> The patch has made a difference, but I'm afraid it still crashes. I've
> added the full output to the bug entry. This time the error is:
>
> @@ unlikely looking definition in unparsed remains ";"
Unfortunately this time round there doesn't seem to be enough
information in the crash to diagnose the problem.
> If it would help I could make the library it is crashing on available
> download. It is fairly large though (>100MB), and has quite a few
> to dependencies.
The library isn't much use if it has dependencies. The output from
running "objdump -G" on it might be, but only if we can work which
stab is causing the crash.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Duane G. <d.g...@ps...> - 2005-03-12 13:54:52
|
Jeremy Fitzhardinge wrote: >Tom Hughes wrote: >> >>I put a patch u plast night, although I'm worried it might break >>with stabs from other compilers. I agree this probably shouldn't >>hold up the release. >> =20 >> >Looks fine to me; I just checked it in. We'll see if it breaks someone = >else. I'm not sure where the 3rd parameter to R came from. The patch has made a difference, but I'm afraid it still crashes. I've = added the full output to the bug entry. This time the error is: @@ unlikely looking definition in unparsed remains ";" If it would help I could make the library it is crashing on available to = download. It is fairly large though (>100MB), and has quite a few = dependencies. Cheers,=20 Duane. |
|
From: Donna R. <do...@te...> - 2005-03-12 09:29:48
|
On Saturday 12 March 2005 04:57, Bob Rossi wrote: > Great job on the new site! Do you think it would be to much of a hassle > to redirect valgrind.org->www.valgrind.org? yr wish is my command: done. de |
|
From: Jeremy F. <je...@go...> - 2005-03-12 09:04:36
|
I have made 2.4.0.rc3 available for testing at http://www.goop.org/~jeremy/valgrind/dist/. Please test it out and report any problems at http://bugs.kde.org/enter_valgrind_bug.cgi . Changes since rc2 are: * Fix which prevents an assertion failure when a threaded program forks, and the child starts a thread. * Fix a problem in which signals which have the default action of "ignore" (SIGCONT, WINCH, USR and CHLD) interrupted a blocked syscall. For these signals, Valgrind doesn't set a signal handler unless the client needs one. * Remove segment merging from mprotect(), which was causing rtldi to trigger a Valgrind internal error. * Fix the parsing of the 'R' floating-point type in the stabs parser. The full set of changes since 2.2.0 is attached. J |