#$@%#$%!

Ngiler SH3LL 360
: / proc / 1295291 / root / usr / share / doc / valgrind / html /

Information Server
MySQL : ON Perl : OFF CURL : ON WGET : OFF PKEXEC : ON

Directive	Local Value
IP Address	103.154.184.216
System	Linux vps.readyhost.in 4.18.0-553.6.1.el8.x86_64 #1 SMP Thu May 30 04:13:58 UTC 2024 x86_64
User	vaidikupchar
PHP Version	8.3.12
Software	Apache
Doc root	Permission Denied

Edit File : dist.readme-developers.html \| Size : 22.22 KB
<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>6. README_DEVELOPERS</title> <link rel="stylesheet" type="text/css" href="vg_basic.css"> <meta name="generator" content="DocBook XSL Stylesheets Vsnapshot"> <link rel="home" href="index.html" title="Valgrind Documentation"> <link rel="up" href="dist.html" title="Valgrind Distribution Documents"> <link rel="prev" href="dist.readme-missing.html" title="5. README_MISSING_SYSCALL_OR_IOCTL"> <link rel="next" href="dist.readme-packagers.html" title="7. README_PACKAGERS"> </head> <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> <div><table class="nav" width="100%" cellspacing="3" cellpadding="3" border="0" summary="Navigation header"><tr> <td width="22px" align="center" valign="middle"><a accesskey="p" href="dist.readme-missing.html"><img src="images/prev.png" width="18" height="21" border="0" alt="Prev"></a></td> <td width="25px" align="center" valign="middle"><a accesskey="u" href="dist.html"><img src="images/up.png" width="21" height="18" border="0" alt="Up"></a></td> <td width="31px" align="center" valign="middle"><a accesskey="h" href="index.html"><img src="images/home.png" width="27" height="20" border="0" alt="Up"></a></td> <th align="center" valign="middle">Valgrind Distribution Documents</th> <td width="22px" align="center" valign="middle"><a accesskey="n" href="dist.readme-packagers.html"><img src="images/next.png" width="18" height="21" border="0" alt="Next"></a></td> </tr></table></div> <div class="chapter"> <div class="titlepage"><div><div><h1 class="title"> <a name="dist.readme-developers"></a>6. README_DEVELOPERS</h1></div></div></div> <div class="literallayout"><p><br> Building and installing it<br> ~~~~~~~~~~~~~~~~~~~~~~~~~~<br> To build/install from the GIT repository or from a distribution<br> tarball, refer to the section with the same name in README.<br> <br> <br> Building and not installing it<br> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br> To run Valgrind without having to install it, run coregrind/valgrind<br> with the VALGRIND_LIB environment variable set, where <dir> is the root<br> of the source tree (and must be an absolute path). Eg:<br> <br> VALGRIND_LIB=~/grind/head4/.in_place ~/grind/head4/coregrind/valgrind <br> <br> This allows you to compile and run with "make" instead of "make install",<br> saving you time.<br> <br> Or, you can use the 'vg-in-place' script which does that for you.<br> <br> I recommend compiling with "make --quiet" to further reduce the amount of<br> output spewed out during compilation, letting you actually see any errors,<br> warnings, etc.<br> <br> <br> Building a distribution tarball<br> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br> To build a distribution tarball from the valgrind sources:<br> <br> make dist<br> <br> In addition to compiling, linking and packaging everything up, the command<br> will also attempt to build the documentation.<br> <br> If you only want to test whether the generated tarball is complete and runs<br> regression tests successfully, building documentation is not needed.<br> <br> make dist BUILD_ALL_DOCS=no<br> <br> If you insist on building documentation some embarrassing instructions<br> can be found in docs/README.<br> <br> <br> Running the regression tests<br> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br> To build and run all the regression tests, run "make [--quiet] regtest".<br> <br> To run a subset of the regression tests, execute:<br> <br> perl tests/vg_regtest <name><br> <br> where <name> is a directory (all tests within will be run) or a single<br> .vgtest test file, or the name of a program which has a like-named .vgtest<br> file. Eg:<br> <br> perl tests/vg_regtest memcheck<br> perl tests/vg_regtest memcheck/tests/badfree.vgtest<br> perl tests/vg_regtest memcheck/tests/badfree<br> <br> <br> Running the performance tests<br> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br> To build and run all the performance tests, run "make [--quiet] perf".<br> <br> To run a subset of the performance suite, execute:<br> <br> perl perf/vg_perf <name><br> <br> where <name> is a directory (all tests within will be run) or a single<br> .vgperf test file, or the name of a program which has a like-named .vgperf<br> file. Eg:<br> <br> perl perf/vg_perf perf/<br> perl perf/vg_perf perf/bz2.vgperf<br> perl perf/vg_perf perf/bz2<br> <br> To compare multiple versions of Valgrind, use the --vg= option multiple<br> times. For example, if you have two Valgrinds next to each other, one in<br> trunk1/ and one in trunk2/, from within either trunk1/ or trunk2/ do this to<br> compare them on all the performance tests:<br> <br> perl perf/vg_perf --vg=../trunk1 --vg=../trunk2 perf/<br> <br> <br> Commit access and try branches<br> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br> To get commit access to the valgrind git repository on sourceware<br> you will have to ask an existing developer and fill in the following<br> form: https://sourceware.org/cgi-bin/pdw/ps_form.cgi<br> <br> Every developer with commit access can use try branches. If you want to try a<br> branch before pushing you can push to a special named try branch as follows: <br> <br> git push origin $BRANCH:users/$USERNAME/try-$BRANCH<br> <br> Where $BRANCH is the branch name and $USERNAME is your user name.<br> <br> You can see the status of the builders here:<br> https://builder.sourceware.org/buildbot/#/builders?tags=valgrind-try<br> <br> The buildbot will also sent the patch author multiple success/failure emails.<br> <br> Afterwards you can delete the branch again:<br> <br> git push origin :users/$USERNAME/try-$BRANCH<br> <br> <br> Debugging Valgrind with GDB<br> ~~~~~~~~~~~~~~~~~~~~~~~~~~~<br> To debug the valgrind launcher program (<prefix>/bin/valgrind) just<br> run it under gdb in the normal way.<br> <br> Debugging the main body of the valgrind code (and/or the code for<br> a particular tool) requires a bit more trickery but can be achieved<br> without too much problem by following these steps:<br> <br> (1) Set VALGRIND_LAUNCHER to point to the valgrind executable. Eg:<br> <br> export VALGRIND_LAUNCHER=/usr/local/bin/valgrind<br> <br> or for an uninstalled version in a source directory $DIR:<br> <br> export VALGRIND_LAUNCHER=$DIR/coregrind/valgrind<br> export VALGRIND_LIB=$DIR/.in_place<br> <br> VALGRIND_LIB is where the default.supp and vgpreload_ libraries<br> are found (which is under /usr/libexec/valgrind for an installed<br> version).<br> <br> (2) Run gdb on the tool executable. Eg:<br> <br> gdb /usr/local/lib/valgrind/lackey-ppc32-linux<br> <br> or<br> <br> gdb $DIR/.in_place/memcheck-x86-linux<br> <br> (3) Do "handle SIGSEGV SIGILL nostop noprint" in GDB to prevent GDB from<br> stopping on a SIGSEGV or SIGILL:<br> <br> (gdb) handle SIGILL SIGSEGV nostop noprint<br> <br> If you are using lldb, then the equivalent command is<br> <br> (lldb) pro hand -p true -s false -n false SIGILL SIGSEGV<br> <br> (4) Set any breakpoints you want and proceed as normal for gdb. The<br> macro VG_(FUNC) is expanded to vgPlain_FUNC, so If you want to set<br> a breakpoint VG_(do_exec), you could do like this in GDB:<br> <br> (gdb) b vgPlain_do_exec<br> <br> (5) Run the tool with required options (the --tool option is required<br> for correct setup), e.g.<br> <br> (gdb) run --tool=lackey pwd<br> <br> Steps (1)--(3) can be put in a .gdbinit file, but any directory names must<br> be fully expanded (ie. not an environment variable).<br> <br> A different and possibly easier way is as follows:<br> <br> (1) Run Valgrind as normal, but add the flag --wait-for-gdb=yes. This<br> puts the tool executable into a wait loop soon after it gains<br> control. This delays startup for a few seconds.<br> <br> (2) In a different shell, do "gdb /proc/<pid>/exe <pid>", where<br> <pid> you read from the output printed by (1). This attaches<br> GDB to the tool executable, which should be in the above mentioned<br> wait loop.<br> <br> (3) Do "cont" to continue. After the loop finishes spinning, startup<br> will continue as normal. Note that comment (3) above re passing<br> signals applies here too.<br> <br> The default build of Valgrind uses "-g -O2". This is OK most of the<br> time, but with sophisticated optimization it can be difficult to<br> see the contents of variables. A quick way to get to see function<br> variables is to temporarily add "__attribute__((optnone))" before<br> the function definition and rebuild. Alternatively modify<br> Makefile.all.am and remove -O2 from AM_CFLAGS_BASE. That will<br> require you to reconfigure and rebuild Valgrind.<br> <br> Self-hosting<br> ~~~~~~~~~~~~<br> This section explains:<br> (A) How to configure Valgrind to run under Valgrind.<br> Such a setup is called self hosting, or outer/inner setup.<br> (B) How to run Valgrind regression tests in a 'self-hosting' mode,<br> e.g. to verify Valgrind has no bugs such as memory leaks.<br> (C) How to run Valgrind performance tests in a 'self-hosting' mode,<br> to analyse and optimise the performance of Valgrind and its tools.<br> <br> (A) How to configure Valgrind to run under Valgrind:<br> <br> (1) Check out 2 trees, "Inner" and "Outer". Inner runs the app<br> directly. Outer runs Inner.<br> <br> (2) Configure Inner with --enable-inner and build as usual.<br> <br> (3) Configure Outer normally and build+install as usual.<br> Note: You must use a "make install"-ed valgrind.<br> Do not use vg-in-place for the Outer valgrind.<br> <br> (4) Choose a very simple program (date) and try<br> <br> outer/.../bin/valgrind --sim-hints=enable-outer --trace-children=yes \<br> --smc-check=all-non-file \<br> --run-libc-freeres=no --tool=cachegrind -v \<br> inner/.../vg-in-place --vgdb-prefix=./inner --tool=none -v prog<br> <br> If you omit the --trace-children=yes, you'll only monitor Inner's launcher<br> program, not its stage2. Outer needs --run-libc-freeres=no, as otherwise<br> it will try to find and run __libc_freeres in the inner, while libc is not<br> used by the inner. Inner needs --vgdb-prefix=./inner to avoid inner<br> gdbserver colliding with outer gdbserver.<br> Currently, inner does not use the client request <br> VALGRIND_DISCARD_TRANSLATIONS for the JITted code or the code patched for<br> translation chaining. So the outer needs --smc-check=all-non-file to<br> detect the modified code.<br> <br> Debugging the whole thing might imply to use up to 3 GDB:<br> * a GDB attached to the Outer valgrind, allowing<br> to examine the state of Outer.<br> * a GDB using Outer gdbserver, allowing to<br> examine the state of Inner.<br> * a GDB using Inner gdbserver, allowing to<br> examine the state of prog.<br> <br> The whole thing is fragile, confusing and slow, but it does work well enough<br> for you to get some useful performance data. Inner has most of<br> its output (ie. those lines beginning with "==<pid>==") prefixed with a '>',<br> which helps a lot. However, when running regression tests in an Outer/Inner<br> setup, this prefix causes the reg test diff to fail. Give <br> --sim-hints=no-inner-prefix to the Inner to disable the production<br> of the prefix in the stdout/stderr output of Inner.<br> <br> The allocators in coregrind/m_mallocfree.c and VEX/priv/main_util.h are<br> annotated with client requests so Memcheck can be used to find leaks<br> and use after free in an Inner Valgrind.<br> <br> The Valgrind "big lock" is annotated with helgrind client requests<br> so Helgrind and DRD can be used to find race conditions in an Inner<br> Valgrind.<br> <br> All this has not been tested much, so don't be surprised if you hit problems.<br> <br> When using self-hosting with an outer Callgrind tool, use '--pop-on-jump'<br> (on the outer). Otherwise, Callgrind has much higher memory requirements. <br> <br> (B) Regression tests in an outer/inner setup:<br> <br> To run all the regression tests with an outer memcheck, do :<br> perl tests/vg_regtest --outer-valgrind=../outer/.../bin/valgrind \<br> --all<br> <br> To run a specific regression tests with an outer memcheck, do:<br> perl tests/vg_regtest --outer-valgrind=../outer/.../bin/valgrind \<br> none/tests/args.vgtest<br> <br> To run regression tests with another outer tool:<br> perl tests/vg_regtest --outer-valgrind=../outer/.../bin/valgrind \<br> --outer-tool=helgrind --all<br> <br> --outer-args allows to give specific arguments to the outer tool,<br> replacing the default one provided by vg_regtest.<br> <br> Note: --outer-valgrind must be a "make install"-ed valgrind.<br> Do not use vg-in-place.<br> <br> When an outer valgrind runs an inner valgrind, a regression test<br> produces one additional file <testname>.outer.log which contains the<br> errors detected by the outer valgrind. E.g. for an outer memcheck, it<br> contains the leaks found in the inner, for an outer helgrind or drd,<br> it contains the detected race conditions.<br> <br> The file tests/outer_inner.supp contains suppressions for <br> the irrelevant or benign errors found in the inner.<br> <br> A regression test running in the inner (e.g. memcheck/tests/badrw) will<br> cause the inner to report an error, which is expected and checked<br> as usual when running the regtests in an outer/inner setup.<br> However, the outer will often also observe an error, e.g. a jump<br> using uninitialised data, or a read/write outside the bounds of a heap<br> block. When the outer reports such an error, it will output the<br> inner host stacktrace. To this stacktrace, it will append the<br> stacktrace of the inner guest program. For example, this is an error<br> reported by the outer when the inner runs the badrw regtest:<br> ==8119== Invalid read of size 2<br> ==8119== at 0x7F2EFD7AF: ???<br> ==8119== by 0x7F2C82EAF: ???<br> ==8119== by 0x7F180867F: ???<br> ==8119== by 0x40051D: main (badrw.c:5)<br> ==8119== by 0x7F180867F: ???<br> ==8119== by 0x1BFF: ???<br> ==8119== by 0x3803B7F0: _______VVVVVVVV_appended_inner_guest_stack_VVVVVVVV_______ (m_execontext.c:332)<br> ==8119== by 0x40055C: main (badrw.c:22)<br> ==8119== Address 0x55cd03c is 4 bytes before a block of size 16 alloc'd<br> ==8119== at 0x2804E26D: vgPlain_arena_malloc (m_mallocfree.c:1914)<br> ==8119== by 0x2800BAB4: vgMemCheck_new_block (mc_malloc_wrappers.c:368)<br> ==8119== by 0x2800BC87: vgMemCheck_malloc (mc_malloc_wrappers.c:403)<br> ==8119== by 0x28097EAE: do_client_request (scheduler.c:1861)<br> ==8119== by 0x28097EAE: vgPlain_scheduler (scheduler.c:1425)<br> ==8119== by 0x280A7237: thread_wrapper (syswrap-linux.c:103)<br> ==8119== by 0x280A7237: run_a_thread_NORETURN (syswrap-linux.c:156)<br> ==8119== by 0x3803B7F0: _______VVVVVVVV_appended_inner_guest_stack_VVVVVVVV_______ (m_execontext.c:332)<br> ==8119== by 0x4C294C4: malloc (vg_replace_malloc.c:298)<br> ==8119== by 0x40051D: main (badrw.c:5)<br> In the above, the first stacktrace starts with the inner host stacktrace,<br> which in this case is some JITted code. Such code sometimes contains IPs<br> that points in the inner guest code (0x40051D: main (badrw.c:5)).<br> After the separator, we have the inner guest stacktrace.<br> The second stacktrace gives the stacktrace where the heap block that was<br> overrun was allocated. We see it was allocated by the inner valgrind<br> in the client arena (first part of the stacktrace). The second part is<br> the guest stacktrace that did the allocation.<br> <br> <br> (C) Performance tests in an outer/inner setup:<br> <br> To run all the performance tests with an outer cachegrind, do :<br> perl perf/vg_perf --outer-valgrind=../outer/.../bin/valgrind perf<br> <br> To run a specific perf test (e.g. bz2) in this setup, do :<br> perl perf/vg_perf --outer-valgrind=../outer/.../bin/valgrind perf/bz2<br> <br> To run all the performance tests with an outer callgrind, do :<br> perl perf/vg_perf --outer-valgrind=../outer/.../bin/valgrind \<br> --outer-tool=callgrind perf<br> <br> Note: --outer-valgrind must be a "make install"-ed valgrind.<br> Do not use vg-in-place.<br> <br> To compare the performance of multiple Valgrind versions, do :<br> perl perf/vg_perf --outer-valgrind=../outer/.../bin/valgrind \<br> --outer-tool=callgrind \<br> --vg=../inner_xxxx --vg=../inner_yyyy perf<br> (where inner_xxxx and inner_yyyy are the toplevel directories of<br> the versions to compare).<br> Cachegrind and cg_diff are particularly handy to obtain a delta<br> between the two versions.<br> <br> When the outer tool is callgrind or cachegrind, the following<br> output files will be created for each test:<br> <outertoolname>.out.<inner_valgrind_dir>.<tt>.<perftestname>.<pid><br> <outertoolname>.outer.log.<inner_valgrind_dir>.<tt>.<perftestname>.<pid><br> (where tt is the two letters abbreviation for the inner tool(s) run).<br> <br> For example, the command<br> perl perf/vg_perf \<br> --outer-valgrind=../outer_trunk/install/bin/valgrind \<br> --outer-tool=callgrind \<br> --vg=../inner_tchain --vg=../inner_trunk perf/many-loss-records<br> <br> produces the files<br> callgrind.out.inner_tchain.no.many-loss-records.18465<br> callgrind.outer.log.inner_tchain.no.many-loss-records.18465<br> callgrind.out.inner_tchain.me.many-loss-records.21899<br> callgrind.outer.log.inner_tchain.me.many-loss-records.21899<br> callgrind.out.inner_trunk.no.many-loss-records.21224<br> callgrind.outer.log.inner_trunk.no.many-loss-records.21224<br> callgrind.out.inner_trunk.me.many-loss-records.22916<br> callgrind.outer.log.inner_trunk.me.many-loss-records.22916<br> <br> <br> Printing out problematic blocks<br> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br> If you want to print out a disassembly of a particular block that<br> causes a crash, do the following.<br> <br> Try running with "--vex-guest-chase=no --trace-flags=10000000<br> --trace-notbelow=999999". This should print one line for each block<br> translated, and that includes the address.<br> <br> Then re-run with 999999 changed to the highest bb number shown.<br> This will print the one line per block, and also will print a<br> disassembly of the block in which the fault occurred.<br> <br> <br> Formatting the code with clang-format<br> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br> clang-format is a tool to format C/C++/... code. The root directory of the<br> Valgrind tree contains file .clang-format which is a configuration for this tool<br> and specifies a style for Valgrind. This gives you an option to use<br> clang-format to easily format Valgrind code which you are modifying.<br> <br> The Valgrind codebase is not globally formatted with clang-format. It means<br> that you should not use the tool to format a complete file after making changes<br> in it because that would lead to creating unrelated modifications.<br> <br> The right approach is to format only updated or new code. By using an<br> integration with a text editor, it is possible to reformat arbitrary blocks<br> of code with a single keystroke. Refer to the upstream documentation which<br> describes integration with various editors and IDEs:<br> https://clang.llvm.org/docs/ClangFormat.html.<br> <br> </p></div> </div> <div> <br><table class="nav" width="100%" cellspacing="3" cellpadding="2" border="0" summary="Navigation footer"> <tr> <td rowspan="2" width="40%" align="left"> <a accesskey="p" href="dist.readme-missing.html"><< 5. README_MISSING_SYSCALL_OR_IOCTL</a> </td> <td width="20%" align="center"><a accesskey="u" href="dist.html">Up</a></td> <td rowspan="2" width="40%" align="right"> <a accesskey="n" href="dist.readme-packagers.html">7. README_PACKAGERS >></a> </td> </tr> <tr><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td></tr> </table> </div> </body> </html> Back

