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
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(14) |
2
(4) |
3
(12) |
|
4
(10) |
5
(5) |
6
(17) |
7
(3) |
8
(6) |
9
(4) |
10
|
|
11
(1) |
12
(8) |
13
(16) |
14
(14) |
15
(2) |
16
|
17
(3) |
|
18
(1) |
19
(6) |
20
(2) |
21
(5) |
22
(1) |
23
(2) |
24
(6) |
|
25
(2) |
26
(3) |
27
(2) |
28
(10) |
29
(5) |
30
(5) |
|
|
From: Tom H. <to...@co...> - 2006-06-13 17:49:31
|
In message <Pin...@pe...>
Michael E Locasto <me...@co...> wrote:
> On Tue, 13 Jun 2006, Eric Li wrote:
>
> > Actually, what I meant was instructions for writing a new Valgrind tool.
>
> http://www.valgrind.org/docs/manual/writing-tools.html
The instructions are generally fine, but 4.2.5 is assuming you are
working with a source checkout and developing a tool that is part of
valgrind itself.
It's a bit confusing because 4.2.4 suggests that a normal source
release would work.
There should probably be separate instructions for developing a
separate tool that wouldn't be part of the valgrind build process
and would build against a source release.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Michael E L. <me...@co...> - 2006-06-13 17:14:34
|
On Tue, 13 Jun 2006, Eric Li wrote: > Actually, what I meant was instructions for writing a new Valgrind tool. http://www.valgrind.org/docs/manual/writing-tools.html Cheers, Michael |
|
From: Johannes B. <joh...@si...> - 2006-06-13 16:28:13
|
> The valgrind version is 3.1.1-Debian, kernel is 2.6.17-rc5.=20 I'll verify against 3.2.0 and come back with that, sorry. johannes |
|
From: Johannes B. <joh...@si...> - 2006-06-13 16:27:23
|
On Tue, 2006-06-13 at 18:05 +0200, Johannes Berg wrote:
> This patch allows the lwsync instruction ("lightweight sync") by
> treating it the same as a simple sync ("heavyweight sync"). At least
> then my programs aren't killed with SIGILL any more :)
Never mind, I see this was added to 3.2 already. Sorry for not checking
earlier, I was using the debian package.
johannes
|
|
From: Tom H. <to...@co...> - 2006-06-13 16:26:12
|
In message <1150201687.9208.36.camel@johannes>
Johannes Berg <joh...@si...> wrote:
> This patch allows the lwsync instruction ("lightweight sync") by
> treating it the same as a simple sync ("heavyweight sync"). At least
> then my programs aren't killed with SIGILL any more :)
It's a good idea to put things like this on the bug tracker - it
minimises the chance of them getting forgotten.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Johannes B. <joh...@si...> - 2006-06-13 16:23:36
|
I have a trivial test program that looks like this:
#define GC_THREADS 1
#include <signal.h>
#include <gc.h>
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
static void *thr(void *n)
{
int x;
stack_t st;
st.ss_flags = 0;
st.ss_size = 1024*1024;
st.ss_sp = calloc(st.ss_size, 1);
fprintf(stderr,"alternate stack 0x%x\n", st.ss_sp);
sigaltstack(&st, (stack_t*)st.ss_sp);
fprintf(stderr,"thr: stack base is 0x%X\n", (int)&x);
while (1) {
sleep(1);
fprintf(stderr, "thread executing\n");
GC_malloc(100);
}
return NULL;
}
int main()
{
int x = 0;
void *p;
{
size_t size;
void *sstart;
pthread_attr_t attr;
pthread_getattr_np (pthread_self (), &attr);
pthread_attr_getstack (&attr, &sstart, &size);
fprintf (stderr,"stackbottom pth is: %p\n", (char*)sstart + size);
GC_stackbottom = (char*)sstart + size;
}
{
int stack_bottom = (int)&x;
stack_bottom += 4095;
stack_bottom &= ~4095;
fprintf (stderr,"stackbottom is: %p\n", (char*)stack_bottom);
GC_stackbottom = (char*)stack_bottom;
}
GC_INIT();
p = GC_malloc(100);
GC_stop_world();
GC_start_world();
p = GC_malloc(100);
pthread_t t;
pthread_create(&t, NULL, thr, NULL);
pthread_create(&t, NULL, thr, NULL);
sleep(2);
GC_stop_world();
GC_start_world();
sleep(2);
return 0;
}
I'm linking it against libmonogc as shipped in mono, as such:
cc -o test test.c -lmonogc -I /var/tmp/mono-new/mono-1.1.13.6/libgc/include/ -L /var/tmp/mono-new/mono-1.1.13.6/libgc/.libs/ -lpthread
Then I run it on my ppc64 machine with two dual-core CPUs, so all 3
threads are actually executing in parallel. Every once a while, it'll
crash with the trace below.
The valgrind version is 3.1.1-Debian, kernel is 2.6.17-rc5.
==22710== Nulgrind, a binary JIT-compiler.
==22710== Copyright (C) 2002-2005, and GNU GPL'd, by Nicholas Nethercote.
==22710== Using LibVEX rev 1575, a library for dynamic binary translation.
==22710== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==22710== Using valgrind-3.1.1-Debian, a dynamic binary instrumentation framework.
==22710== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==22710== For more details, rerun with: -v
==22710==
--22710-- Max kernel-supported signal is 64
--22710-- signal 11 arrived ... si_code=1, EIP=0x410BE24, eip=0x478752C
--22710-- SIGSEGV: si_code=1 faultaddr=0xFEC14F40 tid=1 ESP=0xFEC14F40 seg=0xFE416000-0xFEC14FFF
--22710-- -> extended stack base to 0xFEC14000
++22710++ sys_sigaction: sigNo 32, new 0xFEC152B8, old 0x0, new flags 0x0
++22710++ sys_sigaction: sigNo 33, new 0xFEC152B8, old 0x0, new flags 0x0
++22710++ sys_sigaction: sigNo 34, new 0xFEC152B8, old 0x0, new flags 0x0
++22710++ do_setmask: tid = 1 how = 0 (SIG_BLOCK), set = 0xFEC153FC 0000000080000000
++22710++ do_setmask: tid = 1 how = 1 (SIG_UNBLOCK), set = 0xFEC153FC 0000000100000000
--22710-- signal 11 arrived ... si_code=1, EIP=0xFE59694, eip=0x47CFAA8
--22710-- SIGSEGV: si_code=1 faultaddr=0xFEC13040 tid=1 ESP=0xFEC13040 seg=0xFE416000-0xFEC13FFF
--22710-- -> extended stack base to 0xFEC13000
--22710-- signal 11 arrived ... si_code=1, EIP=0xFE59694, eip=0x47D05BC
--22710-- SIGSEGV: si_code=1 faultaddr=0xFEC109F0 tid=1 ESP=0xFEC109F0 seg=0xFE416000-0xFEC12FFF
--22710-- -> extended stack base to 0xFEC10000
stackbottom pth is: 0xfec16000
stackbottom is: 0xfec16000
++22710++ sys_sigaction: sigNo 30, new 0xFEC15398, old 0x0, new flags 0x10000000
++22710++ sys_sigaction: sigNo 24, new 0xFEC15398, old 0x0, new flags 0x10000000
++22711++ do_setmask: tid = 2 how = 2 (SIG_SETMASK), set = 0x10037EA0 FFFFFFFEFFFFFFEF
++22710++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x0 0000000000000000
++22710++ oldset=0xFEC1562C 0000000080000000
++22710++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x0 0000000000000000
++22710++ oldset=0xFEC15588 0000000080000000
++22712++ do_setmask: tid = 3 how = 2 (SIG_SETMASK), set = 0x10038CF8 0000000080000000
alternate stack 0x5a11008
----22711-- 22710-- kill: sent signal 32 to pid 22710
async_signalhandler ( 32 ) for tid 1 info 0
--22710-- Async handler got signal 32 for tid 1 info 0
--22710-- delivering signal 32 (SIGRT0):0 to thread 1
--22710-- push_signal_frame (thread 1): signal 32
--22710-- vg_pop_signal_frame (thread 1): isRT=0 valid magic; EIP=0xFF75FB0
++22710++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x0 0000000000000000
++22710++ oldset=0xFEC1562C 0000000080000000
++22710++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x0 0000000000000000
++22710++ oldset=0xFEC15588 0000000080000000
++22712++ sys_sigaltstack: tid 3, ss 0x5A10ECC, oss 0x5A11008 (current SP 0x5A10EC0)
thr: stack base is 0x5A10EC8
++22712++ do_setmask: tid = 3 how = 0 (SIG_BLOCK), set = 0x5A10D00 0000000000010000
++22712++ oldset=0x5A10D80 0000000080000000
++22712++ sys_sigaction: sigNo 17, new 0x0, old 0x5A10B74, new flags 0x0
++22712++ do_setmask: tid = 3 how = 2 (SIG_SETMASK), set = 0x5A10D80 0000000080000000
++22713++ do_setmask: tid = 4 how = 2 (SIG_SETMASK), set = 0x100398D8 0000000080000000
alternate stack 0x656e008
--22711-- kill: sent signal 32 to pid 22710
++22713++ sys_sigaltstack: tid 4, ss 0x656DECC, oss 0x656E008 (current SP 0x656DEC0)
thr: stack base is 0x656DEC8
++22713++ do_setmask: tid = 4 how = 0 (SIG_BLOCK), set = 0x656DD00 0000000000010000
++22713++ oldset=0x656DD80 0000000080000000
++22713++ sys_sigaction: sigNo 17, new 0x0, old 0x656DB74, new flags 0x0
++22713++ do_setmask: tid = 4 how = 2 (SIG_SETMASK), set = 0x656DD80 0000000080000000
--22710-- async_signalhandler ( 32 ) for tid 1 info 0
--22710-- Async handler got signal 32 for tid 1 info 0
--22710-- delivering signal 32 (SIGRT0):0 to thread 1
--22710-- push_signal_frame (thread 1): signal 32
--22710-- vg_pop_signal_frame (thread 1): isRT=0 valid magic; EIP=0xFF75FB0
++22710++ do_setmask: tid = 1 how = 0 (SIG_BLOCK), set = 0xFEC15560 0000000000010000
++22710++ oldset=0xFEC155E0 0000000080000000
++22710++ sys_sigaction: sigNo 17, new 0x0, old 0xFEC153D4, new flags 0x0
++22710++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0xFEC155E0 0000000080000000
thread executing
++22712++ do_setmask: tid = 3 how = 0 (SIG_BLOCK), set = 0x5A10D00 0000000000010000
++22712++ oldset=0x5A10D80 0000000080000000
++22712++ sys_sigaction: sigNo 17, new 0x0, old 0x5A10B74, new flags 0x0
++22712++ do_setmask: tid = 3 how = 2 (SIG_SETMASK), set = 0x5A10D80 0000000080000000
thread executing
++22713++ do_setmask: tid = 4 how = 0 (SIG_BLOCK), set = 0x656DD00 0000000000010000
++22713++ oldset=0x656DD80 0000000080000000
++22713++ sys_sigaction: sigNo 17, new 0x0, old 0x656DB74, new flags 0x0
++22713++ do_setmask: tid = 4 how = 2 (SIG_SETMASK), set = 0x656DD80 0000000080000000
thread executing
++22712++ do_setmask: tid = 3 how = 0 (SIG_BLOCK), set = 0x5A10D00 0000000000010000
++22712++ oldset=0x5A10D80 0000000080000000
++22712++ sys_sigaction: sigNo 17, new 0x0, old 0x5A10B74, new flags 0x0
++22712++ do_setmask: tid = 3 how = 2 (SIG_SETMASK), set = 0x5A10D80 0000000080000000
thread executing
++22713++ do_setmask: tid = 4 how = 0 (SIG_BLOCK), set = 0x656DD00 0000000000010000
++22713++ oldset=0x656DD80 0000000080000000
++22713++ sys_sigaction: sigNo 17, new 0x0, old 0x656DB74, new flags 0x0
++22713++ do_setmask: tid = 4 how = 2 (SIG_SETMASK), set = 0x656DD80 0000000080000000
--22710-- kill: sent signal 30 to pid 22712
--22710-- kill: sent signal 30 to pid 22713
--22713-- async_signalhandler ( 30 ) for tid 4 info 0
--22712-- async_signalhandler ( 30 ) for tid 3 info 0
++22710++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x0 0000000000000000
++22710++ oldset=0xFEC15618 0000000080000000
--22712-- Async handler got signal 30 for tid 3 info 0
--22712-- delivering signal 30 (SIGPWR):0 to thread 3
--22712-- push_signal_frame (thread 3): signal 30
--22713-- Async handler got signal 30 for tid 4 info 0
--22713-- delivering signal 30 (SIGPWR):0 to thread 4
--22713-- push_signal_frame (thread 4): signal 30
----22710-- async_signalhandler ( 32 ) for tid 1 info 0
22711-- kill: sent signal 32 to pid 22710
--22710-- Async handler got signal 32 for tid 1 info 0
--22710-- delivering signal 32 (SIGRT0):0 to thread 1
--22710-- push_signal_frame (thread 1): signal 32
--22710-- vg_pop_signal_frame (thread 1): isRT=0 valid magic; EIP=0xFF75FB0
++22710++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x0 0000000000000000
++22710++ oldset=0xFEC15618 0000000080000000
----22710-- async_signalhandler ( 32 ) for tid 1 info 0
22711-- kill: sent signal 32 to pid 22710
--22710-- Async handler got signal 32 for tid 1 info 0
--22710-- delivering signal 32 (SIGRT0):0 to thread 1
--22710-- push_signal_frame (thread 1): signal 32
--22710-- vg_pop_signal_frame (thread 1): isRT=0 valid magic; EIP=0xFF75FB0
--22710-- --22712-- async_signalhandler ( 24 ) for tid 3 info 0
kill: sent signal 24 to pid 22712
--22710-- --22713-- async_signalhandler ( 24 ) for tid 4 info 0
kill: sent signal 24 to pid 22713
++22710++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x0 0000000000000000
++22710++ oldset=0xFEC15628 0000000080000000
--22713-- Async handler got signal 24 for tid 4 info 0
--22713-- delivering signal 24 (SIGXCPU):0 to thread 4
--22713-- push_signal_frame (thread 4): signal 24
--22713-- vg_pop_signal_frame (thread 4): isRT=0 valid magic; EIP=0xFE468B4
--22712-- Async handler got signal 24 for tid 3 info 0
--22712-- delivering signal 24 (SIGXCPU):0 to thread 3
--22712-- push_signal_frame (thread 3): signal 24
--22712-- vg_pop_signal_frame (thread 3): isRT=0 valid magic; EIP=0xFE468B4
--22712-- vg_pop_signal_frame (thread 3): isRT=0 valid magic; EIP=0xFEAD124
thread executing
--22713-- vg_pop_signal_frame (thread 4): isRT=0 valid magic; EIP=0xFEAD124
++22713++ do_setmask: tid = 4 how = 2 (SIG_SETMASK), set = 0x0 0000000000000000
++22713++ oldset=0x656B718 0000000080000000
--22711-- kill: sent signal 32 to pid 22710
--22710-- async_signalhandler ( 32 ) for tid 1 info 0
----22712-- kill: sent signal 32 to pid 22713
22713-- async_signalhandler ( 32 ) for tid 4 info 0
++22712++ do_setmask: tid = 3 how = 0 (SIG_BLOCK), set = 0x5A10D00 0000000000010000
++22712++ oldset=0x5A10D80 0000000080000000
++22712++ sys_sigaction: sigNo 17, new 0x0, old 0x5A10B74, new flags 0x0
++22712++ do_setmask: tid = 3 how = 2 (SIG_SETMASK), set = 0x5A10D80 0000000080000000
--22713-- Async handler got signal 32 for tid 4 info 0
--22713-- delivering signal 32 (SIGRT0):0 to thread 4
--22713-- push_signal_frame (thread 4): signal 32
--22713-- vg_pop_signal_frame (thread 4): isRT=0 valid magic; EIP=0xFF75FB0
thread executing
++22713++ do_setmask: tid = 4 how = 0 (SIG_BLOCK), set = 0x656DD00 0000000000010000
++22713++ oldset=0x656DD80 0000000080000000
++22713++ sys_sigaction: sigNo 17, new 0x0, old 0x656DB74, new flags 0x0
++22713++ do_setmask: tid = 4 how = 2 (SIG_SETMASK), set = 0x656DD80 0000000080000000
--22710-- Async handler got signal 32 for tid 1 info 0
--22710-- delivering signal 32 (SIGRT0):0 to thread 1
--22710-- push_signal_frame (thread 1): signal 32
--22710-- vg_pop_signal_frame (thread 1): isRT=0 valid magic; EIP=0xFF75FB0
++22710++ do_setmask: tid = 1 how = 0 (SIG_BLOCK), set = 0xFEC15560 0000000000010000
++22710++ oldset=0xFEC155E0 0000000080000000
++22710++ sys_sigaction: sigNo 17, new 0x0, old 0xFEC153D4, new flags 0x0
++22710++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0xFEC155E0 0000000080000000
thread executing
++22712++ do_setmask: tid = 3 how = 0 (SIG_BLOCK), set = 0x5A10D00 0000000000010000
++22712++ oldset=0x5A10D80 0000000080000000
++22712++ sys_sigaction: sigNo 17, new 0x0, old 0x5A10B74, new flags 0x0
++22712++ do_setmask: tid = 3 how = 2 (SIG_SETMASK), set = 0x5A10D80 0000000080000000
thread executing
++22713++ do_setmask: tid = 4 how = 0 (SIG_BLOCK), set = 0x656DD00 0000000000010000
++22713++ oldset=0x656DD80 0000000080000000
++22713++ sys_sigaction: sigNo 17, new 0x0, old 0x656DB74, new flags 0x0
++22713++ do_setmask: tid = 4 how = 2 (SIG_SETMASK), set = 0x656DD80 0000000080000000
thread executing
++22710++ do_setmask: tid = 1 how = 2 (SIG_SETMASK), set = 0x0 0000000000000000
++22710++ oldset=0xFEC15608 0000000080000000
--22711-- --kill: sent signal 33 to pid 22713
22713-- async_signalhandler ( 33 ) for tid 4 info 0
valgrind: m_signals.c:1418 (async_signalhandler): Assertion 'tst->status == VgTs_WaitSys' failed.
--22711-- kill: sent signal 33 to pid 22712
==22713== at 0x700507B4: report_and_quit (m_libcassert.c:122)
==22713== by 0x70050A34: vgPlain_assert_fail (m_libcassert.c:185)
==22713== by 0x7000C48C: async_signalhandler (m_signals.c:1418)
==22713== by 0x10037C: ???
==22713== by 0x7005302C: vgPlain_gettid (m_libcproc.c:334)
==22713== by 0x70050EE4: vgPlain_read (m_libcfile.c:98)
==22713== by 0x700265C0: vgModuleLocal_sema_down (sema.c:71)
==22713== by 0x70023B9C: vgPlain_set_running (scheduler.c:200)
==22713== by 0x7003A5B0: vgPlain_client_syscall (syswrap-main.c:751)
==22713== by 0x70024FD0: handle_syscall (scheduler.c:623)
==22713== by 0x7002544C: vgPlain_scheduler (scheduler.c:726)
==22713== by 0x7003BB38: thread_wrapper (syswrap-linux.c:86)
==22713== by 0x7003BC9C: run_a_thread_NORETURN (syswrap-linux.c:119)
==22713== by 0x7003BE14: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:206)
==22713== by 0x70048820: (within /usr/lib/valgrind/ppc32-linux/none)
sched status:
running_tid=2
Thread 1: status = VgTs_WaitSys
==22713== at 0xFF75FB0: __pthread_sigsuspend (pt-sigsuspend.c:54)
==22713== by 0xFF751E4: __pthread_wait_for_restart_signal (pthread.c:1216)
==22713== by 0xFF752B8: pthread_onexit_process (restart.h:34)
==22713== by 0xFE49340: exit (exit.c:54)
==22713== by 0xFE2FF74: (below main) (libc-start.c:240)
Thread 2: status = VgTs_Runnable
==22713== at 0xFF7B38C: waitpid (in /usr/lib/debug/libpthread-0.10.so)
==22713== by 0xFF73A8C: __pthread_manager (manager.c:1069)
Thread 3: status = VgTs_Runnable
==22713== at 0xFEAD124: nanosleep (in /usr/lib/debug/libc-2.3.6.so)
==22713== by 0xFEACEFC: sleep (sleep.c:138)
==22713== by 0x10001088: thr (in /tmp/test)
==22713== by 0x10009D84: GC_start_routine (pthread_support.c:1331)
==22713== by 0xFF72F70: pthread_start_thread (manager.c:310)
==22713== by 0xFEE1FC0: clone (clone.S:118)
Thread 4: status = VgTs_Runnable
==22713== at 0xFED0ED8: write (in /usr/lib/debug/libc-2.3.6.so)
==22713== by 0xFE810D4: _IO_file_write@@GLIBC_2.1 (fileops.c:1260)
==22713== by 0xFE7F64C: new_do_write (fileops.c:514)
==22713== by 0xFE813A0: _IO_file_xsputn@@GLIBC_2.1 (fileops.c:1350)
==22713== by 0xFE59808: vfprintf (vfprintf.c:2144)
==22713== by 0xFE61B5C: fprintf (fprintf.c:32)
==22713== by 0x100010A4: thr (in /tmp/test)
==22713== by 0x10009D84: GC_start_routine (pthread_support.c:1331)
==22713== by 0xFF72F70: pthread_start_thread (manager.c:310)
==22713== by 0xFEE1FC0: clone (clone.S:118)
Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.
If that doesn't help, please report this bug to: www.valgrind.org
In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using. Thanks.
--22712-- async_signalhandler ( 33 ) for tid 3 info 0
--22711-- async_signalhandler ( 33 ) for tid 2 info 1
--22711-- Async handler got signal 33 for tid 2 info 1
--22711-- delivering signal 33 (SIGRT1):1 to thread 2
--22711-- push_signal_frame (thread 2): signal 33
--22711-- vg_pop_signal_frame (thread 2): isRT=0 valid magic; EIP=0xFF7B3C0
--22711-- poll_signals: got signal 33 for thread 2
--22711-- Polling found signal 33 for tid 2
--22711-- delivering signal 33 (SIGRT1):1 to thread 2
--22711-- push_signal_frame (thread 2): signal 33
--22711-- vg_pop_signal_frame (thread 2): isRT=0 valid magic; EIP=0xFF7B3C0
--22711-- kill: sent signal 32 to pid 22710
--22710-- async_signalhandler ( 32 ) for tid 1 info 0
--22710-- Async handler got signal 32 for tid 1 info 0
--22710-- delivering signal 32 (SIGRT0):0 to thread 1
--22710-- push_signal_frame (thread 1): signal 32
--22710-- vg_pop_signal_frame (thread 1): isRT=0 valid magic; EIP=0xFF75FB0
|
|
From: Johannes B. <joh...@si...> - 2006-06-13 16:06:17
|
This patch allows the lwsync instruction ("lightweight sync") by
treating it the same as a simple sync ("heavyweight sync"). At least
then my programs aren't killed with SIGILL any more :)
Signed-off-by: Johannes Berg <joh...@si...>
--- a/valgrind-3.1.1/VEX/priv/guest-ppc32/toIR.c 2006-03-06 14:41:01.000000000 +0100
+++ b/valgrind-3.1.1/VEX/priv/guest-ppc32/toIR.c 2006-06-13 14:07:08.521497809 +0200
@@ -3456,8 +3456,9 @@
}
case 0x256: // sync (Synchronize, PPC32 p543)
- if (b11to25 != 0 || b0 != 0) {
- vex_printf("dis_int_memsync(PPC32)(sync,b11to25|b0)\n");
+ /* treat lwsync the same as just sync */
+ if ((b11to25 != 0 && b11to25 != 0x400) || b0 != 0) {
+ vex_printf("dis_int_memsync(PPC32)(sync,b11to25=%x|b0=%x)\n",b11to25,b0);
return False;
}
DIP("sync\n");
|
|
From: Eric L. <ew...@an...> - 2006-06-13 15:34:34
|
Actually, what I meant was instructions for writing a new Valgrind tool. > On Mon, 12 Jun 2006, Eric Li wrote: > >> Hi, are there updated instructions for building a Valgrind tool >> somewhere? The instructions on the documentations page are out of date, >> e.g. there's no valgrind/autogen.sh or a valgrind/inst dir. > > The README file explains how to build both from a distribution and from a > SVN repository checkout. > > Nick > > |
|
From: Jeffrey S. <fe...@no...> - 2006-06-13 14:09:33
|
On Tue, 2006-06-13 at 09:20 +1000, Nicholas Nethercote wrote: > On Mon, 12 Jun 2006, Jeffrey Stedfast wrote: > > > I just noticed the timestamp format changed somewhere between Valgrind > > 2.4.0 and Valgrind 3.1.0 in the non-xml log output. > > > > The new date format looks like "##:##:##:##.###" > > > > Can anyone tell me what each of these fields are and when the change was > > made? (was it made in 3.0? or just in 3.1?) > > The release notes say it changed in 3.1.0: > > - The --time-stamp option no longer gives an absolute date and time. > It now prints the time elapsed since the program began. > > The manual (section 2.6.2) explains the meaning of the fields. Thanks! I somehow missed it when skimming the manual earlier... Jeff > > Nick -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. fe...@no... - www.novell.com |
|
From: Apostolos M. <apo...@gm...> - 2006-06-13 13:12:30
|
On 6/12/06, Apostolos Manolitzas <apo...@gm...> wrote: > On 6/11/06, Dennis Lubert <pla...@pr...> wrote: > > Am Freitag, den 09.06.2006, 18:05 +0300 schrieb Apostolos Manolitzas: > > > > > BUT the program is not executed with the following error: > > > valgrind --tool=3Dmemcheck --log-file=3D/mnt/ipu/tmp/grind.log ./m= yfile.x -s9 > > > ./nms.imgX =C5=14"t=C4=01_\=C6BX=10=10!0=03=03=03=03=03=03=03=03=03= =03=03=03=03=03=03=03 > > > L//lib/valgrind//ppc32-linux/vgpreload_core.so=B0=C4=01X=CC=01=C4=01Y= t=C4=01Y=04=EC=C0=B4t8Droot@foo:# For a better clarification, I attach the execution of the program with the flags -v -v -d -d. thanks in advanced, Apostolos --371:1:debuglog DebugLog system started by Stage 1, level 2 logging reques= ted --371:1:launcher no tool requested, defaulting to 'memcheck' --371:1:launcher no platform detected, defaulting platform to 'ppc32-linux' --371:1:launcher launching /mnt/ipu/lib/valgrind/ppc32-linux/memcheck --371:1:debuglog DebugLog system started by Stage 2 (main), level 2 logging requested --371:1:main Welcome to Valgrind version 3.2.0 debug logging --371:1:main Checking current stack is plausible --371:1:main Checking initial stack was noted --371:1:main Starting the address space manager --371:2:aspacem sp_at_startup =3D 0x007FFFFCC0 (supplied) --371:2:aspacem minAddr =3D 0x0004000000 (computed) --371:2:aspacem maxAddr =3D 0x007FFFEFFF (computed) --371:2:aspacem cStart =3D 0x0004000000 (computed) --371:2:aspacem vStart =3D 0x0042000000 (computed) --371:2:aspacem suggested_clstack_top =3D 0x007EFFFFFF (computed) --371:2:aspacem <<< SHOW_SEGMENTS: Initial layout (5 segments, 0 segname= s) --371:2:aspacem 0: RSVN 0000000000-0003FFFFFF 64m ----- SmFixed --371:2:aspacem 1: 0004000000-0041FFFFFF 992m --371:2:aspacem 2: RSVN 0042000000-0042000FFF 4096 ----- SmFixed --371:2:aspacem 3: 0042001000-007FFFEFFF 991m --371:2:aspacem 4: RSVN 007FFFF000-00FFFFFFFF 2048m ----- SmFixed --371:2:aspacem >>> --371:2:aspacem Reading /proc/self/maps --371:2:aspacem <<< SHOW_SEGMENTS: With contents of /proc/self/maps (11 segments, 1 segnames) --371:2:aspacem ( 0) /mnt/ipu/lib/valgrind/ppc32-linux/memcheck --371:2:aspacem 0: RSVN 0000000000-0003FFFFFF 64m ----- SmFixed --371:2:aspacem 1: 0004000000-0037FFFFFF 832m --371:2:aspacem 2: FILE 0038000000-0038163FFF 1458176 r-x-- d=3D0x008 i=3D6045873 o=3D0 (0) --371:2:aspacem 3: 0038164000-0038172FFF 61440 --371:2:aspacem 4: FILE 0038173000-0038174FFF 8192 rw--- d=3D0x008 i=3D6045873 o=3D1454080 (0) --371:2:aspacem 5: ANON 0038175000-00388FAFFF 7888896 rwx-- --371:2:aspacem 6: 00388FB000-0041FFFFFF 151m --371:2:aspacem 7: RSVN 0042000000-0042000FFF 4096 ----- SmFixed --371:2:aspacem 8: 0042001000-007FFFEFFF 991m --371:2:aspacem 9: ANON 007FFFF000-007FFFFFFF 4096 rwx-- --371:2:aspacem 10: RSVN 0080000000-00FFFFFFFF 2048m ----- SmFixed --371:2:aspacem >>> --371:1:main Address space manager is running --371:1:main Starting the dynamic memory manager --371:1:mallocfr newSuperblock at 0x42001000 (pszB 1048560) owner VALGRIND/= tool --371:1:main Dynamic memory manager is running --371:1:main Getting stage1's name --371:1:main Get hardware capabilities ... --371:1:main ... arch =3D PPC32, hwcaps =3D ppc32-int-flt-GX --371:1:main Split up command line --371:1:main Preprocess command line opts --371:1:main Loading client --371:1:main Setup client env --371:2:main preload_string: --371:2:main "/mnt/ipu/lib/valgrind/ppc32-linux/vgpreload_core.so:/mnt/ipu/lib/valgrind/= ppc32-linux/vgpreload_memcheck.so" --371:1:main Setup client stack --371:2:main PPC32 cache line size 32 (type 19) --371:2:main PPC32 cache line size 32 (type 20) --371:2:main Client info: initial_IP=3D0x4010A48 initial_SP=3D0x7EFFFCD0 initial_TOC=3D0x0 brk_base=3D0x10011000 --371:1:main Setup client data (brk) segment --371:1:main Setup file descriptors --371:1:main Create fake /proc/<pid>/cmdline --371:1:main Initialise the tool part 1 (pre_clo_init) --371:1:main Print help and quit, if requested --371:1:main Process Valgrind's command line options, setup logging --371:1:mallocfr newSuperblock at 0x42101000 (pszB 1048560) owner VALGRIND/= core --371:1:main Print the preamble... =3D=3D371=3D=3D Memcheck, a memory error detector. =3D=3D371=3D=3D Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et= al. =3D=3D371=3D=3D Using LibVEX rev 1606, a library for dynamic binary transla= tion. =3D=3D371=3D=3D Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. =3D=3D371=3D=3D Using valgrind-3.2.0, a dynamic binary instrumentation fram= ework. =3D=3D371=3D=3D Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et= al. =3D=3D371=3D=3D --371-- Command line --371-- mem_stress.x --371-- 20000 --371-- Startup, with flags: --371-- -v --371-- -v --371-- -d --371-- -d --371-- Contents of /proc/version: --371-- Linux version 2.4.20_mvl31-8270ppu (iple@pclinux) (gcc version 3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-12-24)) #8 Fri Feb 24 10:43:32 EET 2006 --371-- Arch and hwcaps: PPC32, ppc32-int-flt-GX --371-- Valgrind library directory: /mnt/ipu/lib/valgrind --371:1:main ...finished the preamble --371:1:main Initialise the tool part 2 (post_clo_init) --371:1:main Initialise TT/TC --371-- TT/TC: VG_(init_tt_tc) (startup of code management) --371-- TT/TC: cache: 8 sectors of 20127744 bytes each =3D 161021952 total --371-- TT/TC: table: 524168 total entries, max occupancy 419328 (80%) --371:2:transtab cache: 8 sectors of 20127744 bytes each =3D 161021952 to= tal --371:2:transtab table: 524168 total entries, max occupancy 419328 (80%) --371:1:main Initialise redirects --371:1:mallocfr newSuperblock at 0x4227C000 (pszB 1048560) owner VALGRIND/symtab --371:1:main Load initial debug info --371-- Reading syms from /lib/ld-2.3.2.so (0x4000000) --371:2:transtab discard_translations(0x40127E0, 1) req by redir_new_SegInfo(from_addr) --371:2:transtab FAST, ec =3D 36 --371:2:transtab discard_translations(0x3802EDF8, 1) req by redir_new_SegInfo(to_addr) --371:2:transtab FAST, ec =3D 93 --371:2:transtab discard_translations(0x40129B0, 1) req by redir_new_SegInfo(from_addr) --371:2:transtab FAST, ec =3D 37 --371:2:transtab discard_translations(0x3802EDD0, 1) req by redir_new_SegInfo(to_addr) --371:2:transtab FAST, ec =3D 93 --371-- Reading syms from /root/mem_stress.x (0x10000000) --371-- Reading syms from /mnt/ipu/lib/valgrind/ppc32-linux/memcheck (0x38000000) --371-- object doesn't have a dynamic symbol table --371:1:mallocfr newSuperblock at 0x4237C000 (pszB 1048560) owner VALGRIND/symtab --371:1:mallocfr newSuperblock at 0x4247C000 (pszB 1048560) owner VALGRIND/symtab --371:1:mallocfr newSuperblock at 0x4257C000 (pszB 2052080) owner VALGRIND/symtab --371:1:redir transfer ownership V -> C of 0x3802E000 .. 0x3802EFFF --371:1:main Tell tool about initial permissions --371:2:main tell tool about 0004000000-0004016FFF r-x --371:2:main tell tool about 0004026000-0004027FFF rwx --371:2:main tell tool about 0010000000-0010000FFF r-x --371:2:main tell tool about 0010010000-0010010FFF rwx --371:2:main tell tool about 0010011000-0010011FFF rwx --371:2:main tell tool about 003802E000-003802EFFF r-x --371:2:main tell tool about 007EFFF000-007EFFFFFF rwx --371:2:main mark stack inaccessible 007EFFF000-007EFFFCCF --371:1:main Initialise scheduler --371:1:main Initialise thread 1's state --371:1:main Initialise signal management --371:1:main Load suppressions --371-- Reading suppressions file: /mnt/ipu/lib/valgrind/default.supp --371:2:stacks register 0x7EFFF000-0x7EFFFFFF as stack 0 --371:1:main --371:1:main --371:1:aspacem <<< SHOW_SEGMENTS: Memory layout at client startup (26 segments, 3 segnames) --371:1:aspacem ( 0) /mnt/ipu/lib/valgrind/ppc32-linux/memcheck --371:1:aspacem ( 1) /root/mem_stress.x --371:1:aspacem ( 2) /lib/ld-2.3.2.so --371:1:aspacem 0: RSVN 0000000000-0003FFFFFF 64m ----- SmFixed --371:1:aspacem 1: file 0004000000-0004016FFF 94208 r-x-- d=3D0x1F01 i=3D622 o=3D0 (2) --371:1:aspacem 2: 0004017000-0004025FFF 61440 --371:1:aspacem 3: file 0004026000-0004027FFF 8192 rwx-- d=3D0x1F01 i=3D622 o=3D90112 (2) --371:1:aspacem 4: 0004028000-000FFFFFFF 191m --371:1:aspacem 5: file 0010000000-0010000FFF 4096 r-x-- d=3D0x1F01 i=3D1987 o=3D0 (1) --371:1:aspacem 6: 0010001000-001000FFFF 61440 --371:1:aspacem 7: file 0010010000-0010010FFF 4096 rwx-- d=3D0x1F01 i=3D1987 o=3D0 (1) --371:1:aspacem 8: anon 0010011000-0010011FFF 4096 rwx-- --371:1:aspacem 9: RSVN 0010012000-0010810FFF 8384512 ----- SmLower --371:1:aspacem 10: 0010811000-0037FFFFFF 631m --371:1:aspacem 11: FILE 0038000000-003802DFFF 188416 r-x-- d=3D0x008 i=3D6045873 o=3D0 (0) --371:1:aspacem 12: file 003802E000-003802EFFF 4096 r-x-- d=3D0x008 i=3D6045873 o=3D188416 (0) --371:1:aspacem 13: FILE 003802F000-0038163FFF 1265664 r-x-- d=3D0x008 i=3D6045873 o=3D192512 (0) --371:1:aspacem 14: 0038164000-0038172FFF 61440 --371:1:aspacem 15: FILE 0038173000-0038174FFF 8192 rw--- d=3D0x008 i=3D6045873 o=3D1454080 (0) --371:1:aspacem 16: ANON 0038175000-00388FAFFF 7888896 rwx-- --371:1:aspacem 17: 00388FB000-0041FFFFFF 151m --371:1:aspacem 18: RSVN 0042000000-0042000FFF 4096 ----- SmFixed --371:1:aspacem 19: ANON 0042001000-0042788FFF 7897088 rwx-- --371:1:aspacem 20: 0042789000-007E7FFFFF 960m --371:1:aspacem 21: RSVN 007E800000-007EFFEFFF 8384512 ----- SmUpper --371:1:aspacem 22: anon 007EFFF000-007EFFFFFF 4096 rwx-- --371:1:aspacem 23: 007F000000-007FFFEFFF 15m --371:1:aspacem 24: ANON 007FFFF000-007FFFFFFF 4096 rwx-- --371:1:aspacem 25: RSVN 0080000000-00FFFFFFFF 2048m ----- SmFixed --371:1:aspacem >>> --371:1:main --371:1:main --371:1:main Running thread 1 --371:1:syswrap- entering VG_(main_thread_wrapper_NORETURN) --371:1:aspacem allocated thread stack at 0x42789000 size 81920 --371:1:syswrap- run_a_thread_NORETURN(tid=3D1): pre-thread_wrapper --371:1:syswrap- thread_wrapper(tid=3D1): entry --371:1:transtab allocate sector 0 --371-- TT/TC: initialise sector 0 --371:1:mallocfr newSuperblock at 0x43FCF000 (pszB 65520) owner VALGRIND/= ttaux --371:2:transtab discard_translations(0x40273E0, 32) req by scheduler(VEX_TRC_JMP_TINVAL) --371:2:transtab FAST, ec =3D 78 --371:2:transtab discard_translations(0x4027400, 32) req by scheduler(VEX_TRC_JMP_TINVAL) --371:2:transtab FAST, ec =3D 78 --371:2:transtab discard_translations(0x4027440, 32) req by scheduler(VEX_TRC_JMP_TINVAL) --371:2:transtab FAST, ec =3D 78 --371:2:transtab discard_translations(0x4027440, 32) req by scheduler(VEX_TRC_JMP_TINVAL) --371:2:transtab FAST, ec =3D 78 --371:2:transtab discard_translations(0x4027440, 32) req by scheduler(VEX_TRC_JMP_TINVAL) --371:2:transtab FAST, ec =3D 78 --371:2:transtab discard_translations(0x4027440, 32) req by scheduler(VEX_TRC_JMP_TINVAL) --371:2:transtab FAST, ec =3D 78 --371:2:transtab discard_translations(0x4027460, 32) req by scheduler(VEX_TRC_JMP_TINVAL) --371:2:transtab FAST, ec =3D 78 --371:2:transtab discard_translations(0x4027460, 32) req by scheduler(VEX_TRC_JMP_TINVAL) --371:2:transtab FAST, ec =3D 78 --371:2:transtab discard_translations(0x4027460, 32) req by scheduler(VEX_TRC_JMP_TINVAL) --371:2:transtab FAST, ec =3D 78 --371:1:mallocfr newSuperblock at 0x43FDF000 (pszB 262128) owner VALGRIND/exectxt --371:1:mallocfr newSuperblock at 0x4401F000 (pszB 65520) owner VALGRIND/errors --371-- REDIR: 0x40129B0 (strlen) redirected to 0x3802EDD0 (vgPlain_ppc32_linux_REDIR_FOR_strlen) --371-- REDIR: 0x40127E0 (strcmp) redirected to 0x3802EDF8 (vgPlain_ppc32_linux_REDIR_FOR_strcmp) --371:1:signals extending a stack base 0x7EFFF000 down by 4096 --371:2:stacks change stack 0 from 0x7EFFF000-0x7EFFFFFF to 0x7EFFE000-0x7EFFFFFF mem_stress.x |
|
From: Nicholas N. <nj...@cs...> - 2006-06-12 23:24:01
|
On Mon, 12 Jun 2006, Eric Li wrote:
> Are there replacements for the
> --optimise=no
> --instrument=no
> --single-step=yes
> --cleanup=no
> flags in the 3.x.x versions (which are documented online as ways of
> viewing/debugging the IR)? When I tried them, it said those were bad
> options.
Look at the --vex-* options in the output of --help-debug:
--vex-iropt-verbosity 0 .. 9 [0]
--vex-iropt-level 0 .. 2 [2]
--vex-iropt-precise-memory-exns [no]
--vex-iropt-unroll-thresh 0 .. 400 [120]
--vex-guest-max-insns 1 .. 100 [50]
--vex-guest-chase-thresh 0 .. 99 [10]
They're not documented in the manual, but hopefully you can work them out.
Using --vex-guest-max-insns=1 is like using the old --single-step, I think.
Nick
|
|
From: Nicholas N. <nj...@cs...> - 2006-06-12 23:20:24
|
On Mon, 12 Jun 2006, Jeffrey Stedfast wrote: > I just noticed the timestamp format changed somewhere between Valgrind > 2.4.0 and Valgrind 3.1.0 in the non-xml log output. > > The new date format looks like "##:##:##:##.###" > > Can anyone tell me what each of these fields are and when the change was > made? (was it made in 3.0? or just in 3.1?) The release notes say it changed in 3.1.0: - The --time-stamp option no longer gives an absolute date and time. It now prints the time elapsed since the program began. The manual (section 2.6.2) explains the meaning of the fields. Nick |
|
From: Nicholas N. <nj...@cs...> - 2006-06-12 23:16:42
|
On Mon, 12 Jun 2006, Eric Li wrote: > Hi, are there updated instructions for building a Valgrind tool somewhere? > The instructions on the documentations page are out of date, e.g. there's > no valgrind/autogen.sh or a valgrind/inst dir. The README file explains how to build both from a distribution and from a SVN repository checkout. Nick |
|
From: Jeffrey S. <fe...@no...> - 2006-06-12 21:33:58
|
I just noticed the timestamp format changed somewhere between Valgrind 2.4.0 and Valgrind 3.1.0 in the non-xml log output. The new date format looks like "##:##:##:##.###" Can anyone tell me what each of these fields are and when the change was made? (was it made in 3.0? or just in 3.1?) Thanks, -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. fe...@no... - www.novell.com |
|
From: Eric L. <ew...@an...> - 2006-06-12 20:41:39
|
Are there replacements for the --optimise=no --instrument=no --single-step=yes --cleanup=no flags in the 3.x.x versions (which are documented online as ways of viewing/debugging the IR)? When I tried them, it said those were bad options. Thanks, Eric > One other thing -- if it hasn't been pointed out already -- is to make > friends with the Valgrind flag combination > > --tool=none --trace-flags=10000000 --trace-notbelow=0 > > (also --trace-flags=10001000). I always find that seeing the IR printed > out nicely makes it much easier to understand what's going on. > > J > > |
|
From: Tom H. <to...@co...> - 2006-06-12 17:43:28
|
In message <4819.128.2.134.182.1150132468.squirrel@128.2.134.182>
"Eric Li" <ew...@an...> wrote:
> Hi, are there updated instructions for building a Valgrind tool somewhere?
> The instructions on the documentations page are out of date, e.g. there's
> no valgrind/autogen.sh or a valgrind/inst dir.
There is an autogen.sh, but only in the development tree as released
tar balls include a pregenerated configure script so it is not needed.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Eric L. <ew...@an...> - 2006-06-12 17:14:34
|
Hi, are there updated instructions for building a Valgrind tool somewhere? The instructions on the documentations page are out of date, e.g. there's no valgrind/autogen.sh or a valgrind/inst dir. thanks, Eric |
|
From: Apostolos M. <apo...@gm...> - 2006-06-12 06:53:35
|
On 6/11/06, Dennis Lubert <pla...@pr...> wrote: > Am Freitag, den 09.06.2006, 18:05 +0300 schrieb Apostolos Manolitzas: > > > BUT the program is not executed with the following error: > > valgrind --tool=3Dmemcheck --log-file=3D/mnt/ipu/tmp/grind.log ./myf= ile.x -s9 > > ./nms.imgX =C5=14"t=C4=01_\=C6BX=10=10!0=03=03=03=03=03=03=03=03=03=03= =03=03=03=03=03=03 > > L//lib/valgrind//ppc32-linux/vgpreload_core.so=B0=C4=01X=CC=01=C4=01Yt= =C4=01Y=04=EC=C0=B4t8Droot@foo:# > > Im having a bit of a problem spotting the actual error. do you mean the > cryptic characters are the error? > I believe that there is some memory corruption that changes the path string. So the program can't load the librady vgpreload_core.so even it is in a valid path. I don't know what else to think... |
|
From: Dennis L. <pla...@pr...> - 2006-06-11 12:11:50
|
Am Freitag, den 09.06.2006, 18:05 +0300 schrieb Apostolos Manolitzas: > BUT the program is not executed with the following error: > valgrind --tool=3Dmemcheck --log-file=3D/mnt/ipu/tmp/grind.log ./myf= ile.x -s9 > ./nms.imgX =C3=85=14"t=C3=84=01_\=C3=86BX=10=10!0=03=03=03=03=03=03=03=03= =03=03=03=03=03=03=03=03 > L//lib/valgrind//ppc32-linux/vgpreload_core.so=C2=B0=C3=84=01X=C3=8C=01= =C3=84=01Yt=C3=84=01Y=04=C3=AC=C3=80=C2=B4t8Droot@foo:# Im having a bit of a problem spotting the actual error. do you mean the cryptic characters are the error? |
|
From: Apostolos M. <apo...@gm...> - 2006-06-09 15:05:44
|
I try to use valgrind for my embedded system. The target is a motorola
processor with montavista linux (ppc)
Linux 2.4.20_mvl31-8270ppu #8 Fri Feb 24 10:43:32 EET 2006 ppc unknown
I compiled valgrind with:
CC=3D/devkit/montavista/ppc/82xx/bin/ppc_82xx-gcc ./configure
--host=3Dppc-linux --disable-tls
gcc version 3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-12-24)
I installed correctly valgrind, but when it tries to load I have the
following message in the log file
=3D=3D482=3D=3D Memcheck, a memory error detector.
=3D=3D482=3D=3D Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et=
al.
=3D=3D482=3D=3D Using LibVEX rev 1606, a library for dynamic binary transla=
tion.
=3D=3D482=3D=3D Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
=3D=3D482=3D=3D Using valgrind-3.2.0, a dynamic binary instrumentation fram=
ework.
=3D=3D482=3D=3D Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et=
al.
=3D=3D482=3D=3D For more details, rerun with: -v
=3D=3D482=3D=3D
=3D=3D482=3D=3D My PID =3D 482, parent PID =3D 481. Prog and args are:
=3D=3D482=3D=3D ./myfile.x
=3D=3D482=3D=3D -s9
=3D=3D482=3D=3D
=3D=3D482=3D=3D
=3D=3D482=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from=
1)
=3D=3D482=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks.
=3D=3D482=3D=3D malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
=3D=3D482=3D=3D For counts of detected errors, rerun with: -v
=3D=3D482=3D=3D All heap blocks were freed -- no leaks are possible
BUT the program is not executed with the following error:
valgrind --tool=3Dmemcheck --log-file=3D/mnt/ipu/tmp/grind.log ./myfile.=
x -s9
./nms.imgX =C5=14"t=C4=01_\=C6BX=10=10!0=03=03=03=03=03=03=03=03=03=03=03=
=03=03=03=03=03
L//lib/valgrind//ppc32-linux/vgpreload_core.so=B0=C4=01X=CC=01=C4=01Yt=C4=
=01Y=04=EC=C0=B4t8Droot@foo:#
but the vgpreload_core.so it is in the path, it is in the LD_LIBRARY_PATH
I tried the same with gdb and i 'm run into the same error.
I used strace and had:
open("/lib/valgrind//ppc32-linux/vgpreload_core.so", O_RDONLY) =3D -1
ENOENT (No such file or directory)
but #ll /lib/valgrind//ppc32-linux/vgpreload_core.so
-rwxr-xr-x 1 root root 71482 Jun 9 16:01
/lib/valgrind//ppc32-linux/vgpreload_core.so*
Any idea about this error ??
Best regards,
Apostolos
gdb output:
(gdb)run -v myfile.x -s9
Starting program: /lib/valgrind/ppc32-linux/memcheck -v nms.img -s9
=3D=3D527=3D=3D Memcheck, a memory error detector.
=3D=3D527=3D=3D Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et=
al.
=3D=3D527=3D=3D Using LibVEX rev 1606, a library for dynamic binary transla=
tion.
=3D=3D527=3D=3D Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
=3D=3D527=3D=3D Using valgrind-3.2.0, a dynamic binary instrumentation fram=
ework.
=3D=3D527=3D=3D Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et=
al.
=3D=3D527=3D=3D
--527-- Command line
--527-- myfile.x
--527-- -s9
--527-- Startup, with flags:
--527-- -v
--527-- Contents of /proc/version:
--527-- Linux version 2.4.20_mvl31-8270ppu (iple@pclinux) (gcc
version 3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-12-24)) #8 Fri Feb
24 10:43:32 EET 2006
--527-- Arch and hwcaps: PPC32, ppc32-int-flt-GX
--527-- Valgrind library directory: /lib/valgrind/
--527-- Reading syms from /lib/ld-2.3.2.so (0x4000000)
--527-- Reading syms from /intracom/usr/DISK0/BOOT/myfile.x (0x10000000)
--527-- Reading syms from /lib/valgrind/ppc32-linux/memcheck (0x38000000)
--527-- object doesn't have a dynamic symbol table
--527-- Reading suppressions file: /mnt/ipu/lib/valgrind//default.supp
--527-- REDIR: 0x40129B0 (strlen) redirected to 0x3802EDD0
(vgPlain_ppc32_linux_REDIR_FOR_strlen)
--527-- REDIR: 0x40127E0 (strcmp) redirected to 0x3802EDF8
(vgPlain_ppc32_linux_REDIR_FOR_strcmp)
myfile.xX =C5=14"t=C4=01_\=C6BX=10=10!0=03=03=03=03=03=03=03=03=03=03=03=03=
=03=03=03=03
L//lib/valgrind//ppc32-linux/vgpreload_core.so=B0=C4=01X=CC=01=C4=01Yt=C4=
=01Y=04=EC=C0=B4t8D=3D=3D527=3D=3D
=3D=3D527=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from=
1)
--527--
--527-- supp: 4 glibc-2.3.x-on-SuSE-10.0-(PPC)-1
=3D=3D527=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks.
=3D=3D527=3D=3D malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
=3D=3D527=3D=3D
=3D=3D527=3D=3D All heap blocks were freed -- no leaks are possible.
--527-- memcheck: sanity checks: 0 cheap, 1 expensive
--527-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--527-- memcheck: auxmaps: 0 searches, 0 comparisons
--527-- memcheck: SMs: n_issued =3D 6 (96k, 0M)
--527-- memcheck: SMs: n_deissued =3D 0 (0k, 0M)
--527-- memcheck: SMs: max_noaccess =3D 65535 (1048560k, 1023M)
--527-- memcheck: SMs: max_undefined =3D 0 (0k, 0M)
--527-- memcheck: SMs: max_defined =3D 41 (656k, 0M)
--527-- memcheck: SMs: max_non_DSM =3D 6 (96k, 0M)
--527-- memcheck: max sec V bit nodes: 0 (0k, 0M)
--527-- memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0)
--527-- memcheck: max shadow mem size: 400k, 0M
--527-- translate: fast SP updates identified: 54 ( 61.3%)
--527-- translate: generic_known SP updates identified: 27 ( 30.6%)
--527-- translate: generic_unknown SP updates identified: 7 ( 7.9%)
--527-- tt/tc: 910 tt lookups requiring 909 probes
--527-- tt/tc: 910 fast-cache updates, 2 flushes
--527-- transtab: new 455 (12,356 -> 201,612; ratio 163:10) [0 scs]
--527-- transtab: dumped 0 (0 -> ??)
--527-- transtab: discarded 0 (0 -> ??)
--527-- scheduler: 2,532 jumps (bb entries).
--527-- scheduler: 0/469 major/minor sched events.
--527-- sanity: 1 cheap, 1 expensive checks.
--527-- exectx: 30,011 lists, 2 contexts (avg 0 per list)
--527-- exectx: 4 searches, 2 full compares (500 per 1000)
--527-- exectx: 0 cmp2, 5 cmp4, 0 cmpAll
Program exited with code 0177.
|
|
From: Eric L. <ew...@an...> - 2006-06-09 14:52:37
|
>> If I want to Vexity an array of BB's, each with a diff number of >> instructions, in a loop, do I have to call LibVEX_Init every iteration >> after setting the guest_max_insns of the VexControl argument for the >> current BB? > > Yes. I tried this but LibVEX_Init has it's own internal static variable to keep track of the fact that it's been called so that it would fail the assert if I called it again. Is there an unInit of some kind that undoes this? >> Or can I just modify the VexControl struct only and VEX would pick it >> up? > > No. > >> Are there any undesired side effects to calling LibVEX_Init multiple >> times? > > No. > > J > > |
|
From: Julian S. <js...@ac...> - 2006-06-09 10:19:13
|
On Wednesday 07 June 2006 19:10, Eric Li wrote: > > I guess one kludge is: if you want to vexify a block which you know > > contains N instructions, you can initialise vex and set > > VexControl.guest_max_insns to N (along with setting .guest_chase_thresh > > to zero). Then it should stop after N insns even if it thinks it could > > go further. > > If I want to Vexity an array of BB's, each with a diff number of > instructions, in a loop, do I have to call LibVEX_Init every iteration > after setting the guest_max_insns of the VexControl argument for the > current BB? Yes. > Or can I just modify the VexControl struct only and VEX would > pick it up? No. > Are there any undesired side effects to calling LibVEX_Init > multiple times? No. J |
|
From: Julian S. <js...@ac...> - 2006-06-09 10:17:24
|
On Thursday 08 June 2006 21:43, Eric Li wrote: > In bb_to_IR and in LibVEX_Init, there are checks that the guest_max_insns > is between 1 and 100 inclusive. Is there a reason that the max instructions > translated cannot exceed 100? Yes, two reasons. Limiting bbs to that length has negligible performance impact when running V since almost all are shorter anyway. The benefits are (1) it bounds the amount of intermediate storage (grep for N_TEMPORARY_BYTES) to translate any given bb, and (2) (somewhat secondarily) it limits worst-case translation time costs should an O(N^2) or worse algorithm accidentally exist in the compilation pipeline, particularly in iropt.c. > How can I translate a BB that has more than > 100 instructions? Chop up any bbs longer than 100 insns into pieces. J |
|
From: Eric L. <ew...@an...> - 2006-06-08 20:44:10
|
In bb_to_IR and in LibVEX_Init, there are checks that the guest_max_insns is between 1 and 100 inclusive. Is there a reason that the max instructions translated cannot exceed 100? How can I translate a BB that has more than 100 instructions? Thanks, Eric |
|
From: Julian S. <js...@ac...> - 2006-06-08 19:46:43
|
On Thursday 08 June 2006 20:15, Eric Li wrote: > > On Wednesday 07 June 2006 07:35, Eric Li wrote: > >> What's the "dispatcher" at the end of VexTranslateArgs in 3.2.0 (but > >> not 3.1.1) for? And what should go there in my case? I've read the > >> comments but I'm still not clear on it. > > > > More or less irrelevant from an analysis point of view. It's where > > execution (on the host) jumps to after the generated code is run, so that > > the next block can be found/run. I'd set it to NULL. You won't see it > > in the IR anyway. > > There are asserts in LibVEX_Translate (specifically the switch stmt where > the arch is X86 or AMD64) that check that "dispatch" is not NULL. Can I > just create a dummy function for it instead? Yes. J |