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
(9) |
2
(5) |
3
(1) |
4
(4) |
5
|
6
(8) |
7
(12) |
|
8
(6) |
9
(10) |
10
(6) |
11
(8) |
12
(12) |
13
(5) |
14
(1) |
|
15
(1) |
16
(12) |
17
(9) |
18
(4) |
19
(8) |
20
(4) |
21
(1) |
|
22
|
23
(4) |
24
(12) |
25
(13) |
26
(16) |
27
(4) |
28
(2) |
|
29
(1) |
30
(4) |
31
(9) |
|
|
|
|
|
From: Yeshurun, M. <mei...@in...> - 2006-01-16 09:31:26
|
Hi,=20 What do these warnings mean? --14739-- warning: CfiSI 0x1C430 .. 0x1C430 outside segment 0x23CFE000 .. 0x23D41FFF --14739-- warning: CfiSI 0x1C431 .. 0x1C432 outside segment 0x23CFE000 .. 0x23D41FFF --14739-- warning: CfiSI 0x1C433 .. 0x1C4EC outside segment 0x23CFE000 .. 0x23D41FFF Thanks, Meir |
|
From: Tom H. <to...@co...> - 2006-01-16 08:55:33
|
In message <ABD...@br...>
Richard Frith-Macdonald <ri...@br...> wrote:
> Unfortunately, valgrind doesn't seem to work with Sun's Java
> implementation. After much searching the 'resolved' bug #69508 seems
> to describe what is happening ... the last two comments in the bug
> report talk about Java re-execing to put its own directory at the
> front of LD_LIBRARY_PATH and valgrind doing the same ... getting into
> an infinite loop.
Possibly - if you use --trace-children=yes do you see a whole stream
of valgrind startup messages appearing?
> I guess the bug being marked as 'resolved' refers to the original
> problem (a 'stack size too small' report) ... but it doesn't actually
> explain how to get valgrind/java to work together. has this actually
> been done? Is there a known workaround?
I'm not sure when the bug was resolved, but we no longer change
the value of LD_LIBRARY_PATH as it was only ever needed to allow
us to replace libpthread with our own one and we haven't done that
since the 2.2.x releases.
I think there was a delay in removing the LD_LIBRARY_PATH code, but
the 3.x releases should all be fine - none of them will try and
change it.
What version are you using?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Richard Frith-M. <ri...@br...> - 2006-01-16 07:13:05
|
I have a large body of code making complex use of JNI called from servlets in tomcat. Because this uses a lot of JNI, and was developed on the Sun implementation of java, I have been unable to find another implementation which will run it ... SableVM and Kaffe lack a lot of the JNI functions required. I have infrequent crashes in Java which are almost certainly due to errors in the JNI code ... most likely C library code writing to memory it shouldn't, and corrupting the Java system ... so valgrind seems the only realistic hope to catch that kind of thing. Unfortunately, valgrind doesn't seem to work with Sun's Java implementation. After much searching the 'resolved' bug #69508 seems to describe what is happening ... the last two comments in the bug report talk about Java re-execing to put its own directory at the front of LD_LIBRARY_PATH and valgrind doing the same ... getting into an infinite loop. I guess the bug being marked as 'resolved' refers to the original problem (a 'stack size too small' report) ... but it doesn't actually explain how to get valgrind/java to work together. has this actually been done? Is there a known workaround? I guess it ought to be possible to get valgrind to intercept the system calls that java uses and fool it into thinking its directory is the first in LD_LIBRARY_PATH? Or perhaps do some clever mixing/matching of java and valgrind libraries putting them both in the same directory I don't know enough about dynamic library loading to know whether that's really possible? I'd really appreciate some help on this. |
|
From: Dennis L. <pla...@tz...> - 2006-01-13 15:10:20
|
Hi, I have a little program of our test suite that determines the maximum number of threads. It does that by allocating threads until pthread_create returns an error, usually ENOMEM or similar. Now when running that under V it says that VG_N_THREADS is too low and I should recompile. Could it be done that it instead returns ENOMEM or similar to the program so that it can continue? greets Dennis |
|
From: Igmar P. <mai...@jd...> - 2006-01-13 13:21:53
|
> I think your patch will work -- I added code to do a specific check > for -7002 and post a 0 byte memory write and that has worked around > the issue. The reason the read is returning a -7002 is the (custom) > hardware driver was written to return -7002 as a status value in a > certain condition. Please mention this information in your startpost next time; using non-default error codes will definitely lead to buggy userspace code. I would suggest rewriting the driver to do the proper thing (that is, return a standard error code, and write an ioctl() to retrieve the driver-specific error code. Regards, Igmar |
|
From: Sadys H. <sad...@gm...> - 2006-01-13 10:34:00
|
Hi, all.
I met a problem when using valgrind to debug my occi application. The
program is running ok outside of valgrrind, but got blocked when running in
valgrind.
Below the code where the application got blocked at when running in
valgrind:
//init oracle Environment
try
{
env =3D
Environment::createEnvironment(Environment::THREADED_MUTEXED);
bInitEnv =3D true;
WriteDBLogFile( "OracleConnection_p5", LL_DB_DebugInfo,
LogType_ORACLEConnection);
}
catch(SQLException ex)
{
WriteDBLogFile( "Create Oracle Environment failed.", LL_DB_Error,
LogType_ORACLEConnection);
bInitEnv=3Dfalse;
}
WriteDBLogFile( "OracleConnection_p6", LL_DB_DebugInfo,
LogType_ORACLEConnection);
this->Connect();
WriteDBLogFile( "OracleConnection_p7", LL_DB_DebugInfo,
LogType_ORACLEConnection);
WriteDBLogFile( "Exit ORACLEConnection::ORACLEConnection().",
LL_DB_DebugInfo, LogType_ORACLEConnection);
};
bool
ORACLEConnection::Connect()
{
WriteDBLogFile( "Enter into ORACLEConnection::Connect().",
LL_DB_DebugInfo, LogType_ORACLEConnection);
char sLog[MAX_SQL_LENGTH+1]=3D{'\0'};
if(!bInitEnv)
{
WriteDBLogFile( "The Oracle Environment has not been created.",
LL_DB_Error,LogType_ORACLEConnection);
return false;
}
//create oracle connection instance
try
{
sprintf(sLog, "Connect to Oracle:%s/%s@%s", sUser.c_str(),
sPasswd.c_str(), sNetService.c_str());
WriteDBLogFile( sLog, LL_DB_SysEvent,LogType_ORACLEConnection);
The output is:
2006 01 13 17:57:19: OracleConnection_p1
2006 01 13 17:57:19: OracleConnection_p2
2006 01 13 17:57:19: OracleConnection_p3
2006 01 13 17:57:19: OracleConnection_p4
2006 01 13 17:57:20: OracleConnection_p5
2006 01 13 17:57:20: OracleConnection_p6
and then nothing............................
The most curious thing is that there is nothing between OracleConnection_p6
and OracleConnection_p7. Where the program has gone?!!!!
I opend valgrind's debug option and the debug output is:
SYSCALL[13095,1]( 5) sys_open (
0x4F97A00(/home/xw/Library/DBLib/common/dbclient/oracleclient/ocommon/nls/a=
dmin/data/lxx
10035.nlb), 0 ) --> [async] ...
SYSCALL[13095,1]( 5) ... [async] --> Success(0xA)
SYSCALL[13095,1]( 3) sys_read ( 10, 0x4F97690, 100 ) --> [async] ...
SYSCALL[13095,1]( 3) ... [async] --> Success(0x64)
SYSCALL[13095,1]( 3) sys_read ( 10, 0x4F976F4, 656 ) --> [async] ...
SYSCALL[13095,1]( 3) ... [async] --> Success(0x28E)
SYSCALL[13095,1]( 6) sys_close ( 10 )[sync] --> Success(0x0)
SYSCALL[13095,1]( 78) sys_gettimeofday ( 0xBEFFC7B0, 0x0 )[sync] -->
Success(0x0)
SYSCALL[13095,1]( 78) sys_gettimeofday ( 0xBEFFC8B8, 0xBEFFC8C0 )[sync] -->
Success(0x0)
SYSCALL[13095,1]( 13) sys_time ( 0xBEFFCBF0 )[sync] --> Success(0x43C778BC)
SYSCALL[13095,1]( 4) sys_write ( 1, 0x401F000, 41 ) --> [async] ...
SYSCALL[13095,1]( 4) ... [async] --> Success(0x29)
SYSCALL[13095,1]( 4) sys_write ( 11, 0x4022000, 41 ) --> [async] ...
SYSCALL[13095,1]( 4) ... [async] --> Success(0x29)
SYSCALL[13095,1]( 13) sys_time ( 0xBEFFCBF0 )[sync] --> Success(0x43C778BD)
SYSCALL[13095,1]( 4) sys_write ( 1, 0x401F000, 41 ) --> [async] ...
SYSCALL[13095,1]( 4) ... [async] --> Success(0x29)
SYSCALL[13095,1]( 4) sys_write ( 11, 0x4022000, 41 ) --> [async] ...
SYSCALL[13095,1]( 4) ... [async] --> Success(0x29)
--
Any idea about that?
Thanks in advance
~~~~~~@@~~~~~~~~@@~~~~~~~~~
!!! Xie Wei, A programmer !!!
!!! sad...@gm... !!!
!!! Mobile:13917917201 !!!
~~~~~~~~~~~###~~~~~~~~
|
|
From: Tom H. <to...@co...> - 2006-01-13 08:53:37
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Thursday 12 January 2006 21:56, Logan Gabriel wrote:
>
>> I think your patch will work -- I added code to do a specific check
>> for -7002 and post a 0 byte memory write and that has worked around
>> the issue. The reason the read is returning a -7002 is the (custom)
>> hardware driver was written to return -7002 as a status value in a
>> certain condition.
>
> Oh, thats invalid though. Error return values are guaranteed to be in the
> range of -4095..-1.
On x86 and amd64 they are - on PPC the error flag is out of band so
there are no reserved error values.
It certainly sounds like the driver is doing something completely
bogus though.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dirk M. <dm...@gm...> - 2006-01-13 08:45:27
|
On Thursday 12 January 2006 21:56, Logan Gabriel wrote: > I think your patch will work -- I added code to do a specific check > for -7002 and post a 0 byte memory write and that has worked around > the issue. The reason the read is returning a -7002 is the (custom) > hardware driver was written to return -7002 as a status value in a > certain condition. Oh, thats invalid though. Error return values are guaranteed to be in the range of -4095..-1. Dirk |
|
From: Logan G. <log...@gm...> - 2006-01-12 20:56:16
|
I think your patch will work -- I added code to do a specific check for -7002 and post a 0 byte memory write and that has worked around the issue. The reason the read is returning a -7002 is the (custom) hardware driver was written to return -7002 as a status value in a certain condition. A more standard way would have been to write to the third ioctl param but that was not done =3D). Thanks a lot for the help I can continue to debug my application now =3D) On 1/12/06, Julian Seward <js...@ac...> wrote: > > > =3D=3D1319=3D=3D Warning: set address range perms: large range 21474766= 46, a 0, v 0 > > Yeh. That's because I suggested the wrong thing. RES is the result of > the syscall (-7002) and the POST_MEM_WRITE is calling set_address_range_p= erms. > > What I should have said is - try the absolute value of RES: > > ( ((Int)RES) < 0 : -(RES) : (RES) ) > > > > Yes that is correct, The system call is returning -7002 in one > > > condition.... and -7001 in a different condition. > > Nevertheless I don't understand how read() can succeed and return a > negative value. > > J > -- Thanks; Logan Gabriel. |
|
From: Julian S. <js...@ac...> - 2006-01-12 20:54:09
|
> ==1319== Warning: set address range perms: large range 2147476646, a 0, v 0 Yeh. That's because I suggested the wrong thing. RES is the result of the syscall (-7002) and the POST_MEM_WRITE is calling set_address_range_perms. What I should have said is - try the absolute value of RES: ( ((Int)RES) < 0 : -(RES) : (RES) ) > > Yes that is correct, The system call is returning -7002 in one > > condition.... and -7001 in a different condition. Nevertheless I don't understand how read() can succeed and return a negative value. J |
|
From: Logan G. <log...@gm...> - 2006-01-12 20:37:11
|
=3D=3D1319=3D=3D Warning: set address range perms: large range 2147476646, =
a 0, v 0
Memcheck: mc_main.c:584 (set_address_range_perms): the 'impossible' happene=
d.
=3D=3D1319=3D=3D at 0x70015010: report_and_quit (m_libcassert.c:136)
=3D=3D1319=3D=3D by 0x70015260: vgPlain_assert_fail (m_libcassert.c:199)
=3D=3D1319=3D=3D by 0x70003E7C: set_address_range_perms (mc_main.c:573)
=3D=3D1319=3D=3D by 0x7004E44C: vgSysWrap_generic_sys_read_after
(priv_types_n_macros.h:249)
=3D=3D1319=3D=3D by 0x70052370: vgPlain_post_syscall (syswrap-main.c:934=
)
=3D=3D1319=3D=3D by 0x70052140: vgPlain_client_syscall (syswrap-main.c:8=
60)
=3D=3D1319=3D=3D by 0x7003D268: handle_syscall (scheduler.c:624)
=3D=3D1319=3D=3D by 0x7003D670: vgPlain_scheduler (scheduler.c:725)
=3D=3D1319=3D=3D by 0x700533E4: thread_wrapper (syswrap-linux.c:86)
=3D=3D1319=3D=3D by 0x70053518: run_a_thread_NORETURN (syswrap-linux.c:1=
19)
=3D=3D1319=3D=3D by 0x70053668: vgModuleLocal_start_thread_NORETURN
(syswrap-linux.c:206)
=3D=3D1319=3D=3D by 0x7005FEC0: (within /usr/local/lib/valgrind/ppc32-li=
nux/memcheck)
=3D=3D1319=3D=3D by 0x4483BA1C: ???
On 1/12/06, Logan Gabriel <log...@gm...> wrote:
> Yes that is correct, The system call is returning -7002 in one
> condition.... and -7001 in a different condition. I will go change
> the code and re run in an hour or two after lunch... thanks for the
> prompt replies =3D).
>
> On 1/12/06, Julian Seward <js...@ac...> wrote:
> >
> > Cancel that last message - I didn't read the backtrace carefully
> > enough. It's handling a read syscall, but what _seems_ (note,
> > superficial analysis :-) to be happening is that the kernel is
> > saying the syscall succeeded and read -7002 bytes of data. Cool.
> >
> > The immediate trigger of the problem is this
> >
> > POST(sys_read)
> > {
> > vg_assert(SUCCESS);
> > POST_MEM_WRITE( ARG2, RES );
> > }
> >
> > (syswrap-generic.c:4785). What happens if you change "RES" to
> > "0x7FFFFFFF & (RES)" ?
> >
> > J
> >
> >
> > > > Memcheck: mc_main.c:584 (set_address_range_perms): the 'impossible'
> > > > happened. =3D=3D2272=3D=3D at 0x70015010: report_and_quit (m_lib=
cassert.c:136)
> > > > =3D=3D2272=3D=3D by 0x70015260: vgPlain_assert_fail (m_libcasser=
t.c:199)
> > > > =3D=3D2272=3D=3D by 0x70003E7C: set_address_range_perms (mc_main=
.c:573)
> > > > =3D=3D2272=3D=3D by 0x7004E448: vgSysWrap_generic_sys_read_after
> > > > (priv_types_n_macros.h:249)
> > > > =3D=3D2272=3D=3D by 0x7005236C: vgPlain_post_syscall (syswrap-ma=
in.c:934)
> > > > =3D=3D2272=3D=3D by 0x7005213C: vgPlain_client_syscall (syswrap-=
main.c:860)
> > > > =3D=3D2272=3D=3D by 0x7003D268: handle_syscall (scheduler.c:624)
> > > > =3D=3D2272=3D=3D by 0x7003D670: vgPlain_scheduler (scheduler.c:7=
25)
> > > > =3D=3D2272=3D=3D by 0x700533E0: thread_wrapper (syswrap-linux.c:=
86)
> > > > =3D=3D2272=3D=3D by 0x70053514: run_a_thread_NORETURN (syswrap-l=
inux.c:119)
> > > > =3D=3D2272=3D=3D by 0x70053664: vgModuleLocal_start_thread_NORET=
URN
> > >
> > > Well, umm. The problem is certainly syscall related, but this stack
> > > trace lacks the critical frame which would indicate which syscall it
> > > is. (What was really called from syswrap-main.c:934?)
> > >
> > > Can you rerun with --trace-syscalls=3Dyes. This should give an
> > > strace-style log of syscalls. Just send the couple of lines
> > > prior to the "Warning" line.
> > >
> > > J
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc. Do you grep through lo=
g
> > > files for problems? Stop! Download the new AJAX search engine that =
makes
> > > searching your log files as easy as surfing the web. DOWNLOAD SPLUN=
K!
> > > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> > > _______________________________________________
> > > Valgrind-users mailing list
> > > Val...@li...
> > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
>
>
> --
> Thanks;
> Logan Gabriel.
>
--
Thanks;
Logan Gabriel.
|
|
From: Logan G. <log...@gm...> - 2006-01-12 19:21:17
|
Yes that is correct, The system call is returning -7002 in one
condition.... and -7001 in a different condition. I will go change
the code and re run in an hour or two after lunch... thanks for the
prompt replies =3D).
On 1/12/06, Julian Seward <js...@ac...> wrote:
>
> Cancel that last message - I didn't read the backtrace carefully
> enough. It's handling a read syscall, but what _seems_ (note,
> superficial analysis :-) to be happening is that the kernel is
> saying the syscall succeeded and read -7002 bytes of data. Cool.
>
> The immediate trigger of the problem is this
>
> POST(sys_read)
> {
> vg_assert(SUCCESS);
> POST_MEM_WRITE( ARG2, RES );
> }
>
> (syswrap-generic.c:4785). What happens if you change "RES" to
> "0x7FFFFFFF & (RES)" ?
>
> J
>
>
> > > Memcheck: mc_main.c:584 (set_address_range_perms): the 'impossible'
> > > happened. =3D=3D2272=3D=3D at 0x70015010: report_and_quit (m_libca=
ssert.c:136)
> > > =3D=3D2272=3D=3D by 0x70015260: vgPlain_assert_fail (m_libcassert.=
c:199)
> > > =3D=3D2272=3D=3D by 0x70003E7C: set_address_range_perms (mc_main.c=
:573)
> > > =3D=3D2272=3D=3D by 0x7004E448: vgSysWrap_generic_sys_read_after
> > > (priv_types_n_macros.h:249)
> > > =3D=3D2272=3D=3D by 0x7005236C: vgPlain_post_syscall (syswrap-main=
.c:934)
> > > =3D=3D2272=3D=3D by 0x7005213C: vgPlain_client_syscall (syswrap-ma=
in.c:860)
> > > =3D=3D2272=3D=3D by 0x7003D268: handle_syscall (scheduler.c:624)
> > > =3D=3D2272=3D=3D by 0x7003D670: vgPlain_scheduler (scheduler.c:725=
)
> > > =3D=3D2272=3D=3D by 0x700533E0: thread_wrapper (syswrap-linux.c:86=
)
> > > =3D=3D2272=3D=3D by 0x70053514: run_a_thread_NORETURN (syswrap-lin=
ux.c:119)
> > > =3D=3D2272=3D=3D by 0x70053664: vgModuleLocal_start_thread_NORETUR=
N
> >
> > Well, umm. The problem is certainly syscall related, but this stack
> > trace lacks the critical frame which would indicate which syscall it
> > is. (What was really called from syswrap-main.c:934?)
> >
> > Can you rerun with --trace-syscalls=3Dyes. This should give an
> > strace-style log of syscalls. Just send the couple of lines
> > prior to the "Warning" line.
> >
> > J
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > files for problems? Stop! Download the new AJAX search engine that ma=
kes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
--
Thanks;
Logan Gabriel.
|
|
From: Julian S. <js...@ac...> - 2006-01-12 18:12:45
|
Cancel that last message - I didn't read the backtrace carefully
enough. It's handling a read syscall, but what _seems_ (note,
superficial analysis :-) to be happening is that the kernel is
saying the syscall succeeded and read -7002 bytes of data. Cool.
The immediate trigger of the problem is this
POST(sys_read)
{
vg_assert(SUCCESS);
POST_MEM_WRITE( ARG2, RES );
}
(syswrap-generic.c:4785). What happens if you change "RES" to
"0x7FFFFFFF & (RES)" ?
J
> > Memcheck: mc_main.c:584 (set_address_range_perms): the 'impossible'
> > happened. ==2272== at 0x70015010: report_and_quit (m_libcassert.c:136)
> > ==2272== by 0x70015260: vgPlain_assert_fail (m_libcassert.c:199)
> > ==2272== by 0x70003E7C: set_address_range_perms (mc_main.c:573)
> > ==2272== by 0x7004E448: vgSysWrap_generic_sys_read_after
> > (priv_types_n_macros.h:249)
> > ==2272== by 0x7005236C: vgPlain_post_syscall (syswrap-main.c:934)
> > ==2272== by 0x7005213C: vgPlain_client_syscall (syswrap-main.c:860)
> > ==2272== by 0x7003D268: handle_syscall (scheduler.c:624)
> > ==2272== by 0x7003D670: vgPlain_scheduler (scheduler.c:725)
> > ==2272== by 0x700533E0: thread_wrapper (syswrap-linux.c:86)
> > ==2272== by 0x70053514: run_a_thread_NORETURN (syswrap-linux.c:119)
> > ==2272== by 0x70053664: vgModuleLocal_start_thread_NORETURN
>
> Well, umm. The problem is certainly syscall related, but this stack
> trace lacks the critical frame which would indicate which syscall it
> is. (What was really called from syswrap-main.c:934?)
>
> Can you rerun with --trace-syscalls=yes. This should give an
> strace-style log of syscalls. Just send the couple of lines
> prior to the "Warning" line.
>
> J
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Julian S. <js...@ac...> - 2006-01-12 17:59:44
|
> ==2272== Warning: set address range perms: large range 4294960294, a 0, v 0 > > Memcheck: mc_main.c:584 (set_address_range_perms): the 'impossible' > happened. ==2272== at 0x70015010: report_and_quit (m_libcassert.c:136) > ==2272== by 0x70015260: vgPlain_assert_fail (m_libcassert.c:199) > ==2272== by 0x70003E7C: set_address_range_perms (mc_main.c:573) > ==2272== by 0x7004E448: vgSysWrap_generic_sys_read_after > (priv_types_n_macros.h:249) > ==2272== by 0x7005236C: vgPlain_post_syscall (syswrap-main.c:934) > ==2272== by 0x7005213C: vgPlain_client_syscall (syswrap-main.c:860) > ==2272== by 0x7003D268: handle_syscall (scheduler.c:624) > ==2272== by 0x7003D670: vgPlain_scheduler (scheduler.c:725) > ==2272== by 0x700533E0: thread_wrapper (syswrap-linux.c:86) > ==2272== by 0x70053514: run_a_thread_NORETURN (syswrap-linux.c:119) > ==2272== by 0x70053664: vgModuleLocal_start_thread_NORETURN Well, umm. The problem is certainly syscall related, but this stack trace lacks the critical frame which would indicate which syscall it is. (What was really called from syswrap-main.c:934?) Can you rerun with --trace-syscalls=yes. This should give an strace-style log of syscalls. Just send the couple of lines prior to the "Warning" line. J |
|
From: Logan G. <log...@gm...> - 2006-01-12 17:49:40
|
Here is the output: =3D=3D2272=3D=3D Warning: set address range perms: large range 4294960294, = a 0, v 0 Memcheck: mc_main.c:584 (set_address_range_perms): the 'impossible' happene= d. =3D=3D2272=3D=3D at 0x70015010: report_and_quit (m_libcassert.c:136) =3D=3D2272=3D=3D by 0x70015260: vgPlain_assert_fail (m_libcassert.c:199) =3D=3D2272=3D=3D by 0x70003E7C: set_address_range_perms (mc_main.c:573) =3D=3D2272=3D=3D by 0x7004E448: vgSysWrap_generic_sys_read_after (priv_types_n_macros.h:249) =3D=3D2272=3D=3D by 0x7005236C: vgPlain_post_syscall (syswrap-main.c:934= ) =3D=3D2272=3D=3D by 0x7005213C: vgPlain_client_syscall (syswrap-main.c:8= 60) =3D=3D2272=3D=3D by 0x7003D268: handle_syscall (scheduler.c:624) =3D=3D2272=3D=3D by 0x7003D670: vgPlain_scheduler (scheduler.c:725) =3D=3D2272=3D=3D by 0x700533E0: thread_wrapper (syswrap-linux.c:86) =3D=3D2272=3D=3D by 0x70053514: run_a_thread_NORETURN (syswrap-linux.c:1= 19) =3D=3D2272=3D=3D by 0x70053664: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:206) =3D=3D2272=3D=3D by 0x7005FEBC: (within /usr/local/lib/valgrind/ppc32-li= nux/memcheck) =3D=3D2272=3D=3D by 0x44887A1C: ??? =3D=3D2272=3D=3D by 0x700635F8: myvprintf_str (m_debuglog.c:266) On 1/12/06, Julian Seward <js...@ac...> wrote: > > > I'm not sure if this helps or not but I saw the large range 4294960294 > > before I wrote the ioctl wrappers. > > Ok, so it's a pre-existing bug :-) Perhaps an endianness thing -- the > ppc port hasn't been hammered as much as the x86/amd64 ports. > > > > > =3D=3D1953=3D=3D Warning: set address range perms: large range 4294= 960294, > > We need to know why this happened. Can you find the place this is > printed (mc_main.c, around about line 490) and put "tl_assert(0)" > immediately after it; rebuild; rerun. This should give a backtrace showi= ng > how V got there. My feeling is (and this could be wrong) that once > we know that, the bug should be relatively simple to fix. > > Alternatively .. make a simple C test program which shows the problem > and can be examined at this end. > > J > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Thanks; Logan Gabriel. |
|
From: Julian S. <js...@ac...> - 2006-01-12 11:48:05
|
> I'm not sure if this helps or not but I saw the large range 4294960294 > before I wrote the ioctl wrappers. Ok, so it's a pre-existing bug :-) Perhaps an endianness thing -- the ppc port hasn't been hammered as much as the x86/amd64 ports. > > > ==1953== Warning: set address range perms: large range 4294960294, We need to know why this happened. Can you find the place this is printed (mc_main.c, around about line 490) and put "tl_assert(0)" immediately after it; rebuild; rerun. This should give a backtrace showing how V got there. My feeling is (and this could be wrong) that once we know that, the bug should be relatively simple to fix. Alternatively .. make a simple C test program which shows the problem and can be examined at this end. J |
|
From: Logan G. <log...@gm...> - 2006-01-12 04:27:06
|
I'm not sure if this helps or not but I saw the large range 4294960294
before I wrote the ioctl wrappers. The ioctl wrappers do not actually
use the POST/PRE MEM_WRITE -- the ioctl's
do not actually use (read from or write to) the third param.
The real ioctl's are:
#define XX_IOCTL_1 _IO (0xE7, 0x00)
#define XX_IOCTL_2 _IO (0xE7, 0x01)
#define XX_IOCTL_3 _IO (0xE7, 0x06)
#define XX_IOCTL_4 _IO (0xE7, 0x07)
.... and so on.
The code I added was in:
coregrind/m_syswrap/syswrap-generic.c:
#define VKI_XX_IOCTL_1 _VKI_IO(0xE7, 0x00)
#define VKI_XX_IOCTL_2 _VKI_IO(0xE7, 0x01)
#define VKI_XX_IOCTL_3 _VKI_IO(0xE7, 0x06)
#define VKI_XX_IOCTL_4 _VKI_IO(0xE7, 0x07)
PRE(sys_ioctl)
{
....
switch (ARG2 /* request */) {
case VKI_XX_IOCTL_1:
case VKI_XX_IOCTL_2:
case VKI_XX_IOCTL_3:
case VKI_XX_IOCTL_4:
break;
....
}
However I (just now) noticed that in my haste to leave the office at a
decent hour (before 9pm) I forgot to add cases to POST(sys_ioctl).
Would this still be an issue --- even knowing that the ioctl's do not
read from or write to the third param?
On 1/11/06, Julian Seward <js...@ac...> wrote:
>
> > Memcheck: the 'impossible' happened:
> > create_MAC_Chunk: shadow area is accessible
> > =3D=3D1929=3D=3D at 0x70014FFC: report_and_quit (m_libcassert.c:136)
> > =3D=3D1929=3D=3D by 0x700152E0: panic (m_libcassert.c:209)
>
> is probably a side-effect of
>
> > =3D=3D1953=3D=3D Warning: set address range perms: large range 42949602=
94, a 0, v 0
> > =3D=3D1951=3D=3D Warning: set address range perms: large range 42949602=
94, a 0, v 0
>
> For some reason, valgrind is being told to mark almost the entirety
> of the process' address space as accessible. One place where address
> space permissions are changed is in syscall wrappers.
>
> Note that 4294960294 differs from 2^32 by just 7002 (iow, it's
> (unsigned int)(-7002))). Is it possible that your ioctl wrappers have
> some signedness error which is causing -7002 rather than 7002 to
> be passed as a length in POST_MEM_WRITE (not sure of the name) or similar
> macros in your ioctl wrappers?
>
> J
>
--
Thanks;
Logan Gabriel.
|
|
From: Julian S. <js...@ac...> - 2006-01-12 02:59:02
|
> Memcheck: the 'impossible' happened: > create_MAC_Chunk: shadow area is accessible > ==1929== at 0x70014FFC: report_and_quit (m_libcassert.c:136) > ==1929== by 0x700152E0: panic (m_libcassert.c:209) is probably a side-effect of > ==1953== Warning: set address range perms: large range 4294960294, a 0, v 0 > ==1951== Warning: set address range perms: large range 4294960294, a 0, v 0 For some reason, valgrind is being told to mark almost the entirety of the process' address space as accessible. One place where address space permissions are changed is in syscall wrappers. Note that 4294960294 differs from 2^32 by just 7002 (iow, it's (unsigned int)(-7002))). Is it possible that your ioctl wrappers have some signedness error which is causing -7002 rather than 7002 to be passed as a length in POST_MEM_WRITE (not sure of the name) or similar macros in your ioctl wrappers? J |
|
From: Logan G. <log...@gm...> - 2006-01-12 02:47:47
|
Hello all. I am using valgrind 3.2.0 from SVN as of Friday 01/06/2006 on a PowerPC 440= GP Embedded Processor running kernel Linux 2.4.21. I have built valgrind on the board and am getting the following error when I run a decently heavy multi threaded (30 threads) application. I had to add support for a number of ioctl() calls but that went fairly easily thanks to the documentation -- however I am unable to continue debugging my program past this error. Any help / advice would be greatly appreciated. A strange note. When I build the application statically linked I still see the 'set address range perms' warning message (many many times)but did not get a 'the impossible' happened error -- I also got a (lot) of memory condition warnings but I am almost positive that is because the glibc suppression's are not being used for my statically linked executable. =3D=3D1953=3D=3D Warning: set address range perms: large range 4294960294, = a 0, v 0 =3D=3D1951=3D=3D Warning: set address range perms: large range 4294960294, = a 0, v 0 Memcheck: the 'impossible' happened: create_MAC_Chunk: shadow area is accessible =3D=3D1929=3D=3D at 0x70014FFC: report_and_quit (m_libcassert.c:136) =3D=3D1929=3D=3D by 0x700152E0: panic (m_libcassert.c:209) =3D=3D1929=3D=3D by 0x70015374: vgPlain_tool_panic (m_libcassert.c:224) =3D=3D1929=3D=3D by 0x70001E18: create_MAC_Chunk (mac_malloc_wrappers.c:= 145) =3D=3D1929=3D=3D by 0x700024F0: vgMAC_new_block (mac_malloc_wrappers.c:2= 00) =3D=3D1929=3D=3D by 0x7003DCF8: do_client_request (scheduler.c:984) =3D=3D1929=3D=3D by 0x7003D644: vgPlain_scheduler (scheduler.c:720) =3D=3D1929=3D=3D by 0x70053398: thread_wrapper (syswrap-linux.c:86) =3D=3D1929=3D=3D by 0x700534CC: run_a_thread_NORETURN (syswrap-linux.c:1= 19) =3D=3D1929=3D=3D by 0x7005361C: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:206) =3D=3D1929=3D=3D by 0x7005FE74: (within /usr/local/lib/valgrind/ppc32-li= nux/memcheck) =3D=3D1929=3D=3D by 0x26: ??? =3D=3D1929=3D=3D by 0x444E5CEC: ??? =3D=3D1929=3D=3D by 0x700635B0: myvprintf_str (m_debuglog.c:266) =3D=3D1929=3D=3D by 0x702283F4: ??? =3D=3D1929=3D=3D by 0xB57: ??? =3D=3D1929=3D=3D by 0xFFFFFFFE: ??? =3D=3D1929=3D=3D by 0x438FDC70: ??? =3D=3D1929=3D=3D by 0x28000080: ??? =3D=3D1929=3D=3D by 0x44415D84: ??? =3D=3D1929=3D=3D by 0x444E5CEC: ??? =3D=3D1929=3D=3D by 0x70016584: send_bytes_to_logging_sink (m_libcprint.= c:65) =3D=3D1929=3D=3D by 0x51: ??? -- Thanks; Logan Gabriel. |
|
From: Julian S. <js...@ac...> - 2006-01-12 02:35:15
|
On Wednesday 11 January 2006 16:57, Josef Weidendorfer wrote: > On Wednesday 11 January 2006 17:38, Nicholas Nethercote wrote: > > > Say, after a write, but before the > > > corresponding helper? If yes, does that happen often? > > > > If you're instrumenting the writes as the occur, as you said, then I > > think this case would only occur if the write caused a seg fault > > I am curious: How does valgrind "replay" a memory write after a seg fault > handled in a user signal handler? Does this create a new superblock > starting at the write instruction? Yes. In general the same instruction may be part of many superblocks, not just one. J |
|
From: Josef W. <Jos...@gm...> - 2006-01-11 16:58:26
|
On Wednesday 11 January 2006 17:38, Nicholas Nethercote wrote: > > Say, after a write, but before the > > corresponding helper? If yes, does that happen often? > > If you're instrumenting the writes as the occur, as you said, then I think > this case would only occur if the write caused a seg fault I am curious: How does valgrind "replay" a memory write after a seg fault handled in a user signal handler? Does this create a new superblock starting at the write instruction? Josef |
|
From: Nicholas N. <nj...@cs...> - 2006-01-11 16:38:56
|
On Wed, 11 Jan 2006, Martin Hirzel wrote: > Does control flow ever leave a basic block in the middle for any > reason (e.g. for an exception)? Yes -- they're not basic blocks but "superblocks" which means they can have multiple exits, usually just for normal jumps, but also for more unusual events like exceptions. > Say, after a write, but before the > corresponding helper? If yes, does that happen often? If you're instrumenting the writes as the occur, as you said, then I think this case would only occur if the write caused a seg fault or something similar, so it should be extremely rare. Nick |
|
From: Martin H. <hi...@gm...> - 2006-01-11 16:17:18
|
Does control flow ever leave a basic block in the middle for any reason (e.g. for an exception)? Say, after a write, but before the corresponding helper? If yes, does that happen often? Martin On 1/11/06, Julian Seward <js...@ac...> wrote: > > > In other words: the helper comes after the write, but there may be > > other writes in the middle. > > Ah yes. As Josef points out. > > > I think I'll just eagerly flush the pending helpers after each write. > > That sounds like a good compromise. > > J > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Julian S. <js...@ac...> - 2006-01-11 15:58:28
|
> In other words: the helper comes after the write, but there may be > other writes in the middle. Ah yes. As Josef points out. > I think I'll just eagerly flush the pending helpers after each write. That sounds like a good compromise. J |
|
From: Martin H. <hi...@gm...> - 2006-01-11 15:09:45
|
Hey, thanks for checking that for me!
In other words: the helper comes after the write, but there may be
other writes in the middle.
I think I'll just eagerly flush the pending helpers after each write.
That should avoid the problem you found, while still retaining some of
the benefits of grouping for reads.
Martin
On 1/11/06, Josef Weidendorfer <Jos...@gm...> wrote:
> On Wednesday 11 January 2006 13:56, Julian Seward wrote:
> >
> > > is my question: can I just obtain that by reading the current memory
> > > contents at the given address at the time the instrumentation functio=
n
> > > gets executed? From looking at the source code, I assume that yes,
> > > because the instrumentation appears to be always after (later in the
> > > basic block than) the instruction(s) it instruments. Could someone
> > > please confirm or deny whether I understand the code correctly?
> >
> > I think that's right (not 100% sure). Use --tool=3Dcachegrind
> > --trace-flags=3D10001000 to see the relationship between the initial IR
> > and the instrumented IR. The calls to simulation functions are grouped
> > in sets of up to 8 for efficiency reasons, so the instrumented IR
> > looks a bit strange at first.
>
> Wrong.
>
> I just checked:
>
> int main()
> {
> volatile int a;
> a =3D 3;
> a =3D 5;
> return a;
> }
>
> 08048240 <main>:
> int main()
> {
> 8048240: 55 push %ebp
> 8048241: 89 e5 mov %esp,%ebp
> 8048243: 83 ec 18 sub $0x18,%esp
> 8048246: 83 e4 f0 and $0xfffffff0,%esp
> volatile int a;
>
> a =3D 3;
> 8048249: c7 45 fc 03 00 00 00 movl $0x3,0xfffffffc(%ebp)
> a =3D 5;
> 8048250: c7 45 fc 05 00 00 00 movl $0x5,0xfffffffc(%ebp)
>
> return a;
> 8048257: 8b 45 fc mov 0xfffffffc(%ebp),%eax
> 804825a: 83 ec 10 sub $0x10,%esp
> }
>
> Relevant output of
> valgrind --tool=3Dcachegrind --trace-flags=3D10001000 ./a.out
>
> ------ IMark(0x8048249, 7) ------
> PUT(60) =3D 0x8048249:I32
> t22 =3D Add32(t19,0xFFFFFFFC:I32)
> STle(t22) =3D 0x3:I32
> ------ IMark(0x8048250, 7) ------
> PUT(60) =3D 0x8048250:I32
> t24 =3D Add32(t19,0xFFFFFFFC:I32)
> STle(t24) =3D 0x5:I32
> ------ IMark(0x8048257, 7) ------
> PUT(60) =3D 0x8048257:I32
> t26 =3D Add32(t19,0xFFFFFFFC:I32)
> STle(t26) =3D 0x7:I32
> ------ IMark(0x804825E, 3) ------
> PUT(32) =3D 0x6:I32
> PUT(36) =3D t5
> PUT(40) =3D 0x10:I32
> PUT(44) =3D 0x0:I32
> PUT(16) =3D Sub32(t5,0x10:I32)
> ------ IMark(0x8048261, 3) ------
> PUT(60) =3D 0x8048261:I32
> t28 =3D Add32(t19,0xFFFFFFFC:I32)
> PUT(0) =3D LDle:I32(t28)
> ------ IMark(0x8048264, 1) ------
> PUT(60) =3D 0x8048264:I32
> PUT(16) =3D t19
> PUT(20) =3D LDle:I32(t19)
> t31 =3D Add32(t19,0x4:I32)
> PUT(16) =3D t31
> DIRTY 1:I1 ::: log_1I_1Dw_cache_access[rp=3D3]{0xb0003e4c}(0x61D55E7C:=
I32,t19,0x4:I32)
> DIRTY 1:I1 ::: log_3I_0D_cache_access[rp=3D3]{0xb00019a6}(0x61D55E88:I=
32,0x61D55E94:I32,0x61D55EA0:I32)
> DIRTY 1:I1 ::: log_1I_1Dw_cache_access[rp=3D3]{0xb0003e4c}(0x61D55EAC:=
I32,t22,0x4:I32)
> DIRTY 1:I1 ::: log_1I_1Dw_cache_access[rp=3D3]{0xb0003e4c}(0x61D55EB8:=
I32,t24,0x4:I32)
> DIRTY 1:I1 ::: log_1I_1Dw_cache_access[rp=3D3]{0xb0003e4c}(0x61D55EC4:=
I32,t26,0x4:I32)
> DIRTY 1:I1 ::: log_2I_0D_cache_access[rp=3D2]{0xb0000b00}(0x61D55ED0:I=
32,0x61D55EDC:I32)
> DIRTY 1:I1 ::: log_0I_1Dr_cache_access[rp=3D3]{0xb0004cf0}(0x61D55EDC:=
I32,t28,0x4:I32)
> DIRTY 1:I1 ::: log_1I_1Dr_cache_access[rp=3D3]{0xb0002fa8}(0x61D55EE8:=
I32,t19,0x4:I32)
> ------ IMark(0x8048265, 1) ------
>
> So all the calls are delayed to the end of main.
> The helper has no chance to get at the 3 written first.
>
> Perhaps you should add the read/written value as parameter of the helper.
>
> Josef
>
>
> >
> > J
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
> >
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|