Edit File : dist.readme-developers.html | Size : 22.22 KB

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>6. README_DEVELOPERS</title>
<link rel="stylesheet" type="text/css" href="vg_basic.css">
<meta name="generator" content="DocBook XSL Stylesheets Vsnapshot">
<link rel="home" href="index.html" title="Valgrind Documentation">
<link rel="up" href="dist.html" title="Valgrind Distribution Documents">
<link rel="prev" href="dist.readme-missing.html" title="5. README_MISSING_SYSCALL_OR_IOCTL">
<link rel="next" href="dist.readme-packagers.html" title="7. README_PACKAGERS">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div><table class="nav" width="100%" cellspacing="3" cellpadding="3" border="0" summary="Navigation header"><tr>
<td width="22px" align="center" valign="middle"><a accesskey="p" href="dist.readme-missing.html"><img src="images/prev.png" width="18" height="21" border="0" alt="Prev"></a></td>
<td width="25px" align="center" valign="middle"><a accesskey="u" href="dist.html"><img src="images/up.png" width="21" height="18" border="0" alt="Up"></a></td>
<td width="31px" align="center" valign="middle"><a accesskey="h" href="index.html"><img src="images/home.png" width="27" height="20" border="0" alt="Up"></a></td>
<th align="center" valign="middle">Valgrind Distribution Documents</th>
<td width="22px" align="center" valign="middle"><a accesskey="n" href="dist.readme-packagers.html"><img src="images/next.png" width="18" height="21" border="0" alt="Next"></a></td>
</tr></table></div>
<div class="chapter">
<div class="titlepage"><div><div><h1 class="title">
<a name="dist.readme-developers"></a>6. README_DEVELOPERS</h1></div></div></div>
<div class="literallayout"> 
      Building and installing it 
