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
(22) |
2
(19) |
3
(8) |
4
(34) |
5
(14) |
6
(14) |
|
7
(12) |
8
(15) |
9
(15) |
10
(10) |
11
(10) |
12
(28) |
13
(11) |
|
14
(22) |
15
(29) |
16
(20) |
17
(15) |
18
(39) |
19
(11) |
20
(12) |
|
21
(8) |
22
(9) |
23
(8) |
24
(10) |
25
(9) |
26
(7) |
27
(7) |
|
28
(6) |
29
(6) |
30
(11) |
|
|
|
|
|
From: Robert W. <rj...@du...> - 2004-11-18 22:56:15
|
CVS commit by rjwalsh:
Allow readlink to handle /proc/self/exe and /proc/<pid>/exe properly.
M +20 -5 vg_syscalls.c 1.224
M +1 -1 x86-linux/syscalls.c 1.7
--- valgrind/coregrind/vg_syscalls.c #1.223:1.224
@@ -4402,6 +4402,8 @@ POST(sys_poll)
}
-PRE(sys_readlink, 0)
+PRE(sys_readlink, Special)
{
+ char name[25];
+
PRINT("sys_readlink ( %p, %p, %llu )", arg1,arg2,(ULong)arg3);
PRE_REG_READ3(long, "readlink",
@@ -4409,8 +4411,21 @@ PRE(sys_readlink, 0)
PRE_MEM_RASCIIZ( "readlink(path)", arg1 );
PRE_MEM_WRITE( "readlink(buf)", arg2,arg3 );
-}
-POST(sys_readlink)
-{
+ /*
+ * Handle the single case where readlink failed reading /proc/self/exe.
+ */
+
+ VG_(sprintf)(name, "/proc/%d/exe", VG_(getpid)());
+
+ if (VG_(strcmp)((Char *)arg1, name) == 0 ||
+ VG_(strcmp)((Char *)arg1, "/proc/self/exe") == 0) {
+ VG_(sprintf)(name, "/proc/self/fd/%d", VG_(clexecfd));
+ res = VG_(do_syscall)(SYSNO, name, arg2, arg3);
+ }
+ else {
+ res = VG_(do_syscall)(SYSNO, arg1, arg2, arg3);
+ }
+
+ if (res > 0)
POST_MEM_WRITE( arg2, res );
}
--- valgrind/coregrind/x86-linux/syscalls.c #1.6:1.7
@@ -450,5 +450,5 @@ const struct SyscallTableEntry VGA_(sysc
// (__NR_oldlstat, sys_lstat), // 84 -- obsolete
- GENXY(__NR_readlink, sys_readlink), // 85
+ GENX_(__NR_readlink, sys_readlink), // 85
// (__NR_uselib, sys_uselib), // 86 */Linux
// (__NR_swapon, sys_swapon), // 87 */Linux
|
|
From: Robert W. <rj...@du...> - 2004-11-18 22:28:05
|
> > I was speaking to Jeremy about the issue we see with programs that do a
> > readlink on /proc/self/exe. Instead of trying to come up with a
> > complete solution that solves this for every possible scenario, I'd like
> > to check in an intermediate fix that simply handles the single scenario
> > where your code does this:
> >
> > readlink("/proc/self/exe", &buf, size);
> >
> > This will catch 99% of the cases and work now... If we can come up with
> > a better solution later, we can change it then.
>
> I already wrote a patch to do that - it's on the bug tracker
> somewhere. It turned out that it didn't help with the bug though
> as I recall as the program was using open or something.
Oh good - less work to do ;-) I've twiddled your patch so that it works
correctly with the new syscall work Nick has been doing. It works, in
that readlink now does the correct thing for this case. Should I go
ahead and check it in? Even though it isn't complete, as you pointed
out, it's still very useful.
Regards,
Robert.
|
|
From: Tom H. <th...@cy...> - 2004-11-18 22:12:10
|
In message <110...@he...>
Robert Walsh <rj...@du...> wrote:
> I was speaking to Jeremy about the issue we see with programs that do a
> readlink on /proc/self/exe. Instead of trying to come up with a
> complete solution that solves this for every possible scenario, I'd like
> to check in an intermediate fix that simply handles the single scenario
> where your code does this:
>
> readlink("/proc/self/exe", &buf, size);
>
> This will catch 99% of the cases and work now... If we can come up with
> a better solution later, we can change it then.
I already wrote a patch to do that - it's on the bug tracker
somewhere. It turned out that it didn't help with the bug though
as I recall as the program was using open or something.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Robert W. <rj...@du...> - 2004-11-18 21:32:49
|
Hi all,
I was speaking to Jeremy about the issue we see with programs that do a
readlink on /proc/self/exe. Instead of trying to come up with a
complete solution that solves this for every possible scenario, I'd like
to check in an intermediate fix that simply handles the single scenario
where your code does this:
readlink("/proc/self/exe", &buf, size);
This will catch 99% of the cases and work now... If we can come up with
a better solution later, we can change it then.
Is everyone OK with this? Personally, I need this at work for some code
that does this in multiple places, so I'm biased... ;-)
Regards,
Robert.
|
|
From: Josef W. <Jos...@gm...> - 2004-11-18 19:54:55
|
On Thursday 18 November 2004 19:34, Tom Hughes wrote: > In message <200...@gm...> ... > > rt_sigprocmask(SIG_SETMASK, ~[SEGV], ~[ILL BUS FPE KILL SEGV STOP], 8) = > > 0 getpid() = 15972 > > tgkill(15972, 15972, SIGSEGV) = 0 > > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > > +++ killed by SIGSEGV +++ > > That's completely different. That is the trace that you get when > valgrind decides it can't handle the signal and decides to kill > itself instead. Yes. If valgrind sees the faulting address of 0, it passes the segfault on to the client. > > As root, this gives the correct output: > > Signal 11, Addr 0xd000000 > > > > As normal user, I get > > Signal 11, Addr (nil) > > Well that's completely bogus. If the kernel doesn't give us the > right fault address then nothing is going to work. > > > I already supposed this to be a feature of SELinux. But I can't see how, > > and SELinux seems to be installed, but disabled. Looking at Suse's kernel > > source, I can't find anything (in arch/i386/mm/fault.c and > > kernel/signal.c). > > I'm running FC3 which has SELinux turned on and I don't have this > problem so it looks like something with the SuSE kernel. OK. One possibility less. > Are you looking at the SuSE kernel source? or the generic source > from kernel.org? I look into /usr/src/linux-2.6.8-24.3. And I did a grep on the full source for si_addr. Hmmm.... I found a candidate: I did a diff of vanilla 2.6.9 and the Suse9.2 2.6.8-24, and found this: ============================================= --- linux-2.6.9/arch/i386/mm/fault.c 2004-10-18 23:53:06.000000000 +0200 +++ linux-2.6.8-24.3/arch/i386/mm/fault.c 2004-10-26 18:50:30.000000000 +0200 @@ -227,7 +227,7 @@ asmlinkage void do_page_fault(struct pt_ __asm__("movl %%cr2,%0":"=r" (address)); if (notify_die(DIE_PAGE_FAULT, "page fault", regs, error_code, 14, - SIGSEGV) == NOTIFY_STOP) + SIGSEGV) == NOTIFY_OK) =============================================== Googling, this change is part of a "kprobes-exceptions-nofitier-fix", included into 2.6.9rc2, which isn't in the Suse kernel. But I am not sure if that's really the problem. I have no idea why this changes sefault behaviour between root and normal user. I think I will run plain 2.6.9 instead. And waiting for the next kernel in an Suse online update... ;-( BTW: This is a kernel from the last Suse online update. Perhaps the original one from the DVD does not show the problem. Josef > > Tom |
|
From: Nicholas N. <nj...@ca...> - 2004-11-18 18:35:39
|
On Tue, 9 Nov 2004, Stephen McCamant wrote: > The "coregrind_tools.html" file contains some obsolete documentation > about how to run Valgrind under GDB (i.e. for debugging bugs in > Valgrind and tools, rather than bugs in the program you're running > Valgrind on). The more recently added instructions in > "README_DEVELOPERS" seem to work fine, though. It seems to me that the > HTML documentation should either be updated with up-to-date > instructions, or replaced with a pointer to the README file. I committed your patch, thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2004-11-18 18:35:06
|
CVS commit by nethercote:
Fix incorrect info about using GDB on Valgrind.
MERGED FROM HEAD
M +2 -27 coregrind_tools.html 1.2.2.1
--- valgrind/coregrind/docs/coregrind_tools.html #1.2:1.2.2.1
@@ -548,31 +548,6 @@
If you want to debug C functions used by your tool, you can attach GDB to
-Valgrind with some effort:
-<ul>
- <li>Enable the following code in <code>coregrind/vg_main.c</code> by
- changing <code>if (0)</code> into <code>if (1)</code>:
-<pre>
- /* Hook to delay things long enough so we can get the pid and
- attach GDB in another shell. */
- if (0) {
- Int p, q;
- for (p = 0; p < 50000; p++)
- for (q = 0; q < 50000; q++) ;
- }
-</pre>
- </li><p>
- and rebuild Valgrind.
-
- <li>Then run:
- <blockquote><code>valgrind <i>prog</i></code></blockquote>
-
- Valgrind starts the program, printing its process id, and then delays for
- a few seconds (you may have to change the loop bounds to get a suitable
- delay).</li><p>
-
- <li>In a second shell run:
-
- <blockquote><code>gdb <i>prog</i> <i>pid</i></code></blockquote></li><p>
-</ul>
+Valgrind with some effort; see the file <code>README_DEVELOPERS</code> in
+CVS for instructions.<p>
GDB may be able to give you useful information. Note that by default
|
|
From: Tom H. <th...@cy...> - 2004-11-18 18:34:28
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> I get (as normal user):
> ...
> munmap(0xb031a000, 4096) = 0
> rt_sigaction(SIGSEGV, {SIG_DFL}, {0xb0037f77, ~[KILL STOP], SA_RESTORER|
> SA_STACK|SA_RESTART|SA_SIGINFO, 0xb0074c1e}, 8) = 0
> rt_sigprocmask(SIG_SETMASK, ~[SEGV], ~[ILL BUS FPE KILL SEGV STOP], 8) = 0
> getpid() = 15972
> tgkill(15972, 15972, SIGSEGV) = 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
That's completely different. That is the trace that you get when
valgrind decides it can't handle the signal and decides to kill
itself instead.
> Look at this small prog:
> ==============================
> #include <signal.h>
> char buf[1024];
>
> void handler(int s, siginfo_t *i, void *p)
> {
> sprintf(buf,"Signal %d, Addr %p\n", s, i->si_addr);
> write(1,buf,strlen(buf));
> exit(1);
> }
>
> int main()
> {
> struct sigaction sa;
> int *addr = 0xd000000;
>
> sa.sa_flags = SA_SIGINFO;
> sa.sa_sigaction = handler;
> sigaction(11,&sa,0);
>
> *addr = 5;
> return 0;
> }
> ====================================
> As root, this gives the correct output:
> Signal 11, Addr 0xd000000
>
> As normal user, I get
> Signal 11, Addr (nil)
Well that's completely bogus. If the kernel doesn't give us the
right fault address then nothing is going to work.
> I already supposed this to be a feature of SELinux. But I can't see how, and
> SELinux seems to be installed, but disabled. Looking at Suse's kernel source,
> I can't find anything (in arch/i386/mm/fault.c and kernel/signal.c).
I'm running FC3 which has SELinux turned on and I don't have this
problem so it looks like something with the SuSE kernel.
Are you looking at the SuSE kernel source? or the generic source
from kernel.org?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-11-18 18:34:08
|
CVS commit by nethercote:
Fix incorrect info about using GDB on Valgrind.
MERGE TO STABLE
M +2 -27 coregrind_tools.html 1.4
--- valgrind/coregrind/docs/coregrind_tools.html #1.3:1.4
@@ -548,31 +548,6 @@
If you want to debug C functions used by your tool, you can attach GDB to
-Valgrind with some effort:
-<ul>
- <li>Enable the following code in <code>coregrind/vg_main.c</code> by
- changing <code>if (0)</code> into <code>if (1)</code>:
-<pre>
- /* Hook to delay things long enough so we can get the pid and
- attach GDB in another shell. */
- if (0) {
- Int p, q;
- for (p = 0; p < 50000; p++)
- for (q = 0; q < 50000; q++) ;
- }
-</pre>
- </li><p>
- and rebuild Valgrind.
-
- <li>Then run:
- <blockquote><code>valgrind <i>prog</i></code></blockquote>
-
- Valgrind starts the program, printing its process id, and then delays for
- a few seconds (you may have to change the loop bounds to get a suitable
- delay).</li><p>
-
- <li>In a second shell run:
-
- <blockquote><code>gdb <i>prog</i> <i>pid</i></code></blockquote></li><p>
-</ul>
+Valgrind with some effort; see the file <code>README_DEVELOPERS</code> in
+CVS for instructions.<p>
GDB may be able to give you useful information. Note that by default
|
|
From: Nicholas N. <nj...@ca...> - 2004-11-18 18:24:26
|
CVS commit by nethercote:
Add link to Taintcheck.
M +4 -0 related.html 1.21
--- devel-home/valgrind/related.html #1.20:1.21
@@ -110,4 +110,8 @@
Kvasir.
<p>
+<li>CMU's <a href="http://www.ece.cmu.edu/~jnewsome/docs/taintcheck.pdf">
+ Taintcheck</a> exploit detector and analyser is implemented as a Valgrind
+ tool.
+ <p>
</ul>
|
|
From: Nicholas N. <nj...@ca...> - 2004-11-18 18:22:02
|
CVS commit by nethercote:
Arch-abstraction:
- Added a hacky mechanism which prevents the regtest script from entering
directories for other architectures. (Eg. when running on x86/, it won't enter
a ppc/ subdir.)
M +36 -12 cputest.c 1.6
M +7 -1 vg_regtest.in 1.26
--- valgrind/tests/cputest.c #1.5:1.6
@@ -3,5 +3,22 @@
#include <string.h>
-// We return 0 if the machine matches the asked-for cpu, 1 otherwise.
+// We return:
+// - 0 if the machine matches the asked-for cpu
+// - 1 if it didn't match, but did match the name of another arch
+// - 2 otherwise
+
+// When updating this file for a new architecture, add the name to
+// 'all_archs' as well as adding go().
+
+#define False 0
+#define True 1
+typedef int Bool;
+
+char* all_archs[] = {
+ "x86",
+ "ppc",
+ "amd64",
+ NULL
+};
#ifdef __x86__
@@ -17,10 +34,10 @@ static __inline__ void cpuid(unsigned in
}
-static int go(char* cpu)
+static Bool go(char* cpu)
{
unsigned int level = 0, mask = 0, a, b, c, d;
if ( strcmp( cpu, "x86" ) == 0 ) {
- return 0;
+ return True;
} else if ( strcmp( cpu, "x86-fpu" ) == 0 ) {
level = 1;
@@ -42,5 +59,5 @@ static int go(char* cpu)
mask = 1 << 26;
} else {
- return 1;
+ return False;
}
@@ -50,7 +67,7 @@ static int go(char* cpu)
cpuid( level, &a, &b, &c, &d );
- if ( ( d & mask ) != 0 ) return 0;
+ if ( ( d & mask ) != 0 ) return True;
}
- return 1;
+ return False;
}
#endif // __x86__
@@ -58,10 +75,10 @@ static int go(char* cpu)
#ifdef __ppc__
-static int go(char* cpu)
+static Bool go(char* cpu)
{
if ( strcmp( cpu, "ppc" ) == 0 )
- return 0;
+ return True;
else
- return 1;
+ return False;
}
#endif // __ppc__
@@ -70,8 +86,16 @@ static int go(char* cpu)
int main(int argc, char **argv)
{
+ int i;
if ( argc != 2 ) {
fprintf( stderr, "usage: cputest <cpu-type>\n" );
- exit( 1 );
+ exit( 2 );
}
- return go( argv[1] );
+ if (go( argv[1] )) {
+ return 0; // matched
+ }
+ for (i = 0; NULL != all_archs[i]; i++) {
+ if ( strcmp( argv[1], all_archs[i] ) == 0 )
+ return 1;
+ }
+ return 2;
}
--- valgrind/tests/vg_regtest.in #1.25:1.26
@@ -319,7 +319,13 @@
$dir =~ s/\/$//; # trim a trailing '/'
- # ignore dirs into which we should not recurse
+ # Ignore dirs into which we should not recurse.
if ($dir =~ /^(BitKeeper|CVS|SCCS|docs|doc)$/) { return; }
+ # Ignore any dir whose name matches that of an architecture which is not
+ # the architecture we are running on (eg. when running on x86, ignore ppc/
+ # directories).
+ # Nb: weird Perl-ism -- exit code of '1' is seen by Perl as 256...
+ if (256 == system("$tests_dir/tests/cputest $dir")) { return; }
+
chdir($dir) or die "Could not change into $dir\n";
|
|
From: Josef W. <Jos...@gm...> - 2004-11-18 17:39:24
|
On Thursday 18 November 2004 18:02, Tom Hughes wrote:
> In message <200...@gm...>
>
> Josef Weidendorfer <Jos...@gm...> wrote:
> >> > Hmm, it seems that those reports also had the problem with the currnet
> >> > CVS HEAD. Hmm.
> >>
> >> Does SuSE 9.2 use gcc 3.4 by any chance?
> >
> > No. It's "gcc (GCC) 3.3.4 (pre 3.3.5 20040809)"
> > It still segfaults. I don't know why, this morning it was working...
Another thing:
Valgrind as root is working. Perhaps I tried it as root.
> Try straceing the valgrind process and see what the last half dozen
> or so lines look like. The problem case looks like this:
>
> rt_sigaction(SIGSEGV, {0xf003950f, ~[], 0}, {0xf0041e92, ~[KILL STOP],
> SA_RESTORER|SA_STACK|SA_RESTART|SA_SIGINFO, 0xf0086d52}, 8) = 0
> rt_sigprocmask(SIG_SETMASK, NULL, ~[ILL BUS FPE KILL SEGV STOP], 8) = 0 ---
> SIGSEGV (Segmentation fault) @ 0 (0) ---
> rt_sigaction(SIGSEGV, {SIG_DFL}, NULL, 8) = 0
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
I get (as normal user):
...
munmap(0xb031a000, 4096) = 0
rt_sigaction(SIGSEGV, {SIG_DFL}, {0xb0037f77, ~[KILL STOP], SA_RESTORER|
SA_STACK|SA_RESTART|SA_SIGINFO, 0xb0074c1e}, 8) = 0
rt_sigprocmask(SIG_SETMASK, ~[SEGV], ~[ILL BUS FPE KILL SEGV STOP], 8) = 0
getpid() = 15972
tgkill(15972, 15972, SIGSEGV) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
There is no second sigaction.
Look at this small prog:
==============================
#include <signal.h>
char buf[1024];
void handler(int s, siginfo_t *i, void *p)
{
sprintf(buf,"Signal %d, Addr %p\n", s, i->si_addr);
write(1,buf,strlen(buf));
exit(1);
}
int main()
{
struct sigaction sa;
int *addr = 0xd000000;
sa.sa_flags = SA_SIGINFO;
sa.sa_sigaction = handler;
sigaction(11,&sa,0);
*addr = 5;
return 0;
}
====================================
As root, this gives the correct output:
Signal 11, Addr 0xd000000
As normal user, I get
Signal 11, Addr (nil)
I already supposed this to be a feature of SELinux. But I can't see how, and
SELinux seems to be installed, but disabled. Looking at Suse's kernel source,
I can't find anything (in arch/i386/mm/fault.c and kernel/signal.c).
Any idea?
Josef
>
> Note the second sigaction which sets SEGV to SIG_DFL which is complete
> nonsense.
>
> Tom
|
|
From: Tom H. <th...@cy...> - 2004-11-18 17:02:22
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
>> > Hmm, it seems that those reports also had the problem with the currnet
>> > CVS HEAD. Hmm.
>>
>> Does SuSE 9.2 use gcc 3.4 by any chance?
>
> No. It's "gcc (GCC) 3.3.4 (pre 3.3.5 20040809)"
> It still segfaults. I don't know why, this morning it was working...
Hmm. FC2 was 3.3.3 so I guess that's possible.
>> I was chasing a problem on my newly upgraded FC3 box last night which
>> uses gcc 3.4 rather than the 3.3 that it was using before and I'm
>> pretty sure that it is down to a compiler bug related to __builtin_setjmp
>> that is causing VG_(is_addressable) not to reinstall the correct SEGV
>> handler after it has run.
>
> But why is this also a problem with gcc 3.3.4?
> Where should I look to be sure that this is a compiler bug ?!?
Try straceing the valgrind process and see what the last half dozen
or so lines look like. The problem case looks like this:
rt_sigaction(SIGSEGV, {0xf003950f, ~[], 0}, {0xf0041e92, ~[KILL STOP], SA_RESTORER|SA_STACK|SA_RESTART|SA_SIGINFO, 0xf0086d52}, 8) = 0
rt_sigprocmask(SIG_SETMASK, NULL, ~[ILL BUS FPE KILL SEGV STOP], 8) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
rt_sigaction(SIGSEGV, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Note the second sigaction which sets SEGV to SIG_DFL which is complete
nonsense.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Richard v. d. H. <ric...@mx...> - 2004-11-18 16:38:03
|
Julian Seward wrote: > Yes, we are trying to do away with nested functions. Only gcc > supports them, and even the gcc folks don't like them, I think. > Can you fix this some other way? Okay then, I'll try harder :) Let's try the attached patch against CVS HEAD - unfortunately there are a few more changes, but it does fix it properly in a thread-safe kind of way. Cheers, -- Richard van der Hoff <ric...@mx...> Systems Analyst Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com |
|
From: Josef W. <Jos...@gm...> - 2004-11-18 16:30:25
|
> >> in CVS. I assume this is with the CVS HEAD? Could you try the CVS > >> VALGRIND_2_2_0_BRANCH and let us know if there is a problem with > >> that? Thanks. Currently, it always segfaults, either with HEAD or VALGRIND_2_2_0_BRANCH, so my previous reply was wrong ;-( > > Hmm, it seems that those reports also had the problem with the currnet > > CVS HEAD. Hmm. > > Does SuSE 9.2 use gcc 3.4 by any chance? No. It's "gcc (GCC) 3.3.4 (pre 3.3.5 20040809)" It still segfaults. I don't know why, this morning it was working... > I was chasing a problem on my newly upgraded FC3 box last night which > uses gcc 3.4 rather than the 3.3 that it was using before and I'm > pretty sure that it is down to a compiler bug related to __builtin_setjmp > that is causing VG_(is_addressable) not to reinstall the correct SEGV > handler after it has run. But why is this also a problem with gcc 3.3.4? Where should I look to be sure that this is a compiler bug ?!? Josef |
|
From: Nicholas N. <nj...@ca...> - 2004-11-18 15:32:17
|
On Thu, 18 Nov 2004, Tom Hughes wrote: > I was chasing a problem on my newly upgraded FC3 box last night which > uses gcc 3.4 rather than the 3.3 that it was using before and I'm > pretty sure that it is down to a compiler bug related to __builtin_setjmp > that is causing VG_(is_addressable) not to reinstall the correct SEGV > handler after it has run. Erk, that sucks... N |
|
From: Nicholas N. <nj...@ca...> - 2004-11-18 13:34:03
|
CVS commit by nethercote: Added missing .cvsignore file. A .cvsignore 1.1 |
|
From: Nicholas N. <nj...@ca...> - 2004-11-18 13:00:29
|
Josef, I've committed all those changes. Let me know if I've missed anything. N |
|
From: Nicholas N. <nj...@ca...> - 2004-11-18 12:58:59
|
CVS commit by nethercote:
Tweaks for keeping Josef's external Callgrind tool running, including a bumping
of the interface major version number.
M +2 -2 valgrind.pc.in 1.3
M +4 -1 include/tool.h.base 1.15
--- valgrind/valgrind.pc.in #1.2:1.3
@@ -2,5 +2,5 @@
exec_prefix=@exec_prefix@
libdir=@libdir@
-includedir=@includedir@
+includedir=@includedir@/valgrind
Name: Valgrind
@@ -9,3 +9,3 @@
Requires:
Libs:
-Cflags: -I${includedir} -I${includedir}/@VG_ARCH@ -I${includedir}/@VG_PLATFORM@
+Cflags: -I${includedir} -I${includedir}/@VG_ARCH@ -I${includedir}/@VG_OS@ -I${includedir}/@VG_PLATFORM@ @ARCH_TOOL_AM_CFLAGS@
--- valgrind/include/tool.h.base #1.14:1.15
@@ -80,6 +80,9 @@
interface; if the core and tool major versions don't match, Valgrind
will abort. The minor version indicates binary-compatible changes.
+
+ (Update: as it happens, we're never using the minor version number, because
+ there's no point in doing so.)
*/
-#define VG_CORE_INTERFACE_MAJOR_VERSION 6
+#define VG_CORE_INTERFACE_MAJOR_VERSION 7
#define VG_CORE_INTERFACE_MINOR_VERSION 0
|
|
From: Julian S. <js...@ac...> - 2004-11-18 12:56:30
|
Yes, we are trying to do away with nested functions. Only gcc supports them, and even the gcc folks don't like them, I think. Can you fix this some other way? J On Thursday 18 November 2004 12:36, Tom Hughes wrote: > In message <419...@mx...> > > Richard van der Hoff <ric...@mx...> wrote: > > The best way to fix this seems to be to make sprintf reentrant; > > attached is a patch to do so, using a nested function - which is of > > course a gcc-only extension. Is introducing a dependency on gcc a > > problem, or do we rely on gcc anyway? If the former, let me know, and > > I'll submit an alternative solution. > > I did take all the existing nested functions out a while back... > > Tom |
|
From: Nicholas N. <nj...@ca...> - 2004-11-18 12:49:07
|
CVS commit by nethercote:
Replace magic number with proper constant.
MERGED FROM HEAD
M +2 -1 vg_errcontext.c 1.58.2.3
--- valgrind/coregrind/vg_errcontext.c #1.58.2.2:1.58.2.3
@@ -338,5 +338,6 @@ static void gen_suppression(Error* err)
Int stop_at = VG_(clo_backtrace_size);
- if (stop_at > 4) stop_at = 4; /* At most four names */
+ /* At most VG_N_SUPP_CALLERS names */
+ if (stop_at > VG_N_SUPP_CALLERS) stop_at = VG_N_SUPP_CALLERS;
vg_assert(stop_at > 0);
|
|
From: Nicholas N. <nj...@ca...> - 2004-11-18 12:48:21
|
CVS commit by nethercote:
Generalised the reg test script again: replaced the "cpu_test" line,
which caused the test to be skipped if the CPU type wasn't appropriate,
with a "prereq" line, which specifies a command that must succeed before
the test is run.
M +1 -1 addrcheck/tests/x86/insn_cmov.vgtest 1.2
M +1 -1 addrcheck/tests/x86/insn_fpu.vgtest 1.2
M +1 -1 addrcheck/tests/x86/insn_mmx.vgtest 1.2
M +1 -1 addrcheck/tests/x86/insn_mmxext.vgtest 1.2
M +1 -1 addrcheck/tests/x86/insn_sse.vgtest 1.2
M +1 -1 addrcheck/tests/x86/insn_sse2.vgtest 1.2
M +0 -1 cachegrind/tests/x86/fpu-28-108.vgtest 1.3
M +1 -1 cachegrind/tests/x86/insn_cmov.vgtest 1.4
M +1 -1 cachegrind/tests/x86/insn_fpu.vgtest 1.4
M +1 -1 cachegrind/tests/x86/insn_mmx.vgtest 1.4
M +1 -1 cachegrind/tests/x86/insn_mmxext.vgtest 1.4
M +1 -1 cachegrind/tests/x86/insn_sse.vgtest 1.4
M +1 -1 cachegrind/tests/x86/insn_sse2.vgtest 1.4
M +1 -1 helgrind/tests/x86/insn_cmov.vgtest 1.2
M +1 -1 helgrind/tests/x86/insn_fpu.vgtest 1.2
M +1 -1 helgrind/tests/x86/insn_mmx.vgtest 1.2
M +1 -1 helgrind/tests/x86/insn_mmxext.vgtest 1.2
M +1 -1 helgrind/tests/x86/insn_sse.vgtest 1.2
M +1 -1 helgrind/tests/x86/insn_sse2.vgtest 1.2
M +1 -1 memcheck/tests/x86/insn_cmov.vgtest 1.2
M +1 -1 memcheck/tests/x86/insn_fpu.vgtest 1.2
M +1 -1 memcheck/tests/x86/insn_mmx.vgtest 1.2
M +1 -1 memcheck/tests/x86/insn_mmxext.vgtest 1.2
M +1 -1 memcheck/tests/x86/insn_sse.vgtest 1.2
M +1 -1 memcheck/tests/x86/insn_sse2.vgtest 1.2
M +1 -1 none/tests/x86/insn_cmov.vgtest 1.2
M +1 -1 none/tests/x86/insn_fpu.vgtest 1.2
M +1 -1 none/tests/x86/insn_mmx.vgtest 1.2
M +1 -1 none/tests/x86/insn_mmxext.vgtest 1.2
M +1 -1 none/tests/x86/insn_sse.vgtest 1.2
M +1 -1 none/tests/x86/insn_sse2.vgtest 1.2
M +1 -2 tests/cputest.c 1.5
M +11 -8 tests/vg_regtest.in 1.25
--- valgrind/addrcheck/tests/x86/insn_cmov.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_cmov
-cpu_test: x86-cmov
+prereq: ../../../tests/cputest x86-cmov
--- valgrind/addrcheck/tests/x86/insn_fpu.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_fpu
-cpu_test: x86-fpu
+prereq: ../../../tests/cputest x86-fpu
--- valgrind/addrcheck/tests/x86/insn_mmx.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_mmx
-cpu_test: x86-mmx
+prereq: ../../../tests/cputest x86-mmx
--- valgrind/addrcheck/tests/x86/insn_mmxext.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_mmxext
-cpu_test: x86-mmxext
+prereq: ../../../tests/cputest x86-mmxext
--- valgrind/addrcheck/tests/x86/insn_sse.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_sse
-cpu_test: x86-sse
+prereq: ../../../tests/cputest x86-sse
--- valgrind/addrcheck/tests/x86/insn_sse2.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_sse2
-cpu_test: x86-sse2
+prereq: ../../../tests/cputest x86-sse2
--- valgrind/cachegrind/tests/x86/fpu-28-108.vgtest #1.2:1.3
@@ -1,3 +1,2 @@
prog: fpu-28-108
cleanup: rm cachegrind.out.*
-cpu_test: x86
--- valgrind/cachegrind/tests/x86/insn_cmov.vgtest #1.3:1.4
@@ -1,4 +1,4 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_cmov
-cpu_test: x86-cmov
+prereq: ../../../tests/cputest x86-cmov
cleanup: rm cachegrind.out.*
--- valgrind/cachegrind/tests/x86/insn_fpu.vgtest #1.3:1.4
@@ -1,4 +1,4 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_fpu
-cpu_test: x86-fpu
+prereq: ../../../tests/cputest x86-fpu
cleanup: rm cachegrind.out.*
--- valgrind/cachegrind/tests/x86/insn_mmx.vgtest #1.3:1.4
@@ -1,4 +1,4 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_mmx
-cpu_test: x86-mmx
+prereq: ../../../tests/cputest x86-mmx
cleanup: rm cachegrind.out.*
--- valgrind/cachegrind/tests/x86/insn_mmxext.vgtest #1.3:1.4
@@ -1,4 +1,4 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_mmxext
-cpu_test: x86-mmxext
+prereq: ../../../tests/cputest x86-mmxext
cleanup: rm cachegrind.out.*
--- valgrind/cachegrind/tests/x86/insn_sse.vgtest #1.3:1.4
@@ -1,4 +1,4 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_sse
-cpu_test: x86-sse
+prereq: ../../../tests/cputest x86-sse
cleanup: rm cachegrind.out.*
--- valgrind/cachegrind/tests/x86/insn_sse2.vgtest #1.3:1.4
@@ -1,4 +1,4 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_sse2
-cpu_test: x86-sse2
+prereq: ../../../tests/cputest x86-sse2
cleanup: rm cachegrind.out.*
--- valgrind/helgrind/tests/x86/insn_cmov.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_cmov
-cpu_test: x86-cmov
+prereq: ../../../tests/cputest x86-cmov
--- valgrind/helgrind/tests/x86/insn_fpu.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_fpu
-cpu_test: x86-fpu
+prereq: ../../../tests/cputest x86-fpu
--- valgrind/helgrind/tests/x86/insn_mmx.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_mmx
-cpu_test: x86-mmx
+prereq: ../../../tests/cputest x86-mmx
--- valgrind/helgrind/tests/x86/insn_mmxext.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_mmxext
-cpu_test: x86-mmxext
+prereq: ../../../tests/cputest x86-mmxext
--- valgrind/helgrind/tests/x86/insn_sse.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_sse
-cpu_test: x86-sse
+prereq: ../../../tests/cputest x86-sse
--- valgrind/helgrind/tests/x86/insn_sse2.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_sse2
-cpu_test: x86-sse2
+prereq: ../../../tests/cputest x86-sse2
--- valgrind/memcheck/tests/x86/insn_cmov.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_cmov
-cpu_test: x86-cmov
+prereq: ../../../tests/cputest x86-cmov
--- valgrind/memcheck/tests/x86/insn_fpu.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_fpu
-cpu_test: x86-fpu
+prereq: ../../../tests/cputest x86-fpu
--- valgrind/memcheck/tests/x86/insn_mmx.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_mmx
-cpu_test: x86-mmx
+prereq: ../../../tests/cputest x86-mmx
--- valgrind/memcheck/tests/x86/insn_mmxext.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_mmxext
-cpu_test: x86-mmxext
+prereq: ../../../tests/cputest x86-mmxext
--- valgrind/memcheck/tests/x86/insn_sse.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_sse
-cpu_test: x86-sse
+prereq: ../../../tests/cputest x86-sse
--- valgrind/memcheck/tests/x86/insn_sse2.vgtest #1.1:1.2
@@ -1,3 +1,3 @@
vgopts: -q
prog: ../../../none/tests/x86/insn_sse2
-cpu_test: x86-sse2
+prereq: ../../../tests/cputest x86-sse2
--- valgrind/none/tests/x86/insn_cmov.vgtest #1.1:1.2
@@ -1,2 +1,2 @@
prog: insn_cmov
-cpu_test: x86-cmov
+prereq: ../../../tests/cputest x86-cmov
--- valgrind/none/tests/x86/insn_fpu.vgtest #1.1:1.2
@@ -1,2 +1,2 @@
prog: insn_fpu
-cpu_test: x86-fpu
+prereq: ../../../tests/cputest x86-fpu
--- valgrind/none/tests/x86/insn_mmx.vgtest #1.1:1.2
@@ -1,2 +1,2 @@
prog: insn_mmx
-cpu_test: x86-mmx
+prereq: ../../../tests/cputest x86-mmx
--- valgrind/none/tests/x86/insn_mmxext.vgtest #1.1:1.2
@@ -1,2 +1,2 @@
prog: insn_mmxext
-cpu_test: x86-mmxext
+prereq: ../../../tests/cputest x86-mmxext
--- valgrind/none/tests/x86/insn_sse.vgtest #1.1:1.2
@@ -1,2 +1,2 @@
prog: insn_sse
-cpu_test: x86-sse
+prereq: ../../../tests/cputest x86-sse
--- valgrind/none/tests/x86/insn_sse2.vgtest #1.1:1.2
@@ -1,2 +1,2 @@
prog: insn_sse2
-cpu_test: x86-sse2
+prereq: ../../../tests/cputest x86-sse2
--- valgrind/tests/cputest.c #1.4:1.5
@@ -22,6 +22,5 @@ static int go(char* cpu)
if ( strcmp( cpu, "x86" ) == 0 ) {
- level = 1;
- mask = 1 << 0;
+ return 0;
} else if ( strcmp( cpu, "x86-fpu" ) == 0 ) {
level = 1;
--- valgrind/tests/vg_regtest.in #1.24:1.25
@@ -50,5 +50,5 @@
# - stdout_filter: <filter to run stdout through> (default: none)
# - stderr_filter: <filter to run stderr through> (default: ./filter_stderr)
-# - cpu_test: <cpu feature required for test> (default: none)
+# - prereq: <prerequisite command> (default: none)
# - cleanup: <post-test cleanup cmd to run> (default: none)
#
@@ -60,4 +60,7 @@
# stderr (filtered) is kept in <test>.stderr.exp[0-9]?.
#
+# The prerequisite command, if present, must return 0 otherwise the test is
+# skipped.
+#
# If results don't match, the output can be found in <test>.std<strm>.out,
# and the diff between expected and actual in <test>.std<strm>.diff[0-9]?.
@@ -83,5 +86,5 @@
my $stdout_filter; # filter program to run stdout results file through
my $stderr_filter; # filter program to run stderr results file through
-my $cpu_test; # cpu feature to check for before running test
+my $prereq; # prerequisite test to satisfy before running test
my $cleanup; # cleanup command to run
@@ -170,5 +173,5 @@
# Defaults.
- ($vgopts, $prog, $args, $stdout_filter, $stderr_filter, $cpu_test, $cleanup)
+ ($vgopts, $prog, $args, $stdout_filter, $stderr_filter, $prereq, $cleanup)
= ("", undef, "", undef, undef, undef, undef);
@@ -189,6 +192,6 @@
} elsif ($line =~ /^\s*stderr_filter:\s*(.*)$/) {
$stderr_filter = validate_program(".", $1, 1, 1);
- } elsif ($line =~ /^\s*cpu_test:\s*(.*)$/) {
- $cpu_test = $1;
+ } elsif ($line =~ /^\s*prereq:\s*(.*)$/) {
+ $prereq = $1;
} elsif ($line =~ /^\s*cleanup:\s*(.*)$/) {
$cleanup = $1;
@@ -264,7 +267,7 @@
read_vgtest_file($vgtest);
- if (defined $cpu_test) {
- if (system("$tests_dir/tests/cputest $cpu_test") != 0) {
- printf("%-16s (cpu_test failed, skipping)\n", "$name:");
+ if (defined $prereq) {
+ if (system("$prereq") != 0) {
+ printf("%-16s (skipping, prereq failed: $prereq)\n", "$name:");
return;
}
|
|
From: Nicholas N. <nj...@ca...> - 2004-11-18 12:45:55
|
CVS commit by nethercote:
Replace magic number with proper constant.
M +2 -1 vg_errcontext.c 1.65
--- valgrind/coregrind/vg_errcontext.c #1.64:1.65
@@ -338,5 +338,6 @@ static void gen_suppression(Error* err)
Int stop_at = VG_(clo_backtrace_size);
- if (stop_at > 4) stop_at = 4; /* At most four names */
+ /* At most VG_N_SUPP_CALLERS names */
+ if (stop_at > VG_N_SUPP_CALLERS) stop_at = VG_N_SUPP_CALLERS;
vg_assert(stop_at > 0);
|
|
From: Josef W. <Jos...@gm...> - 2004-11-18 12:43:51
|
On Thursday 18 November 2004 11:58, you wrote:
> On Thu, 18 Nov 2004, Josef Weidendorfer wrote:
> > We simply could change the include path base in valgrind.pc.in (line4)
> > into includedir=@includedir@/valgrind
> > leading to correct paths for CFLAGS. But this is a source incompatible
> > change for external tools which used valgrind.pc before. I don't know if
> > there are such tools, and I never used it,
>
> I think it's safe to assume that Callgrind is the only external tool worth
> worrying about, I'm not aware of any others that are publically
> distributed.
> Perhaps the version check is best? It seems like changing the include
> path base in valgrind.pc.in is the right thing to do. If you are happy
Yes.
> with that, let me know, and I will change valgrind.pc.in.
Ok, as tool.h directly includes other VG headers, $PREFIX/include/valgrind has
to be in the include path. So yes, please change line 4 in valgrind.pc.in to
includedir=@includedir@/valgrind
> > BTW: tool.h now also needs vki.h, which is never installed.
>
> Hmm, any idea why? include/linux/Makefile.am has an "incincdir" line,
> just like the other Makefile.am files...
I was wrong. But the path was missing in valgrind.pc.in.
Please also change the CFLAGS line in valgrind.pc.in to include VG_OS:
Cflags: -I${includedir} -I${includedir}/@VG_ARCH@ -I${includedir}/@VG_
PLATFORM@ -I${includedir}/@VG_OS@
Hmm. The Cflags line in valgrind.pc.in is for CFLAGS to use for VG tool
compilation. Perhaps it makes sense to also add
Cflags: ... @ARCH_TOOL_AM_CFLAGS@
And could you please increment VG_CORE_INTERFACE_MAJOR_VERSION to 7?
The compiler complains about changed prototypes (e.g. UInt* => UWord*).
Thanks,
Josef
>
> N
|
|
From: Tom H. <th...@cy...> - 2004-11-18 12:37:07
|
In message <419...@mx...>
Richard van der Hoff <ric...@mx...> wrote:
> The best way to fix this seems to be to make sprintf reentrant;
> attached is a patch to do so, using a nested function - which is of
> course a gcc-only extension. Is introducing a dependency on gcc a
> problem, or do we rely on gcc anyway? If the former, let me know, and
> I'll submit an alternative solution.
I did take all the existing nested functions out a while back...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|