Hi Christoph,

Thanks you so much for your detailed comment. Now I do understand why
Julian was right in his first answer!

The thing is that the boost function internally uses long doubles. The
problem is that the following is zero within valgrind

  std::numeric_limits<long double>::min()

Below is a minimal unit test for this valgrind issue. I guess it is
implicitly mentioned in the documentation
(http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits):

  "Valgrind represents all such "long double" numbers in 64 bits, and
so there may be some differences in results. Whether or not this is
critical remains to be seen"

In this case the difference seems critical to me as it breaks the
semantics of numeric_limits... Maybe a note on numeric_limits<long
double> could be added to the documentation.

It's a pity I will not be able to use valgrind anymore to fix my
software; valgrind had been serving me so good until now.

Thank you all for your feedback,
Tom


/////// Unit test v4 ///////

#include <cassert>
#include <limits>

int main()
{
   // std::numeric_limits<long double>::min() is typically close to
   // 3.3621e-4932
   assert( std::numeric_limits<long double>::min() > 0.0L );
}

/////// End unit test v4 ///////

On Wed, Aug 12, 2009 at 22:58, Christoph
Bartoschek<[email protected]> wrote:
> Hi Tom,
>
> you could ask the boost guys about this, but I think you are out of luck.
>
> The problem is in boost/math/special_functions/detail/bessel_ik.hpp in the
> function CF1_ik.  They set:
>
> T tiny = sqrt(tools::min_value<T>());
>
> Within valgrind tiny is 0.0; out of valgrind it is
> 1.8336038675548471656e-2466. A number that can only be represented by higher
> precision than standard doubles.
>
> Later there are calculations that divide by tiny and result in inv and later
> in NaN.
>
> I say that you are out of luck because of this:
>
> The code is compiled with the assumption that it has the full register size of
> the target. Therefore the compiler chooses versions of the functions that
> exploit the whole precision.
> But you run the code on the limited register size of valgrind which violates
> the assumptions the compiler made on the executing platform.
>
> Maybe there is a real bug in the line sqrt(tools::min_value<T>()); and you
> could ask the boost guy. But I would not bet on it.
>
> To get the code running within valgrind you need to tell the compiler at
> compile time that you will run within valgrind such that the correct
> std::numeric_limits are used. But I do not know whether this is possible at
> all.
>
> Christoph
>
> st 2009 schrieb Tom Vercauteren:
>> Hi David,
>>
>> Thanks for the feedback. I am sorry i missed this type promotion...
>>
>> This leaves me dubious. The double version returns a NaN in valgrind
>> but the float does not. If the problem came from numerical stability,
>> I would have expected the opposite. Outside of valgrind, with or
>> without excess-precision, both options return non-NaN values.
>>
>> To try and make sure excess-precision was turned off outside of
>> valgrind I also tried adding some combination of the following gcc
>> options:
>>
>> -ffloat-store
>> http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options
>>
>> -mpc32
>> -mpc64
>> http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html#i386-and
>>-x86_002d64-Options
>>
>>
>> No matter what combination of options I use the results are the same, e.g.
>>
>> > g++ -mpc64 -ffloat-store -msse2 -mfpmath=sse -O0 -Wall -Wconversion -I
>> > /usr/local/boost_1_39_0/include/boost-1_39/
>> > boost_cyl_bessel_i_valgrind_bug_test.cpp -o
>> > boost_cyl_bessel_i_valgrind_bug_test
>> > ./boost_cyl_bessel_i_valgrind_bug_test
>>
>> passes
>>
>> > valgrind -v ./boost_cyl_bessel_i_valgrind_bug_test
>>
>> fails on the second assert (double version)
>>
>> Tom
>>
>>
>> /////// Unit test v3 ///////
>>
>> #include <boost/math/special_functions/bessel.hpp>
>> int main()
>> {
>>  // boost::math::cyl_bessel_i( 2, 0.82995 ) should be close to 0.0912
>>  assert( isnan( boost::math::cyl_bessel_i( 2.0f, 0.82995f ) ) == 0 );
>>  assert( isnan( boost::math::cyl_bessel_i( 2, 0.82995 ) ) == 0 );
>> }
>>
>> ///// End unit test v3 ////
>>
>> On Wed, Aug 12, 2009 at 18:02, David<[email protected]> wrote:
>> > boost::math::cyl_bessel_i( 2, 0.82995 )
>> >
>> > is actually a function with arguments of type (int, float), which
>> > according to <boost/math/tools/promotion.hpp> will be forwarded to a
>> > function of type double(double, double).  I tried it with
>> >
>> > boost::math::cyl_bessel_i( 2.0f, 0.82995f )
>> >
>> > and it didn't assert in valgrind.
>> >
>> > Tom Vercauteren wrote:
>> >> Hi Julian,
>> >>
>> >> First of thanks for the lightning fast answer!
>> >>
>> >> I am not sure I fully understand why bullet point 8 in
>> >> http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits
>> >> addresses my concern.
>> >>
>> >> If I get it right, it only means that valgrind does not implement
>> >> extended (80bits) precision. This should not be a problem for me. I
>> >> don't expect
>> >>   boost::math::cyl_bessel_i( 2, 0.82995 )
>> >> to provide the exact same result inside and outside of valgrind. I
>> >> just expect them to be somewhat close. My test only checks that the
>> >> returned value is not NaN. This is what is failing in valgrind.
>> >>
>> >> I tried disabling extended precision (outside of valgrind) by adding
>> >> "-msse2 -mfpmath=sse" to my compilation command line. I also tried
>> >> using the float version of  boost::math::cyl_bessel_i
>> >>   boost::math::cyl_bessel_i( 2, 0.82995f )
>> >> The same pattern appears
>> >>
>> >>> g++ -msse2 -mfpmath=sse -O0 -Wall -Wconversion -I
>> >>> /usr/local/boost_1_39_0/include/boost-1_39/
>> >>> boost_cyl_bessel_i_valgrind_bug_test.cpp -o
>> >>> boost_cyl_bessel_i_valgrind_bug_test
>> >>> ./boost_cyl_bessel_i_valgrind_bug_test
>> >>
>> >> pass
>> >>
>> >>> valgrind  ./boost_cyl_bessel_i_valgrind_bug_test
>> >>
>> >> fail
>> >>
>> >>
>> >> Thanks again for the support,
>> >> Tom
>> >>
>> >> /////// New unit test ///////
>> >>
>> >> #include <boost/math/special_functions/bessel.hpp>
>> >> int main()
>> >> {
>> >>   // boost::math::cyl_bessel_i( 2, 0.82995 ) should be close to 0.0912
>> >>   assert( isnan( boost::math::cyl_bessel_i( 2, 0.82995 ) ) == 0 );
>> >>   assert( isnan( boost::math::cyl_bessel_i( 2, 0.82995f ) ) == 0 );
>> >> }
>> >>
>> >> ///// End new unit test ////
>> >>
>> >> On Wed, Aug 12, 2009 at 11:57, Julian Seward<[email protected]> wrote:
>> >>> Known problem.  See
>> >>> http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits
>> >>> bullet point 8 for details.
>> >>>
>> >>> J
>> >>>
>> >>> On Wednesday 12 August 2009, Tom Vercauteren wrote:
>> >>>> Hi all,
>> >>>>
>> >>>> I encountered a strange behavior when using the cyl_bessel_i from
>> >>>> boost:
>> >>>> http://www.boost.org/doc/libs/1_39_0/libs/math/doc/sf_and_dist/html/ma
>> >>>>th_to olkit/special/bessel/mbessel.html
>> >>>>
>> >>>> When running within valgrind, the following code
>> >>>>
>> >>>>   boost::math::cyl_bessel_i( 2, 0.82995 )
>> >>>>
>> >>>> returns a NaN instead of something close to 0.0912 as correctly
>> >>>> returned outside of valgrind. Could this be a valgrind issue, or would
>> >>>> you rather have me report this to the boost mailing list?
>> >>>>
>> >>>> Below is a simple (but requiring boost) unit test for this issue and
>> >>>> some infomation about my setup.
>> >>>>
>> >>>> Thank you for your help.
>> >>>>
>> >>>> Best regards,
>> >>>> Tom Vercauteren
>> >>>>
>> >>>>
>> >>>> /////// Unit test ///////
>> >>>>
>> >>>> #include <boost/math/special_functions/bessel.hpp>
>> >>>> int main()
>> >>>> {
>> >>>>    // boost::math::cyl_bessel_i( 2, 0.82995 ) should be close to
>> >>>> 0.0912 assert( isnan( boost::math::cyl_bessel_i( 2, 0.82995 ) ) == 0
>> >>>> ); }
>> >>>>
>> >>>> ///// End unit test ////
>> >>>>
>> >>>>
>> >>>> ////  Commands I tried ////
>> >>>>
>> >>>>> g++-4.1 -O0 -Wall -Wconversion -I
>> >>>>> /usr/local/boost_1_39_0/include/boost-1_39/
>> >>>>> boost_cyl_bessel_i_valgrind_bug_test.cpp -o
>> >>>>> boost_cyl_bessel_i_valgrind_bug_test
>> >>>>> ./boost_cyl_bessel_i_valgrind_bug_test
>> >>>>
>> >>>> pass
>> >>>>
>> >>>>> valgrind ./boost_cyl_bessel_i_valgrind_bug_test
>> >>>>
>> >>>> fail
>> >>>>
>> >>>>> g++-4.1 -O2 -Wall -Wconversion -I
>> >>>>> /usr/local/boost_1_39_0/include/boost-1_39/
>> >>>>> boost_cyl_bessel_i_valgrind_bug_test.cpp -o
>> >>>>> boost_cyl_bessel_i_valgrind_bug_test
>> >>>>> ./boost_cyl_bessel_i_valgrind_bug_test
>> >>>>
>> >>>> pass
>> >>>>
>> >>>>> valgrind ./boost_cyl_bessel_i_valgrind_bug_test
>> >>>>
>> >>>> fail
>> >>>>
>> >>>>> g++-4.3 -O0 -Wall -Wconversion -I
>> >>>>> /usr/local/boost_1_39_0/include/boost-1_39/
>> >>>>> boost_cyl_bessel_i_valgrind_bug_test.cpp -o
>> >>>>> boost_cyl_bessel_i_valgrind_bug_test
>> >>>>> ./boost_cyl_bessel_i_valgrind_bug_test
>> >>>>
>> >>>> pass
>> >>>>
>> >>>>> valgrind ./boost_cyl_bessel_i_valgrind_bug_test
>> >>>>
>> >>>> fail
>> >>>>
>> >>>>> g++-4.3 -O2 -Wall -Wconversion -I
>> >>>>> /usr/local/boost_1_39_0/include/boost-1_39/
>> >>>>> boost_cyl_bessel_i_valgrind_bug_test.cpp -o
>> >>>>> boost_cyl_bessel_i_valgrind_bug_test
>> >>>>> ./boost_cyl_bessel_i_valgrind_bug_test
>> >>>>
>> >>>> pass
>> >>>>
>> >>>>> valgrind ./boost_cyl_bessel_i_valgrind_bug_test
>> >>>>
>> >>>> fail
>> >>>>
>> >>>> ////  End commands I tried ////
>> >>>>
>> >>>>
>> >>>> /// Version information ///
>> >>>>
>> >>>>> uname -a
>> >>>>
>> >>>> Linux oahu 2.6.28-15-generic #48-Ubuntu SMP Wed Jul 29 08:54:56 UTC
>> >>>> 2009 i686 GNU/Linux
>> >>>>
>> >>>>> g++-4.1 --version
>> >>>>
>> >>>> g++-4.1 (GCC) 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-24ubuntu1)
>> >>>> Copyright (C) 2006 Free Software Foundation, Inc.
>> >>>> This is free software; see the source for copying conditions.  There
>> >>>> is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
>> >>>> PARTICULAR PURPOSE.
>> >>>>
>> >>>>> g++-4.3 --version
>> >>>>
>> >>>> g++-4.3 (Ubuntu 4.3.3-5ubuntu4) 4.3.3
>> >>>> Copyright (C) 2008 Free Software Foundation, Inc.
>> >>>> This is free software; see the source for copying conditions.  There
>> >>>> is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
>> >>>> PARTICULAR PURPOSE.
>> >>>>
>> >>>>> valgrind --version
>> >>>>
>> >>>> valgrind-3.4.1-Debian
>> >>>>
>> >>>> /// End version information ///
>> >>>>
>> >>>>
>> >>>> //// Full valgrind output example ////
>> >>>>
>> >>>>> g++ -O0 -Wall -Wconversion -I
>> >>>>> /usr/local/mkt-dev/install/boost_1_39_0/include/boost-1_39/
>> >>>>> boost_cyl_bessel_i_valgrind_bug_test.cpp -o
>> >>>>> boost_cyl_bessel_i_valgrind_bug_test valgrind -v
>> >>>>> ./boost_cyl_bessel_i_valgrind_bug_test
>> >>>>
>> >>>> ==28028== Memcheck, a memory error detector.
>> >>>> ==28028== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et
>> >>>> al. ==28028== Using LibVEX rev 1884, a library for dynamic binary
>> >>>> translation. ==28028== Copyright (C) 2004-2008, and GNU GPL'd, by
>> >>>> OpenWorks LLP. ==28028== Using valgrind-3.4.1-Debian, a dynamic binary
>> >>>> instrumentation framework.
>> >>>> ==28028== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et
>> >>>> al. ==28028==
>> >>>> --28028-- Command line
>> >>>> --28028--    ./boost_cyl_bessel_i_valgrind_bug_test
>> >>>> --28028-- Startup, with flags:
>> >>>> --28028--    -v
>> >>>> --28028-- Contents of /proc/version:
>> >>>> --28028--   Linux version 2.6.28-15-generic (bui...@rothera) (gcc
>> >>>> version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #48-Ubuntu SMP Wed Jul 29
>> >>>> 08:54:56 UTC 2009
>> >>>> --28028-- Arch and hwcaps: X86, x86-sse1-sse2
>> >>>> --28028-- Page sizes: currently 4096, max supported 4096
>> >>>> --28028-- Valgrind library directory: /usr/lib/valgrind
>> >>>> --28028-- Reading syms from /lib/ld-2.9.so (0x4000000)
>> >>>> --28028-- Reading debug info from /lib/ld-2.9.so ..
>> >>>> --28028-- .. CRC mismatch (computed 049232cc wanted 022486d8)
>> >>>> --28028--    object doesn't have a symbol table
>> >>>> --28028-- Reading syms from
>> >>>> /home/tom/dev/Sandbox/boost_cyl_bessel_i_valgrind_bug_test (0x8048000)
>> >>>> --28028-- Reading syms from /usr/lib/valgrind/x86-linux/memcheck
>> >>>> (0x38000000) --28028--    object doesn't have a dynamic symbol table
>> >>>> --28028-- Reading suppressions file: /usr/lib/valgrind/default.supp
>> >>>> --28028-- Reading syms from
>> >>>> /usr/lib/valgrind/x86-linux/vgpreload_core.so (0x4020000)
>> >>>> --28028-- Reading syms from
>> >>>> /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x4023000)
>> >>>> --28028-- Reading syms from /usr/lib/libstdc++.so.6.0.10 (0x404c000)
>> >>>> --28028-- Reading debug info from /usr/lib/libstdc++.so.6.0.10 ..
>> >>>> --28028-- .. CRC mismatch (computed 87794c5d wanted bcd37461)
>> >>>> --28028--    object doesn't have a symbol table
>> >>>> --28028-- Reading syms from /lib/tls/i686/cmov/libm-2.9.so (0x413b000)
>> >>>> --28028-- Reading debug info from /lib/tls/i686/cmov/libm-2.9.so ..
>> >>>> --28028-- .. CRC mismatch (computed 9d3c94d0 wanted 85a674c7)
>> >>>> --28028--    object doesn't have a symbol table
>> >>>> --28028-- Reading syms from /lib/libgcc_s.so.1 (0x4162000)
>> >>>> --28028-- Reading debug info from /lib/libgcc_s.so.1 ..
>> >>>> --28028-- .. CRC mismatch (computed 224ab3f8 wanted 89276151)
>> >>>> --28028--    object doesn't have a symbol table
>> >>>> --28028-- Reading syms from /lib/tls/i686/cmov/libc-2.9.so (0x4171000)
>> >>>> --28028-- Reading debug info from /lib/tls/i686/cmov/libc-2.9.so ..
>> >>>> --28028-- .. CRC mismatch (computed 7ee64c88 wanted 8d898f0d)
>> >>>> --28028--    object doesn't have a symbol table
>> >>>> --28028-- REDIR: 0x41e8a60 (rindex) redirected to 0x4027330 (rindex)
>> >>>> --28028-- REDIR: 0x41e85e0 (strlen) redirected to 0x40276e0 (strlen)
>> >>>> --28028-- REDIR: 0x41ea850 (memcpy) redirected to 0x4027b50 (memcpy)
>> >>>> --28028-- REDIR: 0x41e8800 (strncmp) redirected to 0x4027950 (strncmp)
>> >>>> --28028-- REDIR: 0x41ea530 (stpcpy) redirected to 0x4028380 (stpcpy)
>> >>>> --28028-- REDIR: 0x41ea3a0 (mempcpy) redirected to 0x4028720 (mempcpy)
>> >>>> --28028-- REDIR: 0x41e4930 (malloc) redirected to 0x4026f20 (malloc)
>> >>>> --28028-- REDIR: 0x41ed390 (strchrnul) redirected to 0x40286c0
>> >>>> (strchrnul) --28028-- REDIR: 0x41e2520 (free) redirected to 0x4025d40
>> >>>> (free) --28028-- REDIR: 0x41ea340 (memset) redirected to 0x40285f0
>> >>>> (memset) --28028-- REDIR: 0x41e4de0 (realloc) redirected to 0x4027030
>> >>>> (realloc) boost_cyl_bessel_i_valgrind_bug_test:
>> >>>> boost_cyl_bessel_i_valgrind_bug_test.cpp:9: int main(): Assertion
>> >>>> `isnan( boost::math::cyl_bessel_i( 2, 0.82995 ) ) == 0' failed.
>> >>>> ==28028==
>> >>>> ==28028== Process terminating with default action of signal 6
>> >>>> (SIGABRT): dumping core
>> >>>> ==28028==    at 0x40007F2: (within /lib/ld-2.9.so)
>> >>>> ==28028==    by 0x419E097: abort (in /lib/tls/i686/cmov/libc-2.9.so)
>> >>>> ==28028==    by 0x41955CD: __assert_fail (in
>> >>>> /lib/tls/i686/cmov/libc-2.9.so) ==28028==    by 0x804AD8F: main (in
>> >>>> /home/tom/dev/Sandbox/boost_cyl_bessel_i_valgrind_bug_test)
>> >>>> ==28028==
>> >>>> ==28028== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from
>> >>>> 1) --28028--
>> >>>> --28028-- supp:     17 Debian libc6 (2.9.x) stripped dynamic linker
>> >>>> ==28028== malloc/free: in use at exit: 0 bytes in 0 blocks.
>> >>>> ==28028== malloc/free: 3 allocs, 3 frees, 569 bytes allocated.
>> >>>> ==28028==
>> >>>> ==28028== All heap blocks were freed -- no leaks are possible.
>> >>>> --28028--  memcheck: sanity checks: 2 cheap, 2 expensive
>> >>>> --28028--  memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
>> >>>> --28028--  memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10
>> >>>> --28028--  memcheck: auxmaps_L2: 0 searches, 0 nodes
>> >>>> --28028--  memcheck: SMs: n_issued      = 11 (176k, 0M)
>> >>>> --28028--  memcheck: SMs: n_deissued    = 0 (0k, 0M)
>> >>>> --28028--  memcheck: SMs: max_noaccess  = 65535 (1048560k, 1023M)
>> >>>> --28028--  memcheck: SMs: max_undefined = 0 (0k, 0M)
>> >>>> --28028--  memcheck: SMs: max_defined   = 40 (640k, 0M)
>> >>>> --28028--  memcheck: SMs: max_non_DSM   = 11 (176k, 0M)
>> >>>> --28028--  memcheck: max sec V bit nodes:    0 (0k, 0M)
>> >>>> --28028--  memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0)
>> >>>> --28028--  memcheck: max shadow mem size:   480k, 0M
>> >>>> --28028-- translate:            fast SP updates identified: 3,175 (
>> >>>> 85.6%) --28028-- translate:   generic_known SP updates identified: 269
>> >>>> (  7.2%) --28028-- translate: generic_unknown SP updates identified:
>> >>>> 264 (  7.1%) --28028--     tt/tc: 5,657 tt lookups requiring 5,794
>> >>>> probes
>> >>>> --28028--     tt/tc: 5,657 fast-cache updates, 2 flushes
>> >>>> --28028--  transtab: new        2,821 (67,794 -> 1,028,579; ratio
>> >>>> 151:10) [0 scs]
>> >>>> --28028--  transtab: dumped     0 (0 -> ??)
>> >>>> --28028--  transtab: discarded  0 (0 -> ??)
>> >>>> --28028-- scheduler: 231,604 jumps (bb entries).
>> >>>> --28028-- scheduler: 2/3,045 major/minor sched events.
>> >>>> --28028--    sanity: 3 cheap, 2 expensive checks.
>> >>>> --28028--    exectx: 769 lists, 466 contexts (avg 0 per list)
>> >>>> --28028--    exectx: 558 searches, 222 full compares (397 per 1000)
>> >>>> --28028--    exectx: 0 cmp2, 38 cmp4, 0 cmpAll
>> >>>> --28028--  errormgr: 6 supplist searches, 6 comparisons during search
>> >>>> --28028--  errormgr: 17 errlist searches, 38 comparisons during search
>> >>>> Aborted
>> >>>>
>> >>>> ----------------------------------------------------------------------
>> >>>>----- --- Let Crystal Reports handle the reporting - Free Crystal
>> >>>> Reports 2008 30-Day trial. Simplify your report design, integration
>> >>>> and deployment - and focus on what you do best, core application
>> >>>> coding. Discover what's new with Crystal Reports now.
>> >>>>  http://p.sf.net/sfu/bobj-july
>> >>>> _______________________________________________
>> >>>> Valgrind-users mailing list
>> >>>> [email protected]
>> >>>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>> >>
>> >> ------------------------------------------------------------------------
>> >>------ Let Crystal Reports handle the reporting - Free Crystal Reports
>> >> 2008 30-Day trial. Simplify your report design, integration and
>> >> deployment - and focus on what you do best, core application coding.
>> >> Discover what's new with Crystal Reports now.
>> >>  http://p.sf.net/sfu/bobj-july
>> >> _______________________________________________
>> >> Valgrind-users mailing list
>> >> [email protected]
>> >> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>> >
>> > -------------------------------------------------------------------------
>> >----- Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> > 30-Day trial. Simplify your report design, integration and deployment -
>> > and focus on what you do best, core application coding. Discover what's
>> > new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> > _______________________________________________
>> > Valgrind-users mailing list
>> > [email protected]
>> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>> ---------------------------------------------------------------------------
>>--- Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day trial. Simplify your report design, integration and deployment - and
>> focus on what you do best, core application coding. Discover what's new
>> with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Valgrind-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to