~~~~~~~~~~~~~~~~~~~~~~~~~~ 
To build/install from the GIT repository or from a distribution 
tarball, refer to the section with the same name in README. 
 
 
Building and not installing it 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
To run Valgrind without having to install it, run coregrind/valgrind 
with the VALGRIND_LIB environment variable set, where &lt;dir&gt; is the root 
of the source tree (and must be an absolute path).  Eg: 
 
  VALGRIND_LIB=~/grind/head4/.in_place ~/grind/head4/coregrind/valgrind  
 
This allows you to compile and run with "make" instead of "make install", 
saving you time. 
 
Or, you can use the 'vg-in-place' script which does that for you. 
 
I recommend compiling with "make --quiet" to further reduce the amount of 
output spewed out during compilation, letting you actually see any errors, 
warnings, etc. 
 
 
Building a distribution tarball 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
To build a distribution tarball from the valgrind sources: 
 
  make dist 
 
In addition to compiling, linking and packaging everything up, the command 
will also attempt to build the documentation. 
 
If you only want to test whether the generated tarball is complete and runs 
regression tests successfully, building documentation is not needed. 
 
  make dist BUILD_ALL_DOCS=no 
 
If you insist on building documentation some embarrassing instructions 
can be found in docs/README. 
 
 
Running the regression tests 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
To build and run all the regression tests, run "make [--quiet] regtest". 
 
To run a subset of the regression tests, execute: 
 
  perl tests/vg_regtest &lt;name&gt; 
 
where &lt;name&gt; is a directory (all tests within will be run) or a single 
.vgtest test file, or the name of a program which has a like-named .vgtest 
file.  Eg: 
 
  perl tests/vg_regtest memcheck 
  perl tests/vg_regtest memcheck/tests/badfree.vgtest 
  perl tests/vg_regtest memcheck/tests/badfree 
 
 
Running the performance tests 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
To build and run all the performance tests, run "make [--quiet] perf". 
 
To run a subset of the performance suite, execute: 
 
  perl perf/vg_perf &lt;name&gt; 
 
where &lt;name&gt; is a directory (all tests within will be run) or a single 
.vgperf test file, or the name of a program which has a like-named .vgperf 
file.  Eg: 
 
  perl perf/vg_perf perf/ 
  perl perf/vg_perf perf/bz2.vgperf 
  perl perf/vg_perf perf/bz2 
 
To compare multiple versions of Valgrind, use the --vg= option multiple 
times.  For example, if you have two Valgrinds next to each other, one in 
trunk1/ and one in trunk2/, from within either trunk1/ or trunk2/ do this to 
compare them on all the performance tests: 
 
  perl perf/vg_perf --vg=../trunk1 --vg=../trunk2 perf/ 
 
 
Commit access and try branches 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
To get commit access to the valgrind git repository on sourceware 
you will have to ask an existing developer and fill in the following 
form: https://sourceware.org/cgi-bin/pdw/ps_form.cgi 
 
Every developer with commit access can use try branches. If you want to try a 
branch before pushing you can push to a special named try branch as follows:  
 
  git push origin $BRANCH:users/$USERNAME/try-$BRANCH 
 
Where $BRANCH is the branch name and $USERNAME is your user name. 
 
You can see the status of the builders here: 
https://builder.sourceware.org/buildbot/#/builders?tags=valgrind-try 
 
The buildbot will also sent the patch author multiple success/failure emails. 
 
Afterwards you can delete the branch again: 
 
    git push origin :users/$USERNAME/try-$BRANCH 
 
 
Debugging Valgrind with GDB 
~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
To debug the valgrind launcher program (&lt;prefix&gt;/bin/valgrind) just 
run it under gdb in the normal way. 
 
Debugging the main body of the valgrind code (and/or the code for 
a particular tool) requires a bit more trickery but can be achieved 
without too much problem by following these steps: 
 
(1) Set VALGRIND_LAUNCHER to point to the valgrind executable.  Eg: 
 
      export VALGRIND_LAUNCHER=/usr/local/bin/valgrind 
 
    or for an uninstalled version in a source directory $DIR: 
 
      export VALGRIND_LAUNCHER=$DIR/coregrind/valgrind 
      export VALGRIND_LIB=$DIR/.in_place 
 
    VALGRIND_LIB is where the default.supp and vgpreload_ libraries 
    are found (which is under /usr/libexec/valgrind for an installed 
    version). 
 
(2) Run gdb on the tool executable.  Eg: 
 
      gdb /usr/local/lib/valgrind/lackey-ppc32-linux 
 
    or 
 
      gdb $DIR/.in_place/memcheck-x86-linux 
 
(3) Do "handle SIGSEGV SIGILL nostop noprint" in GDB to prevent GDB from 
    stopping on a SIGSEGV or SIGILL: 
 
    (gdb) handle SIGILL SIGSEGV nostop noprint 
 
    If you are using lldb, then the equivalent command is 
 
    (lldb) pro hand -p true -s false -n false SIGILL SIGSEGV 
 
(4) Set any breakpoints you want and proceed as normal for gdb. The 
    macro VG_(FUNC) is expanded to vgPlain_FUNC, so If you want to set 
    a breakpoint VG_(do_exec), you could do like this in GDB: 
 
    (gdb) b vgPlain_do_exec 
 
(5) Run the tool with required options (the --tool option is required 
    for correct setup), e.g. 
 
    (gdb) run --tool=lackey pwd 
 
Steps (1)--(3) can be put in a .gdbinit file, but any directory names must 
be fully expanded (ie. not an environment variable). 
 
A different and possibly easier way is as follows: 
 
(1) Run Valgrind as normal, but add the flag --wait-for-gdb=yes.  This 
    puts the tool executable into a wait loop soon after it gains 
    control.  This delays startup for a few seconds. 
 
(2) In a different shell, do "gdb /proc/&lt;pid&gt;/exe &lt;pid&gt;", where 
    &lt;pid&gt; you read from the output printed by (1).  This attaches 
    GDB to the tool executable, which should be in the above mentioned 
    wait loop. 
 
(3) Do "cont" to continue.  After the loop finishes spinning, startup 
    will continue as normal.  Note that comment (3) above re passing 
    signals applies here too. 
 
The default build of Valgrind uses "-g -O2". This is OK most of the 
time, but with sophisticated optimization it can be difficult to 
see the contents of variables. A quick way to get to see function 
variables is to temporarily add "__attribute__((optnone))" before 
the function definition and rebuild. Alternatively modify 
Makefile.all.am and remove -O2 from AM_CFLAGS_BASE. That will 
require you to reconfigure and rebuild Valgrind. 
 
Self-hosting 
~~~~~~~~~~~~ 
This section explains: 
  (A) How to configure Valgrind to run under Valgrind. 
      Such a setup is called self hosting, or outer/inner setup. 
  (B) How to run Valgrind regression tests in a 'self-hosting' mode, 
      e.g. to verify Valgrind has no bugs such as memory leaks. 
  (C) How to run Valgrind performance tests in a 'self-hosting' mode, 
      to analyse and optimise the performance of Valgrind and its tools. 
 
(A) How to configure Valgrind to run under Valgrind: 
 
(1) Check out 2 trees, "Inner" and "Outer".  Inner runs the app 
    directly.  Outer runs Inner. 
 
(2) Configure Inner with --enable-inner and build as usual. 
 
(3) Configure Outer normally and build+install as usual. 
    Note: You must use a "make install"-ed valgrind. 
    Do *not* use vg-in-place for the Outer valgrind. 
 
(4) Choose a very simple program (date) and try 
 
    outer/.../bin/valgrind --sim-hints=enable-outer --trace-children=yes  \ 
       --smc-check=all-non-file \ 
       --run-libc-freeres=no --tool=cachegrind -v \ 
       inner/.../vg-in-place --vgdb-prefix=./inner --tool=none -v prog 
 
If you omit the --trace-children=yes, you'll only monitor Inner's launcher 
program, not its stage2. Outer needs --run-libc-freeres=no, as otherwise 
it will try to find and run __libc_freeres in the inner, while libc is not 
used by the inner. Inner needs --vgdb-prefix=./inner to avoid inner 
gdbserver colliding with outer gdbserver. 
Currently, inner does *not* use the client request  
VALGRIND_DISCARD_TRANSLATIONS for the JITted code or the code patched for 
translation chaining. So the outer needs --smc-check=all-non-file to 
detect the modified code. 
 
Debugging the whole thing might imply to use up to 3 GDB: 
  * a GDB attached to the Outer valgrind, allowing 
    to examine the state of Outer. 
  * a GDB using Outer gdbserver, allowing to 
    examine the state of Inner. 
  * a GDB using Inner gdbserver, allowing to 
    examine the state of prog. 
 
The whole thing is fragile, confusing and slow, but it does work well enough 
for you to get some useful performance data.  Inner has most of 
its output (ie. those lines beginning with "==&lt;pid&gt;==") prefixed with a '&gt;', 
which helps a lot. However, when running regression tests in an Outer/Inner 
setup, this prefix causes the reg test diff to fail. Give  
--sim-hints=no-inner-prefix to the Inner to disable the production 
of the prefix in the stdout/stderr output of Inner. 
 
The allocators in coregrind/m_mallocfree.c and VEX/priv/main_util.h are 
annotated with client requests so Memcheck can be used to find leaks 
and use after free in an Inner Valgrind. 
 
The Valgrind "big lock" is annotated with helgrind client requests 
so Helgrind and DRD can be used to find race conditions in an Inner 
Valgrind. 
 
All this has not been tested much, so don't be surprised if you hit problems. 
 
When using self-hosting with an outer Callgrind tool, use '--pop-on-jump' 
(on the outer). Otherwise, Callgrind has much higher memory requirements.  
 
(B) Regression tests in an outer/inner setup: 
 
 To run all the regression tests with an outer memcheck, do : 
   perl tests/vg_regtest --outer-valgrind=../outer/.../bin/valgrind \ 
                         --all 
 
 To run a specific regression tests with an outer memcheck, do: 
   perl tests/vg_regtest --outer-valgrind=../outer/.../bin/valgrind \ 
                         none/tests/args.vgtest 
 
 To run regression tests with another outer tool: 
   perl tests/vg_regtest --outer-valgrind=../outer/.../bin/valgrind \ 
                         --outer-tool=helgrind --all 
 
 --outer-args allows to give specific arguments to the outer tool, 
 replacing the default one provided by vg_regtest. 
 
Note: --outer-valgrind must be a "make install"-ed valgrind. 
Do *not* use vg-in-place. 
 
When an outer valgrind runs an inner valgrind, a regression test 
produces one additional file &lt;testname&gt;.outer.log which contains the 
errors detected by the outer valgrind.  E.g. for an outer memcheck, it 
contains the leaks found in the inner, for an outer helgrind or drd, 
it contains the detected race conditions. 
 
The file tests/outer_inner.supp contains suppressions for  
the irrelevant or benign errors found in the inner. 
 
A regression test running in the inner (e.g. memcheck/tests/badrw) will 
cause the inner to report an error, which is expected and checked 
as usual when running the regtests in an outer/inner setup. 
However, the outer will often also observe an error, e.g. a jump 
using uninitialised data, or a read/write outside the bounds of a heap 
block. When the outer reports such an error, it will output the 
inner host stacktrace. To this stacktrace, it will append the 
stacktrace of the inner guest program. For example, this is an error 
reported by the outer when the inner runs the badrw regtest: 
  ==8119== Invalid read of size 2 
  ==8119==    at 0x7F2EFD7AF: ??? 
  ==8119==    by 0x7F2C82EAF: ??? 
  ==8119==    by 0x7F180867F: ??? 
  ==8119==    by 0x40051D: main (badrw.c:5) 
  ==8119==    by 0x7F180867F: ??? 
  ==8119==    by 0x1BFF: ??? 
  ==8119==    by 0x3803B7F0: _______VVVVVVVV_appended_inner_guest_stack_VVVVVVVV_______ (m_execontext.c:332) 
  ==8119==    by 0x40055C: main (badrw.c:22) 
  ==8119==  Address 0x55cd03c is 4 bytes before a block of size 16 alloc'd 
  ==8119==    at 0x2804E26D: vgPlain_arena_malloc (m_mallocfree.c:1914) 
  ==8119==    by 0x2800BAB4: vgMemCheck_new_block (mc_malloc_wrappers.c:368) 
  ==8119==    by 0x2800BC87: vgMemCheck_malloc (mc_malloc_wrappers.c:403) 
  ==8119==    by 0x28097EAE: do_client_request (scheduler.c:1861) 
  ==8119==    by 0x28097EAE: vgPlain_scheduler (scheduler.c:1425) 
  ==8119==    by 0x280A7237: thread_wrapper (syswrap-linux.c:103) 
  ==8119==    by 0x280A7237: run_a_thread_NORETURN (syswrap-linux.c:156) 
  ==8119==    by 0x3803B7F0: _______VVVVVVVV_appended_inner_guest_stack_VVVVVVVV_______ (m_execontext.c:332) 
  ==8119==    by 0x4C294C4: malloc (vg_replace_malloc.c:298) 
  ==8119==    by 0x40051D: main (badrw.c:5) 
In the above, the first stacktrace starts with the inner host stacktrace, 
which in this case is some JITted code. Such code sometimes contains IPs 
that points in the inner guest code (0x40051D: main (badrw.c:5)). 
After the separator, we have the inner guest stacktrace. 
The second stacktrace gives the stacktrace where the heap block that was 
overrun was allocated. We see it was allocated by the inner valgrind 
in the client arena (first part of the stacktrace). The second part is 
the guest stacktrace that did the allocation. 
 
 
(C) Performance tests in an outer/inner setup: 
 
 To run all the performance tests with an outer cachegrind, do : 
    perl perf/vg_perf --outer-valgrind=../outer/.../bin/valgrind perf 
 
 To run a specific perf test (e.g. bz2) in this setup, do : 
    perl perf/vg_perf --outer-valgrind=../outer/.../bin/valgrind perf/bz2 
 
 To run all the performance tests with an outer callgrind, do : 
    perl perf/vg_perf --outer-valgrind=../outer/.../bin/valgrind \ 
                      --outer-tool=callgrind perf 
 
Note: --outer-valgrind must be a "make install"-ed valgrind. 
Do *not* use vg-in-place. 
 
 To compare the performance of multiple Valgrind versions, do : 
    perl perf/vg_perf --outer-valgrind=../outer/.../bin/valgrind \ 
      --outer-tool=callgrind \ 
      --vg=../inner_xxxx --vg=../inner_yyyy perf 
  (where inner_xxxx and inner_yyyy are the toplevel directories of 
  the versions to compare). 
  Cachegrind and cg_diff are particularly handy to obtain a delta 
  between the two versions. 
 
When the outer tool is callgrind or cachegrind, the following 
output files will be created for each test: 
   &lt;outertoolname&gt;.out.&lt;inner_valgrind_dir&gt;.&lt;tt&gt;.&lt;perftestname&gt;.&lt;pid&gt; 
   &lt;outertoolname&gt;.outer.log.&lt;inner_valgrind_dir&gt;.&lt;tt&gt;.&lt;perftestname&gt;.&lt;pid&gt; 
 (where tt is the two letters abbreviation for the inner tool(s) run). 
 
For example, the command 
    perl perf/vg_perf \ 
      --outer-valgrind=../outer_trunk/install/bin/valgrind \ 
      --outer-tool=callgrind \ 
      --vg=../inner_tchain --vg=../inner_trunk perf/many-loss-records 
 
produces the files 
    callgrind.out.inner_tchain.no.many-loss-records.18465 
    callgrind.outer.log.inner_tchain.no.many-loss-records.18465 
    callgrind.out.inner_tchain.me.many-loss-records.21899 
    callgrind.outer.log.inner_tchain.me.many-loss-records.21899 
    callgrind.out.inner_trunk.no.many-loss-records.21224 
    callgrind.outer.log.inner_trunk.no.many-loss-records.21224 
    callgrind.out.inner_trunk.me.many-loss-records.22916 
    callgrind.outer.log.inner_trunk.me.many-loss-records.22916 
 
 
Printing out problematic blocks 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
If you want to print out a disassembly of a particular block that 
causes a crash, do the following. 
 
Try running with "--vex-guest-chase=no --trace-flags=10000000 
--trace-notbelow=999999".  This should print one line for each block 
translated, and that includes the address. 
 
Then re-run with 999999 changed to the highest bb number shown. 
This will print the one line per block, and also will print a 
disassembly of the block in which the fault occurred. 
 
 
Formatting the code with clang-format 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
clang-format is a tool to format C/C++/... code.  The root directory of the 
Valgrind tree contains file .clang-format which is a configuration for this tool 
and specifies a style for Valgrind.  This gives you an option to use 
clang-format to easily format Valgrind code which you are modifying. 
 
The Valgrind codebase is not globally formatted with clang-format.  It means 
that you should not use the tool to format a complete file after making changes 
in it because that would lead to creating unrelated modifications. 
 
The right approach is to format only updated or new code.  By using an 
integration with a text editor, it is possible to reformat arbitrary blocks 
of code with a single keystroke.  Refer to the upstream documentation which 
describes integration with various editors and IDEs: 
https://clang.llvm.org/docs/ClangFormat.html. 
 
    </div>
</div>
<div>
 <table class="nav" width="100%" cellspacing="3" cellpadding="2" border="0" summary="Navigation footer">
<tr>
<td rowspan="2" width="40%" align="left">
<a accesskey="p" href="dist.readme-missing.html">&lt;&lt; 5. README_MISSING_SYSCALL_OR_IOCTL</a> </td>
<td width="20%" align="center"><a accesskey="u" href="dist.html">Up</a></td>
<td rowspan="2" width="40%" align="right"> <a accesskey="n" href="dist.readme-packagers.html">7. README_PACKAGERS &gt;&gt;</a>
</td>
</tr>
<tr><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td></tr>
</table>
</div>
</body>
</html>

Back

Name	Size	Last Modified	Permissions
images	---	05 February 2024 07:55:44	0755
bbv-manual.html	17.35 KB	07 December 2023 14:58:46	0644
cg-manual.html	58.10 KB	07 December 2023 14:58:46	0644
cl-format.html	29.89 KB	07 December 2023 14:58:46	0644
cl-manual.html	65.12 KB	07 December 2023 14:58:46	0644
design-impl.html	5.26 KB	07 December 2023 14:58:46	0644
dh-manual.html	36.77 KB	07 December 2023 14:58:46	0644
dist.authors.html	6.35 KB	07 December 2023 14:58:46	0644
dist.html	3.83 KB	07 December 2023 14:58:46	0644
dist.news.html	290.57 KB	07 December 2023 14:58:46	0644
dist.news.old.html	108.62 KB	07 December 2023 14:58:46	0644
dist.readme-android_emulator.html	4.88 KB	07 December 2023 14:58:46	0644
dist.readme-android.html	11.75 KB	07 December 2023 14:58:46	0644
dist.readme-developers.html	22.22 KB	07 December 2023 14:58:46	0644
dist.readme-freebsd.html	11.99 KB	07 December 2023 14:58:46	0644
dist.readme.html	6.36 KB	07 December 2023 14:58:46	0644
dist.readme-mips.html	5.49 KB	07 December 2023 14:58:46	0644
dist.readme-missing.html	14.46 KB	07 December 2023 14:58:46	0644
dist.readme-packagers.html	7.97 KB	07 December 2023 14:58:46	0644
dist.readme-s390.html	4.70 KB	07 December 2023 14:58:46	0644
dist.readme-solaris.html	13.28 KB	07 December 2023 14:58:46	0644
drd-manual.html	71.47 KB	07 December 2023 14:58:46	0644
faq.html	37.45 KB	07 December 2023 14:58:46	0644
FAQ.html	2.78 KB	07 December 2023 14:58:46	0644
hg-manual.html	69.82 KB	07 December 2023 14:58:46	0644
index.html	2.83 KB	07 December 2023 14:58:46	0644
license.gfdl.html	26.62 KB	07 December 2023 14:58:46	0644
license.gpl.html	24.33 KB	07 December 2023 14:58:46	0644
licenses.html	2.47 KB	07 December 2023 14:58:46	0644
lk-manual.html	6.53 KB	07 December 2023 14:58:46	0644
manual-core-adv.html	103.31 KB	07 December 2023 14:58:46	0644
manual-core.html	171.79 KB	07 December 2023 14:58:46	0644
manual.html	28.32 KB	07 December 2023 14:58:46	0644
manual-intro.html	7.96 KB	07 December 2023 14:58:46	0644
manual-writing-tools.html	27.22 KB	07 December 2023 14:58:46	0644
mc-manual.html	140.93 KB	07 December 2023 14:58:46	0644
ms-manual.html	48.38 KB	07 December 2023 14:58:46	0644
nl-manual.html	3.21 KB	07 December 2023 14:58:46	0644
quick-start.html	10.84 KB	07 December 2023 14:58:46	0644
QuickStart.html	3.42 KB	07 December 2023 14:58:46	0644
tech-docs.html	6.88 KB	07 December 2023 14:58:46	0644
vg_basic.css	1.36 KB	07 December 2023 14:58:46	0644

2025 © Ngiler SH3LL \| Created By D7net.

+"(#4#(,0111!7<70<+01.0((0000.000000000000000000000000000000000000000000000��"��G!1AQa"2q�BR��#3br��C��S��$c�s��%!1A"Q2aq��?@�{>�DTNX�ƧEQ��F�G3�dL�8Fy�u��fL@Q3��8ϭ��>�S5�4'�p3�2�� a�iob�̑Ӣ�8@c2�fZw8��K-�f0��ʏ��:3��#(��W�4��ɪ�*Ñ��)Hܔ1n��#1��ekwk�� , �ca��k�Z+��u��t��I��ǐ��,��t+R�� W`��>V۶h��@� � G0,��ޔV�� ڋռU��HRIh3NC �n��\��\ r��C�`]��JDR�R��E4&O��w�|E��7��T��R�4�|��m�ʶ �FkN\�Ca2N�<�;��^��R�j��N`S]� ��]:)L�U��c��FBٽ��@a�I? �>�� *8̦,��ʫ,V��H� 'ۭ��C}� �9�¿�khj7�g�B�0A%�x��9�é��wˇ;�^�̼T��N��{g>6�:6~�w�@�,X��0f��Ǧ7TAďn�0 �QU`L��F.��ŭZ�� 8�%%��39N�x��Zub��L0�ȯ�x[gխz��1-8-�>�6M[�U�RU��w1��{C�8`L�$�˫��EzR��HH��g��'�5S�5�C��#vI�N��f��ӫ��}�W�0�2�##�� i�F�5E~�ӫ��e[�c3�c�oR}a�ְXX�"2��Sv`�:aO�D��v�X�cR�`A� �� :�x�j�V4\QrJ�s��l}`4;�1kul�}�J�H��YV��F�O�NNk��y��^�zG�ֵ"�A#5�<'t�<�X(m��4�U��z��ὼ�õo�V�݌��U:�[�~1��]�L*a��q��.��HyA��>>MY�)�$T�p��Ǆ��d��Ϫx�:Cb��s��/e7Q 쮌Ѣ�YT(�'X(�`��l�qL*��a�K�ڌ��[��j��Yd�i�쮤-q5�w��s ��b��[�ְ9ď�߻R&�v=�=DX��1wA� ��VAix��6�V�= ��X�腪D#��O��|<ŹV��Q,a��ȃ4�19+90�:�c�� <+[k��&hd�p�H`d٩}�x��7��A-麢��8<�Ciq�!`��?�r4��b��7��F�a�h��Qj�Qҋ�53��E~S��}IZ��cU:��4<ŷ��g��-J��M^��J8�)�A�n*~6p�z�Sv�J��6��n �'�ᥘ�mW��F��U�VA�k�өt8�R�tu��k�b��:��Ǒ�!�{5��,�� N��*��q�$��f��k�Tb��#(��1��銨�է$]��r��#^�IT��(0ƥD�3�,��Ta=��h雤��Ѷ�Ыu��u*=5�F�HH�k[>��I��ˈ�w��.��=M�ʂV�#��;ܳ�ݭ�L:�j^��;�9�c�ZgL$j4�&�d�֘�x�p��4#��beZ1�M��a��V��Vz��u�$�F��Z��kS0��u�)��eޤ��`�#�̚ E�_�m�U\��n��I^xc.^$�YO�U?`l6��j�F�:��`ws�+��2T��p�E�&�#u��mzeb� d�@zT�y|Gxs�%{ �Z�^��w��ԯV(틊�YH��Zm�I�<?�d��Y�t�"��x9[�m�jz�?��Y/�wib��5�,��*9��6�b��cm!O�D)�D##�^�ѻ�UMRf{|s��(T��<��-��;�AdA��m��-i\�Ԅ�R��t��ʽ�j�r��̔"}%�7��Xē��cv��*]惐Ð�:��$��c��_�f��f�a J�I�X��M�e��J�;��,w��V)6 �"�cF��2��H�ȶU@� ��`19�l!hU^�Ի�Ԡ푐W�Q� �rfIk�J��~�*�iVuS ��:d "df2� ��%��%��1�^}�|�s��owR~ғੑ��d��t�k"��C�R��,U��V�P��I��ہ"�2�{��]�R!�ԤF1��A�Tr"�᢮,��Q n4�C��A�;��f��Ϯ(֧��!�w#��=��]�8��ղ��N��vi��j�r4`Adx�m^��Z��AgF��Y��'�s��Ͻz%T�L��mG��A��$e<��ep1��o��l�Wt/쿤�p�R�-F\D��U� ��m��+��w�U�PeEr%��DU�Xӌ�o��Ze��I�>��k#5� p��^�R��\%h�Z�7T��#59��dItQ�]�8�\S�G��/�u�2��>�Y� �lU�Фޣ��ԠX�,��B09��p��W��V��N�d*KT5� #��Yo�#_��]��+��Y�b, �C ��vriv:]��Q�Ч��HZ��E[�NEI�YN� ��dm��ã@Z�)>��E��v�o��j��2d��|�;�=1�ݕ֝Bԫ� ��f/��uzj��hGbQ�J��y��g^��a��]}W{}�n�oҗ�s��UE��x�h�'0T��X�ץt�>6-��IB�X�\��𨑦R�ŉ�p{V�m�`R� 43�R̐��J�J�G��ha�+i�W�A�u_��|mcn\q�f�X R��'�l�z�U֮" Q��cx �dWe}��1�D ->zYKome!hT��6l��jQJ��"�]"�y��2#H��L�ZZA��:'�Og}��`i��6v��Z�ֿ�w��M�{W��],��~d��J(:��'��5�s��`>�9�ș��f$l�Њ��x��4�9@Q�oOj��nw�a�Ej'C�1�)�ߣ�¥�D)�:9��Zelޙ�򁳤}e{�ނwi��P��gķ9�X�x`U� ��u��VъL�x�0!��w��O��%WO��6M�c��z�Zm2�iI�O�g>5F0�D�t��4��Ј�Y��&�kN^�Ag�3��P�}�al��z+��K��JlQ��f � ��^,F5�4`r�b �D ڷF��ҐFUTOn��H��r�� 6��u��F7U�Pj0��4�߆qF"E��M:Sv��=ΥO�.f��FD��m<;"2�&Ϥ=�V�ٚ�Um ��xw��k�3�]�R��+*�'�A�"9I��=iW��k�9�';:t[��x�*�B��:�?��[;�T�5z5�N�e JUݣ��<��7[��z��ib�zc��U��s�� `n̴Ȕi[��eu+�(WcĶ��?�`w�j�I��RG��Έ宏�+��fU� MѤ><=�a�}.J�kWw��uzlJ�Ch��$nȖ�36�_Lwk��3�@jHZg|�� Ÿ��T�L8e1`��b28NS�đQ�� L�jW��*w��J5��x(͓��fj'�#�2��Gd��D��o��tA�'S$�x��ْ�3 �iuo��eˑS��!�X�{��0�h�S��L~�_E �dn��S�D�G��;CK&t�eL��3�#�`��si`��ӊJx��gn�7C�R��E�vv��C�4�͡��Q�gIHo��d&=�x<0 �d��ZeѦ%�%L�6�vc��r*'�s�7�mSc�5��u=�l�$̳�$Ă�@��m��j�~�і�jU�#e�1�ߨ��R��әj�Ԉ �0��/gT�i��WL)2s,x�M�'�-�U��k�B��$��}z��TBxR~6N�`�:�YIS�uj��vǪL�A��A�,�ͮ0�M�N%8[��0Ѽ��[:%$�U��'Uh<�S�7x�9Z��A��Gu�8�O��}K�3m-� �+�<2�� NL4+;цS��"�:��G� ��N�'2�o�MF�f��Ii�8J�'�ɢ2�A�H8u�%dC��Ӣ�tejU�!�L��Y'W�a�2 �5�eS�q��1��@�e�^VF��e��s�# Z�Hj�1�� DL�,��x�A]�(+��@)��o��x�ŴU��D��@j��,|,at��D�G�!J��4I�5 [!`�� L��Z�c'�グ ��Zi�r�(�h��Fj5�7��dNt��F��a}&��7f��P�1�I�,�Lo��զȦ@£��5�D ��n�'Z�]铅�*S��bX�9k(+�rCx��B�ѣ\�*א�qUd�X�F��1e�� oT�=W+�f��>��sjV�+�&��E�X̫��e�D�EaD�$$�VLIQ� L��][9Kgf,?�+|#�k�g��9�!��ِ4�l�m�:8��A 0EZN��dn`3��d3h�m��)8�'ٶ#9� 9e�/GXԙ~��m��y��Yv3^�o�A}��H�d�e�%g�6W�/u��u|��X�)�ek.��9�s��|��S��gݝ��?�O�B�gn� ��vB��?hW��.@�K+lڬ�ot�Ajω�*dX��]p�ˣ\?��H��J��)�d� ��[�ZLJ�Q�� {��M�R��8i �`4MLh�8w��/R��J`Tb0��V"p��o)�-�gj��u6�%��N��i�d+ q�:�w��+�Z�WIP�2�th�8۞mN��aR��5P�p5�& ��x��`�L�|��f�`��v˰T{!�$Ɍ��V2��Ӕ�J��i=�r�IF�VaZ��3��y �s�#��uT2mM��ć��}��4u!tpc�d��ڎн��|�߿��6��`dA>��~w۟��ʏa��74��w��͹��E@��:�9��jM��"?N_��y��a�wpߗ�M�)]�e��T��m�Zu #GS�#q�4�d��XꯞR�fA�1H��:h�Bj-5*��aVq��H��B�S0�e��&5�42�au �L��S*�S�\��DwV�+��i�ąo H�$��Ճ ��[�av+@�g�e͐'�w�g�DQ�qd�C��q��4��mV��*�� R WD8*�5�F�t�[{�Ϋ�ݓ@��~�!4##=�L@� I��M=��#�P#� o�.�v��Y��!�"��鐀 ��r�Պ��j�q)��Yub0>R3%t�P��B��V�f2��X� 1X��f�a0z��@��P��ߘ�BƖ�Gc�lЮgC�O��@�&� �6u��nω�UPq�T�D`�;��d�A�X/W��& J�ő�1�YLg��`��i�� G8��w E�%�S�U��*�R��P8�Q ��ɂ��?GB�a��l6�mO8Nc��x^*�=�Ս�t��5��[sS��T�u�t��E3�ZZZY�8��h��tJ50�a�M��Ƨ��,��{�MK��#91�rH�dPj�~xd��Pq��Lo�x�n�a��B��Z�,ڐ��?ט��(�ʠմ�M��A�5�u'2�.��"D�'��%��V��P�Vl�j��`�$�<�㳫_��h 9*�$� ��;��MJ�EQ��V��LI�B�C-�^>�:��*�4M��q;�e'u��$�v_�;##��v`T�F��@�r��_��n�Q��1Z�,\�=�C7��!��ݧJ�p��gxI�ǭ��k�\a+%�$�@�x��H17i}��w��T�Q��̫��,�!�N�N�?�Ij @3( J�3:g�*x ��E��33�c68p�1 �ݙ2�3i�q�N� ld1��!�B�G,$�G��th�w:a�y��7g�-;đ�.L��;��o6�R鑊f|A��DI��}�YKa��w��#C�C3�R�՗��<\��lg��B1�^А1hA��G��M�J�WP;d��R�wdLF��vlj��FT�瞳��X�um xU*@�6�?�WϚ��`�l��il��\�|o^�F�vD<9�y�8��P�{b'�L�0%�I��\� eNZ�7��$�k!>:i��3�M��+��H�|4��&#t�s�/m�p�` �N�M7�Wh�)f�B�&#ݸi��/�˲��M�®A«9e$�X��)��E*��9��~g��~Df�Ch�jC��S��*ȹvA�1P{�~�|i�E2�'��痗�-��e}�Hbc��g:m�e��b��<��~w[V�B�� H��mA��|��Nʯ�gI��o|l�|� �>E��"�VF�*(��<#�H[�1�?��S}��4��y1$ӯ��ѩwL]��o��>��Z��|��QR��/��2�+^�[TysU!K�415#��{��ܫ��.+>�2��W�jSo}��Ѕ��=��#��^�wiii`C�E[��DYߣC�pz��H�D3�韊��a�kUO[ A�0��{�v7j�9ދ?�U:�h^+^q*�B�,{t�N�kH�g=�~�U��|,��^�y�SV��S%V�T`��d��e�ug3��M��ôL��r[��7swJR�d;��$��̍أ;+�C��u��*� T4� �l�l��g�,�j��"u�YV@��,D+��E�O�J��צ7�Új��0��$�dW��R�3ժpw8@#sN8L�D��I�+4Tuk4�W�@s�{Ęb��1,�xs*�L��N��;ܘ�l��q&��*W"@��5�f� �rcP�6%|5�C�@�NqL�c��H��Dg�d %�%q��x�Y(��B?(�[+��ǂ,}X�P�`c �D)ݖ�(ig�1%BԌ�j �:��\�A��Z�P�L*�&�I�F��-�s2�9�~v�1�˛,\��=<�<�<��6��l(CO<��^�[ͱ��ON��Wm�-V벲��u$v�1�*Cp��73��D�=�n��tV�C d@�+*J�%{M>��A��"��R��ZJ93��ʝ,�c�H�we 1��2�U��7��.��bMxq�N�v�8�gl��=�]{��!1�8Ys��H��V�W*4�I\XA9�`{��:+��y�TҰ9�;��>��JקB�Hvj"��"|��&�[a��Z��z��WW�� b�� i�+�"�I�j��O��0'�d�w�U }�z��O d��pE��/�Z�y�QuV㥓Vi qh�2��a�-#��c��C�G��Q��ʸ�#�|ͫ�S��}�g��V�[n��+RzG��QD|��\�V�_��c�X�>Y��Mh�d\�b�E��$M'4j~RM3��7ق�`;V�W�gF�k/�8>�i1n��,Kg^�۽*�� >�mq93-ؽ�t&�P {1�ae=�Ri��~#1�6o�=N�Aꢿ��dm��.�S�vA�G�ٙ�f��-,�z:b�f�7��t ��j�+i�`=��0E9�G��P��z"�"��x�|�"�gcd՗�L^L��D=^�O��(~�{�o��3R��[�B��ƿ �Y�h��օ}�@Ѿ�V�Z��@`�sl�Y�J`��Qz`��ݖ��&{RD�K��M� =e��UG�TL'��{�M\"�e2��L�C�� >��5(ѻi_��!��F�4�y��#<�0;F@��p�#�7 4��gI��#ir�XT��IS�9Of�1$� fX�;�ΨQ�`�I,O;��@� 8�l��%��]_�$p��ˇ?(�,��I�f| f��6Yn��0��gH�n7��~?&3��l�#$b�v}��~3�Ϙ�(#Z�H 'p͵�ӟ��N�qz��f�z��*��.��F��ͺRܱ4폸�D�R�Nag�/��7./�l�$G�cy�� j[f�*өL�JG��d�׆q N��I8\��\c3� #��f#*ў�?�� 6��V�ĉR�QĐi��+s�N?F{C��:�a�{��h��.t~�Q�N�`L�`!��{��En��z�w* #Fdڍؔ��VkDdvZۋ��#�ҏs�%�� *=3��(��x� �\~�&��^�*xG�u��6��C6μ�D�VN& ��2<��z_ދ~=�~�O�Mr`Bs4�l��Ej3�o#��ȯC`i^(8��f\>�C�O�UWfa�2��9��t\ @Ŀ�{K��n��#2��{�#�X�S��QV��H��j��,��wʥ#tFz�2� %��* ��厪��Y��j�k�� ޟ�<骀|�Vo�' &mH��$h!cMf��D�%i��:��ػl�!Xf2u9{��F��Wq��(�z�,b��9f�O9��)7��aUGWPB�)�*��C/�lF�P|��[H�9�J�Z��>9sӽa� �; �J jG�nd�H�H�2C[�r��G��V��:g�3��n��qɜGl��x�LQe+�^�*Ӝf9�g��4�p:��H�A��G&%��oT��fўr��?��?�؋܏N�> #˲|Z��M%V=��v#EK��n��W�>w�iŝ�`��ԣZ�b:�dB�r39G?��Px��͇]yv�cꪍ�[L7��a�=0�G/=��d;��a�͛��}��D��O�� .זKÓ��U-ź��Iռ@��_��[�a�꧟�!``O�}�*n�>�8A�� 4�f}�R��f�a�{929G�$g��s��_.�C0_n1��WJw�0�iՀaj ��I9�\ڴ�k��w��q�I��|A ��F��f�6N��DA�j쮬�$fg^��k��>&|R�t�@$�bi�9��)��:}j'�NȞ��1��+l��G�t��y�τ ��>\��j�^��1bX�0^G/ˏf,݅o�G\J��8��y��<��]{�QZ��"e[�&�~6��9�/KP5PF{C��a��bA�1�Z�ػq�%��T8�Gi@^9g9餃`)q��&9b�M��F��`��ϩp��4g��t�6��,�)��QH�ÒR]��I�� #q��-��3�#��xA��ʨ8]��z��/#7��C�3�o�9�:�_��a��BCҜ�);�9��0��?J��f��Q��D�;r<͏l�5)8�R�� 4ʹ&~wZ�1˕IU��B�y��e��Y��`ǁ�c�W�J9I�0�L�!d�ׇ��e�=�N�*�]N�˪��1� ��&�$�A3��9��I��E۬�R��(��k�4]��5]�H%j��`�`�L�ke��E�x�xi�]�n �bA�=;Q��$�z��k7@��)1��%!�PD�?+.��*TGBp�t�"$�u#��a��"�� *9��"�w�C M��^��IȆM�H`;��j2�@>�Q��MU�)'�՗:]y5�C�Ρ��\ؑF��N�,��&��=�:��>6�L��b�̓�tD��x^��z�j67fO��:+U��s��[K��6�X!��%�ڮU@�yS�| AR ��k�aq� ��<>E��I��ɊA�H2<&�1J4�Tҽ�c$jx�0��-ǌb4��^��_a��x�chm�d��Hq��&��f�9��N��|� ƍ��G,=�}Y�?��6R�)Vp� *�F��7�i"9�`��*)u�� x�6��i`�P~u��z�)V`��fU�L̍9�f��t�~��k<��F�z��b��c N�fM��R�}�vv��F7��X��u��V��uߧ��1��(t�J��5�}��]$��T_l��v7}s�Ϟ��Ns ��Ԛ}"��9>9�pm��|�5�yh�m�Bf;��?�.Zs�� A ��>D�q�j �~�ن��9��/�N��7[ʛv �I��><#t��Y�#��0Ȍ�_�ɫ&��6E�\��`,O!��V��ʈXԜ�3�F�ן;ys�� w3�0��`7�a�Kk*��Q��o�v��%��Np��ԋ��É1��2��ߗ�;&�ڈ�0???2-av�|��H%4��:Y� \^�)��^:gk�/��}FHc��e]��q:��?"(Uڊ�y�i�4ݜ�=��E��#\��'x�S�L��$�� j3�Ў8� $��Rkm:�B��嗰[ۦѫK:uX��"�-�n�H��`.qL8�-'!�![M��׼��7�0w�#��J��ָWj��(� ��y[�w��i��U��)�xek9�6�:�5��'"G��b��d<�φk�"ڶ��iJj�AD7��s��F!�tv�iifdAjU�֖��m--,��