Bug 129866 - cachegrind/callgrind causes an executable to die (memcheck is ok)
Summary: cachegrind/callgrind causes an executable to die (memcheck is ok)
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: cachegrind (show other bugs)
Version: 3.2.0
Platform: Compiled Sources Linux
: NOR crash
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-26 20:58 UTC by philippe.waroquiers
Modified: 2006-08-22 04:07 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description philippe.waroquiers 2006-06-26 20:58:22 UTC
I am trying to use callgrind on an tool called adactl (an ada code checker
based on gnat/gcc library).
When running adactl under memcheck, everything goes well.
Memcheck does not report any particular errors (apart of some leaks).
When running adactl under callgrind or under cachegrind, adactl
crashes due to an unhandled Ada exception STORAGE_ERROR.
Such a STORAGE_ERROR exception is raised by the Ada runtime
when there is no memory anymore (either in the heap or no stack)
or when an invalid memory access is done (e.g. unaligned access).


The environment is:
  valgrind 3.2.0
  red-hat AS 3.0
  x86 32 bit
Both gnat/gcc and adactl are free software (so, sources are available), but
building all that is not straightforward.
The executable that fails is mostly statically linked (it only uses
libc.so.6 and ld-linux.so.2)

I have tried to run cachegrind with --sanity-level=10, but
nothing relevant was produced.

What I can do to help is:
   * I will try to upload a tar.gz file of the executable and the data
     file needed to run it. With this tar.gz, the problem can maybe be
     reproduced on your side (assuming this is enough for you to
     see what is happening)
     To reproduce the problem, it should be enough to run the
        run_me
     which run adactl 4 times (once without valgrind, once with callgrind/
     cachegrind and finally once with memcheck). Only callgrind/cachegrind
     runs causes adactl to crash.
  and/or
   * if some more traces can help you, I can run valgrind/cachegrind with 
      the tracing flags you indicate to me and I can upload the result
  and/or
   * if you have any other idea/suggestion that I can look at, I can
     try to do it.

Thanks

(NB: I am still working for the next 2 days, then I am on holidays for 3 weeks).
Comment 1 philippe.waroquiers 2006-06-26 21:06:16 UTC
I tried to upload the tar.gz file but could not (the total size
of the tar gz file is 3.7 Mb)
I could split it in 4 different files and upload them one by one
but I think I better wait for your feedback/guideline about what
to do.
Thanks
Comment 2 philippe.waroquiers 2006-06-27 12:21:30 UTC
Someone else tried to run adactl under callgrind/cachegrind
and obtains an error detected by glibc realloc (see below).
Both the STORAGE_ERROR that I am seeing and the glibc detected
error are maybe caused by the same problem in cachegrind/callgrind.


Loading units, please wait...
*** glibc detected *** realloc(): invalid pointer: 0x0433a008 ***

Execution terminated by unhandled exception
Exception name: PROGRAM_ERROR
Message: unhandled signal
Call stack traceback locations:
0x8338886

Comment 3 Julian Seward 2006-07-17 12:11:30 UTC
Does it work with --tool=none ?
Comment 4 philippe.waroquiers 2006-07-25 23:01:47 UTC
>http://bugs.kde.org/show_bug.cgi?id=129866         

..
>------- Additional Comments From jseward acm org  2006-07-17 
>12:11 -------
>Does it work with --tool=none ?


Same problem with tool=none.
I tried also massif (runs ok) and lackey (crashes).

In summary:

without valgrind: ok
with memcheck:    ok
with massif:      ok
with cachegrind:  adactl crashes
with callgrind:   adactl crashes
with none:        adactl crashes
with lackey:      adactl crashes

Is there any other data I can capture ?


____

This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.

Any views expressed in this message are those of the sender.

Comment 5 philippe.waroquiers 2006-07-31 20:19:22 UTC
Note also that I tried older valgrind versions:
valgrind 2.4.1 + tool=none + adactl: ok
valgrind 3.0.[01] + tool=none/cachegrind + adactl: ok
valgrind 3.1.SVN + tool=none/cachegrind + adactl: failed 
  (not too sure of the exact date of this SVN, it was
   still installed here in a corner, it seems the last src modifs are
from
   the 11 Nov 2005)
valgrind 3.2.0 : see previous mails for failures.

In other words, it seems that the bug causing adactl to crash was
introduced
between 3.0.1 and 3.1.SVN (11 Nov 2005).

Hope this helps ...
(if I can do anything else, ...)


____

This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.

Any views expressed in this message are those of the sender.

Comment 6 philippe.waroquiers 2006-08-09 12:26:02 UTC
Did you already take a look at the tar file 
(sent in a mail to jseward@acm.org) ?

It is probably not very easy for you to work on
a big binary executable. I have tried to cut down the executable a
little
bit, but isolating this problem is quite complex, as adactl is a
static code checker which works on data structures generated by
gnat/gcc. So, to isolate the problem, it is needed to:
  1. first cut down our own source code
  2. cut down the code (part of the gcc/gnat compiler) that generates
the
     data structure (this data structure contains the full semantic
information
     of the source file).
  3. do a similar cut down of the adactl/asis tool that reads this data
structure
     (the cut down in the compiler and in adactl must stay compatible,
and
      must still be able to process some valid source files).
Bref an horribly painful process if we want to obtain a minimal test
case.
I have been able to relatively easily cut the adactl executable size by
2,
and by doing this, has also reduced the quantity of code that really
runs before the real code causing the problem with valgrind.

Will this (still huge but reduced) executable make it easier for you ? 

>-----Original Message-----
>From: WAROQUIERS Philippe 
>Sent: Friday 28 July 2006 15:39
>To: 'Julian Seward'
>Subject: RE: [Bug 129866] cachegrind/callgrind causes an 
>executable to die (memcheck is ok)
>
>
>>Can you send me (jseward@acm.org) the tarball you mentioned earlier?
>>Obviously something is wrong but I can't guess what from the email.
>>Best to compress with bzip2 not gzip; it will be smaller.
>Find attached the bzip2 tar file.
>It a.o. contains a script file called run_me which runs adactl without
>or with valgrind, and this with various valgrind tools (only memcheck
>and massif seems to cause no problem for adactl).
>
>It also contains the run_me.out, the output of a run_me 
>execution I did here,
>which shows the 3 "successful" adactl executions
>and all the failing ones (producing a "STORAGE_ERROR" exception).
>
>The adactl executable needs 2 shared libs: libc.so.6 and ld-linux.so.2
>adactl executable was built (and run_me.out was produced) on
>Red Hat Entreprise Linux AS release 3 (Taroon Update 4).
>
>If you need anything else or have any question or I can do something,
>I am at your disposal.
>
>Thanks for all your nice work and support
>
>Philippe

____

This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.

Any views expressed in this message are those of the sender.

Comment 7 Julian Seward 2006-08-09 12:44:46 UTC
> 2006-08-09 12:26 ------- Did you already take a look at the tar file
> (sent in a mail to jseward acm org) ?


Yes, I did look at it a couple of weeks back.  I can reproduce the
failure, but I have no idea where to start looking for the problem.
I imagine there is some problem between Valgrind and the Ada runtime
library(s), but without someone who is familiar the Ada runtime and 
how it works, this is going to be difficult to track down.

> Will this (still huge but reduced) executable make it easier for you ?


It might - I don't know.  But it can't make things worse, and ultimately
finding a small test case is the best chance for a fix.  The smaller
you make it the better.

This is one of the bugs I would like to fix if possible before releasing
3.2.1, and I'd like to release in about 2 weeks.  So if you can produce
and even smaller test case I'll have another look.
Comment 8 Tom Hughes 2006-08-09 12:47:38 UTC
Is there any reason to believe that this isn't just a genuine heap corruption caused by the client program that just happens to only show up under valgrind (when memory will probably be laid out rather differently)?
Comment 9 Julian Seward 2006-08-09 13:01:31 UTC
> Is there any reason to believe that this isn't just a genuine heap
> corruption caused by the client program that just happens to only show up
> under valgrind (when memory will probably be laid out rather differently)?


But the thing is, it runs ok on memcheck and massif (iirc), both of which
replace malloc; and it fails on the other tools, which don't.  So there
might be heap corruption, yet memcheck doesn't make any comment.

Hmm.  Perhaps it overshoots heap blocks by more than 16 bytes and so
misses the redzones mc puts in.  I can try running it on a hacked V with
huge redzones, I guess.  I'll try that.
Comment 10 Nicholas Nethercote 2006-08-09 13:39:21 UTC
Yes, it is strange that it works ok on the tools that use Valgrind's malloc/free implementation, ie. the ones that are less like the native environment.  So I would suspect that Tom is right and there is a problem with adactl itself.

Massif uses redzones of zero bytes, so I don't think that is the deciding factor.
Comment 11 Julian Seward 2006-08-09 14:29:06 UTC
Well, I tried memcheck with 1024 byte red zones, but that didn't
show anything.

So I guess the initiative is back with Philippe to come up with a
smaller test case.  I agree that it's probably something a bit
strange in the Ada runtime, but still, if we can get to the bottom
if it we should.
Comment 12 Julian Seward 2006-08-09 14:32:41 UTC
> So I would suspect that Tom is right and there is a
> problem with adactl itself.


Also, Philippe, are you able to ask your Ada vendor if they know of any
problems running Ada with Valgrind?
Comment 13 philippe.waroquiers 2006-08-09 15:24:38 UTC
>Also, Philippe, are you able to ask your Ada vendor if they know of any
>problems running Ada with Valgrind?


Note that the same adactl executable:
   works standalone
   works with memcheck  (valgrind 3.0, 3.1, 3.2)
   works with tool=none/cachegrind (up to and including valgrind 3.0)
   fails with tool=none/cachegrind (valgrind 3.1 and 3.2)

We are running our (big) Ada application with memcheck/callgrind
without problems (thanks to the improvements in valgrind and/or in
callgrind
since valgrind 2.4).
This big Ada application (> 1_000_000 SLOC) is doing a heavy usage of
the Ada runtime (e.g. tasks-threads, mutexes, ...) and integrates
quite a lot of COTS/libraries (e.g. Oracle, X, Motif, GTK)
and uses many "strange" system calls (e.g. SysV IPC semaphores).
while adactl/asis combination is a "simple" executable : one single
thread of execution, and does nothing special (mainly file IO).

We have discussed with Adacore (www.adacore.com) valgrind usage with
Ada.

They (and we) know about some problems:
   * when using "pointers" to local/nested procedures, this can cause
problems 
    (due to trampoline). To my knowledge, we do not have such usage in
our 
     big application.
     NB: I do not too much understand what is exactly a
     trampoline. Could it be that the need of trampoline inside adactl
     could make tool=none crash but have memcheck ok ? 
     (and this "need" has then appeared between valgrind 3.0 and 3.1).
   * In some cases, the Ada equivalent of "printf for float" does not
work
     because the Ada runtime counts on the 80 bits floating point
computation.

Apart of this, we have not detected problems on our big application with
memcheck and callgrind.


So, bizarre ...

I will try to further reduce the size of the executable and/or the
initial sources to be checked by adactl.
Reducing the sources to be checked will be relatively easy, but I doubt
I will be able to reduce "gcc-gnat" compiler and the asis library that
reads the data structure produced by gcc-gnat.


____

This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.

Any views expressed in this message are those of the sender.

Comment 14 philippe.waroquiers 2006-08-09 15:37:34 UTC
>------- Additional Comments From tom compton nu  2006-08-09 
>12:47 -------
>Is there any reason to believe that this isn't just a genuine 
>heap corruption caused by the client program that just happens 
>to only show up under valgrind (when memory will probably be 
>laid out rather differently)?


A heap corruption can effectively cause whatever kind of behaviour.
However, memcheck and massif are working ok. I have run memcheck
with a huge value for --freelist-vol (I assume all access to
freed memory will be detected with this).
Memcheck does not report anything significant (only a few leaks).
Not a proof that there is no heap corruption, but it decreases
the probability.
____

This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.

Any views expressed in this message are those of the sender.

Comment 15 Tom Hughes 2006-08-09 15:43:57 UTC
A trampoline is a dynamically generated piece of code - so long as it is placed on the stack valgrind should cope with it by default. If it is no on the stack then you will need to use --smc-check=all with valgrind.

If you are getting glibc heap assertion failures then your heap is getting corrupted, or you are giving realloc a bogus pointer. As valgrind doesn't use the glibc heap that pretty much has to be your program unless there is a code translation bug or something in valgrind.
Comment 16 philippe.waroquiers 2006-08-09 16:04:26 UTC
>If you are getting glibc heap assertion failures then your 
>heap is getting corrupted, or you are giving realloc a bogus 
>pointer. As valgrind doesn't use the glibc heap that pretty 
>much has to be your program unless there is a code translation 
>bug or something in valgrind.


I have just run adactl with export MALLOC_CHECK_=1 (I understood
that this is the way to have glibc checking the heap)
and no message is being produced.


____

This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.

Any views expressed in this message are those of the sender.

Comment 17 philippe.waroquiers 2006-08-10 21:56:38 UTC
>So I guess the initiative is back with Philippe to come up with a
>smaller test case.  I agree that it's probably something a bit
>strange in the Ada runtime, but still, if we can get to the bottom
>if it we should.


Well, someone else here and myself have spent some time to try to reduce
the problem. adactl usage implies two steps:
  input                           executable       output
  ******                          **********       ******
  sources files to be checked  ----gcc/gnat---->   all_ft_mode.adt
  all_ft_mode.adt -----adactl rule checker ---->   rule violoation

The source files are read and compiled in a special mode by gcc/gnat,
producing a data file (all_ft_mode.adt) that contains the semantic
information about the source files. 
This data file is then read by adactl, which implements various 
code rule verifications.
valgrind --tool=none/cachegrind makes the adactl fail.

We have been able to reduce the sources files to be checked to about
3000
lines of non-blank non-comment lines. But after this, trying to remove a
single
line (at various places, in various files) makes the problem disappear.

The adactl "main" code itself has been reduced to be almost only:
  initialise asis library (asis library = the gcc/gnat lib that can read
the adt files and
                           that gives an API to interrogate the source
files semantic)
  read the adt file with the asis lib
But asis is a big library: it provides a full access to the whole of Ada
language semantic
information about the sources.
Further reducing this asis library seems not really practical because:
   * this lib has to read the data generated by gcc-gnat
   * and simplifying the asis lib code implies to simplify gcc-gnat
similarly so as to
     keep "compatible" data structures (inside all_ft_mode.adt)
   * but gcc-gnat must still be able to read and process 3000 lines of
sources.

The resulting adactl executable still contains about 2Mb of text
(instructions).
In summary, it seems that we are quite blocked on the reduction of the
test case.


What I have also done is to run valgrind --tool=memcheck on gcc-gnat.
This
reports several errors, and maybe these errors causes strange/random
data to be written
in the adt file, which then cause a problem (why it only causes a
problem under
valgrind tool=none/cachegrind/... and e.g. not under memcheck is beyond
the capacity
of my brain, I have to admit): the adt file contains maybe random data,
but once the
random data is saved in the file, it will always have the same value for
all
subsequent invocation(s) of the adactl tool.
I will report to Adacore (gnat and asis maintainer) 
that valgrind --tool=memcheck gcc-gnat gives several error messages, and
that they 
could take a look at these, but even if gcc produces
a random adt file, once the adt file is obtained, it is a
"deterministic" input
for the various runs of adactl (with or without valgrind, with memcheck
or none or ...).


On the "valgrind" investigation side:
  I expect a tool like none or cachegrind to run the code "unchanged".
What we see is that valgrind 3.0.1 tool=none/cachegrind adactl is "ok"
while valgrind 3.1 and 3.2 are making it behave differently (i.e.
crash). So, it seems
that the 3.1/3.2 none/cachegrind tools are doing something different
with the same
adactl executable and adt file than valgrind 3.0.

If the internal debug tracing of valgrind has not changed too much
between 3.0 and 3.1/3.2,
maybe such tracing comparison can help to determine what makes adactl
fail under
valgrind 3.1/3.2 tool=none/cachegrind ?
It is not clear to me how to start with this idea, because I do not know
what kind
of tracing to enable and/or how to interpret and/or compare these
tracing. Maybe you
could give some indications about what to trace ? (assuming this is a
good idea).

Maybe you have other ideas about what to look for ?

Otherwise, if you think you can do something with the slightly smaller
adt file and the 
smaller (but still big) "reduced" adactl executable, I can send it to
you. If you think 
it is desperate, I do not have much ideas about what to try next.

Thanks for the help ...






____

This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.

Any views expressed in this message are those of the sender.

Comment 18 philippe.waroquiers 2006-08-12 02:14:03 UTC
>------- Additional Comments From jseward acm org  2006-08-09 
>14:29 -------
>Well, I tried memcheck with 1024 byte red zones, but that didn't
>show anything.
>
>So I guess the initiative is back with Philippe to come up with a
>smaller test case.  I agree that it's probably something a bit
>strange in the Ada runtime, but still, if we can get to the bottom
>if it we should.


Finally, I have managed to reproduce the bug with a small C program.
>From what I can see, there is really a bug in valgrind.


You will see below how to reproduce the problem.
NB: the way I found it was:
  * enable or add plenty of trace everywhere in asis lib, and see at
which
    point the program failing under valgrind was behaving differently
from the
    "normal" program.
  * with this, I found that adactl tool=none was failing in a call to
realloc
  * I first thought that this was a bug in gnat/asis (corruption of
heap, 
    erasing malloc control data)
    but could not see what it could be. I then saw that realloc was
behaving strangely
    (not reallocating what was supposed to be reallocated).
    I then used valgrind --tool=memcheck --trace-malloc=yes to have all
the "malloc/free/realloc"
    calls and then used a script to re-create a C program doing the same
malloc/free/realloc
    sequence.
  * with this C program, memcheck does not say anything, but cachegrind
and none
    are crashing.

(the program contains plenty of variables called Ox...... (O like the
letter O not like zero).
These var names are matching the addresses as reported by memcheck
tracing.

From what I can see, it looks like if the malloc of a big block followed
by a small increase
of this block using realloc causes a problem due to the fact that the
big malloc blocks are allocated
in pieces of mmap-ed memory (or something like that). There must be a
bug in this area, when
valgrind does not replace the malloc/free/realloc (which explains why
memcheck works ok:
as malloc/free/realloc are replaced, mmap-ed malloc-ed blocks are not
used).


wao@pike: valgrind --version
valgrind --version
valgrind-3.2.0
wao@pike: gcc -g -o reproalloc reproalloc.c
gcc -g -o reproalloc reproalloc.c
wao@pike: valgrind --tool=memcheck ./reproalloc
valgrind --tool=memcheck ./reproalloc
==32617== Memcheck, a memory error detector.
==32617== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et
al.
==32617== Using LibVEX rev 1606, a library for dynamic binary
translation.
==32617== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==32617== Using valgrind-3.2.0, a dynamic binary instrumentation
framework.
==32617== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et
al.
==32617== For more details, rerun with: -v
==32617== 
==32617== 
==32617== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from
1)
==32617== malloc/free: in use at exit: 3,452,769 bytes in 187 blocks.
==32617== malloc/free: 444 allocs, 257 frees, 6,082,087 bytes allocated.
==32617== For counts of detected errors, rerun with: -v
==32617== searching for pointers to 187 not-freed blocks.
==32617== checked 469,272 bytes.
==32617== 
==32617== LEAK SUMMARY:
==32617==    definitely lost: 3,048,458 bytes in 184 blocks.
==32617==      possibly lost: 404,311 bytes in 3 blocks.
==32617==    still reachable: 0 bytes in 0 blocks.
==32617==         suppressed: 0 bytes in 0 blocks.
==32617== Use --leak-check=full to see details of leaked memory.
wao@pike: valgrind --tool=none ./reproalloc
valgrind --tool=none ./reproalloc
==32624== Nulgrind, a binary JIT-compiler.
==32624== Copyright (C) 2002-2006, and GNU GPL'd, by Nicholas
Nethercote.
==32624== Using LibVEX rev 1606, a library for dynamic binary
translation.
==32624== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==32624== Using valgrind-3.2.0, a dynamic binary instrumentation
framework.
==32624== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et
al.
==32624== For more details, rerun with: -v
==32624== 
==32624== 
==32624== Process terminating with default action of signal 11
(SIGSEGV): dumping core
==32624==  Access not within mapped region at address 0x65950164
==32624==    at 0x409C519: _int_realloc (in /lib/tls/libc-2.3.2.so)
==32624==    by 0x409B155: realloc (in /lib/tls/libc-2.3.2.so)
==32624==    by 0x8048403: touch_realloc (reproalloc.c:16)
==32624==    by 0x8048A92: main (reproalloc.c:554)
==32624== 
Memory fault 
wao@pike: 

#include <stdlib.h>
char * touch_malloc (int size) 
{
  char * result;
  int i;
  result = malloc (size);
  for (i = 0; i < size; i++)
    *(result + i) = 'a';

  return result;
}
char * touch_realloc (char * ptr, int size) 
{
  char * result;
  int i;
  result = realloc (ptr, size);
  for (i = 0; i < size; i++)
    *(result + i) = 'a';

  return result;
}

main ()
{
char *  Ox416A868;
char *  Ox416A8A8;
char *  Ox416A8E8;
char *  Ox416A928;
char *  Ox416A968;
char *  Ox416A9A8;
char *  Ox416A9E8;
char *  Ox416AA28;
char *  Ox416AA68;
char *  Ox416AAA8;
char *  Ox416AAE8;
char *  Ox416AB28;
char *  Ox416AB68;
char *  Ox416ABA8;
char *  Ox416ABE8;
char *  Ox416AC28;
char *  Ox416AC68;
char *  Ox416B2D8;
char *  Ox416D888;
char *  Ox416DEF8;
char *  Ox41704A8;
char *  Ox417C828;
char *  Ox4195E98;
char *  Ox419BC88;
char *  Ox41EC848;
char *  Ox41EC8D8;
char *  Ox41EC968;
char *  Ox41EC9F8;
char *  Ox41ED1A8;
char *  Ox41ED200;
char *  Ox41ED320;
char *  Ox41ED3A0;
char *  Ox41ED420;
char *  Ox41F97A0;
char *  Ox4210ED0;
char *  Ox4213610;
char *  Ox42145E0;
char *  Ox42147A0;
char *  Ox4214820;
char *  Ox4214C88;
char *  Ox421E8F8;
char *  Ox4228568;
char *  Ox4229218;
char *  Ox4229428;
char *  Ox4229638;
char *  Ox42296E0;
char *  Ox4229C38;
char *  Ox42357E8;
char *  Ox4266558;
char *  Ox4267528;
char *  Ox42675A0;
char *  Ox42675E0;
char *  Ox4267628;
char *  Ox42676A0;
char *  Ox42676F0;
char *  Ox4267988;
char *  Ox4267A80;
char *  Ox4267B90;
char *  Ox4267C60;
char *  Ox4267C98;
char *  Ox4267D08;
char *  Ox4267EF8;
char *  Ox4267F78;
char *  Ox4268028;
char *  Ox43EEA58;
char *  Ox43EEAC8;
char *  Ox43EEB08;
char *  Ox43EEBD8;
char *  Ox43EEC70;
char *  Ox43EECE8;
char *  Ox43EED60;
char *  Ox43EEDD8;
char *  Ox43EEE18;
char *  Ox43EEE58;
char *  Ox43EEE98;
char *  Ox43EEEE0;
char *  Ox43EEF30;
char *  Ox43EEF80;
char *  Ox43EEFC8;
char *  Ox43EF028;
char *  Ox441FD98;
char *  Ox4423C48;
char *  Ox44549B8;
char *  Ox44857F0;
char *  Ox4486AF0;
char *  Ox44B7928;
char *  Ox44E8760;
char *  Ox44EAF38;
char *  Ox44ECCC8;
char *  Ox44ECD10;
char *  Ox44ECD58;
char *  Ox44ED9B8;
char *  Ox44EDE68;
char *  Ox44EDFA8;
char *  Ox44EEED0;
char *  Ox44EEF90;
char *  Ox44EF028;
char *  Ox4676098;
char *  Ox4676F08;
char *  Ox4676F48;
char *  Ox4676F88;
char *  Ox4676FD8;
char *  Ox4677028;
char *  Ox4677180;
char *  Ox4678090;
char *  Ox46781E0;
char *  Ox46790C8;
char *  Ox4679638;
char *  Ox4679D30;
char *  Ox467A418;
char *  Ox467DA50;
char *  Ox467E0F8;
char *  Ox4684718;
char *  Ox4684BE0;
char *  Ox46850B0;
char *  Ox46899E0;
char *  Ox4689A28;
char *  Ox4689AB8;
char *  Ox4689B30;
char *  Ox4689CD8;
char *  Ox4689FC8;
char *  Ox468C248;
char *  Ox468C288;
char *  Ox468C328;
char *  Ox468C3D0;
char *  Ox468C868;
char *  Ox468CAF0;
char *  Ox468E590;
char *  Ox468E620;
char *  Ox468EC10;
char *  Ox468F350;
char *  Ox4693990;
char *  Ox4693A30;
char *  Ox4693FE8;
char *  Ox4694290;
char *  Ox4696308;
char *  Ox46965F0;
char *  Ox4698000;
char *  Ox4698470;
char *  Ox469AF98;
char *  Ox469B290;
char *  Ox469CD18;
char *  Ox469D0C8;
char *  Ox469F9F0;
char *  Ox469FA90;
char *  Ox469FE68;
char *  Ox469FEE8;
char *  Ox46A0098;
char *  Ox46A0158;
char *  Ox46A0698;
char *  Ox46A06F0;
char *  Ox46A0840;
char *  Ox46A0930;
char *  Ox46A0E40;
char *  Ox46A0EA0;
char *  Ox46A1058;
char *  Ox46A10A8;
char *  Ox46A12A8;
char *  Ox46A1B40;
char *  Ox46A64D8;
char *  Ox46A6518;
char *  Ox46A65A8;
char *  Ox46A6FF8;
char *  Ox46AE4A8;
char *  Ox46AE610;
char *  Ox46AF4C0;
char *  Ox46AF6B8;
char *  Ox46B0DC0;
char *  Ox46B1278;
char *  Ox46B4168;
char *  Ox46B42C0;
char *  Ox46B4D50;
char *  Ox46B4E90;
char *  Ox46B5868;
char *  Ox46B5AA0;
char *  Ox46B6DA8;
char *  Ox46B6FE8;
char *  Ox46B8448;
char *  Ox46B8500;
char *  Ox46B8A38;
char *  Ox46B8BE0;
char *  Ox46B9728;
char *  Ox46B97A8;
char *  Ox46B99E8;
char *  Ox46B9B98;
char *  Ox46BA7D8;
char *  Ox46BA830;
char *  Ox46BA9B8;
char *  Ox46BAA78;
char *  Ox46BAE60;
char *  Ox46BAF18;
char *  Ox46BB3B8;
char *  Ox46BB550;
char *  Ox46BC5D8;
char *  Ox46BC770;
char *  Ox46BD7F8;
char *  Ox46BDBD0;
char *  Ox46BFF40;
char *  Ox46C39B8;
char *  Ox46C4B58;
char *  Ox46C5808;
char *  Ox46C7138;
char *  Ox46C7178;
char *  Ox46C7308;
char *  Ox46C7348;
char *  Ox46C7388;
char *  Ox46C7518;
char *  Ox46C7A20;
char *  Ox46C7A60;
char *  Ox46C7AA0;
char *  Ox46C7AE0;
char *  Ox46C7B20;
char *  Ox46C7B60;
char *  Ox46C7CF0;
char *  Ox46C7E80;
char *  Ox46C8388;
char *  Ox46C83C8;
char *  Ox46C8558;
char *  Ox46C86E8;
char *  Ox46C8BF0;
char *  Ox46C8C30;
char *  Ox46C8DC0;
char *  Ox46C8F50;
char *  Ox46C9458;
char *  Ox46C9498;
char *  Ox46C9628;
char *  Ox46C97B8;
char *  Ox46C9CC0;
char *  Ox46C9D00;
char *  Ox46C9E90;
char *  Ox46CA020;
char *  Ox46CA528;
char *  Ox46CA568;
char *  Ox46CA6F8;
char *  Ox46CA888;
char *  Ox46CAD90;
char *  Ox46CADD0;
char *  Ox46CAF60;
char *  Ox46CB0F0;
char *  Ox46CB5F8;
char *  Ox46CB638;
char *  Ox46CB7C8;
char *  Ox46CB958;
char *  Ox46CBE60;
char *  Ox46CBEA0;
char *  Ox46CC030;
char *  Ox46CC1C0;
char *  Ox46CC6C8;
char *  Ox46CC708;
char *  Ox46CC898;
char *  Ox46CCA28;
char *  Ox46CCF30;
char *  Ox46CCF70;
char *  Ox46CD100;
char *  Ox46CD290;
char *  Ox46CD798;
char *  Ox46CD7D8;
char *  Ox46CD968;
char *  Ox46CDAF8;
char *  Ox46CE000;
char *  Ox46CE040;
char *  Ox46CE1D0;
char *  Ox46CE360;
char *  Ox46CE868;
char *  Ox46CE8A8;
char *  Ox46CEA38;
char *  Ox46CEBC8;
char *  Ox46CF0D0;
char *  Ox46CF110;
char *  Ox46CF2A0;
char *  Ox46CF430;
char *  Ox46CF938;
char *  Ox46CF978;
char *  Ox46CFB08;
char *  Ox46CFC98;
char *  Ox46D01A0;
char *  Ox46D01E0;
char *  Ox46D0370;
char *  Ox46D0500;
char *  Ox46D0A08;
char *  Ox46D0A48;
char *  Ox46D0BD8;
char *  Ox46D0D68;
char *  Ox46D1270;
char *  Ox46D12B0;
char *  Ox46D1440;
char *  Ox46D15D0;
char *  Ox46D1AD8;
char *  Ox46D1B18;
char *  Ox46D1CA8;
char *  Ox46D1E38;
char *  Ox46D2340;
char *  Ox46D2380;
char *  Ox46D2510;
char *  Ox46D26A0;
char *  Ox46D2BA8;
char *  Ox46D2BE8;
char *  Ox46D2D78;
char *  Ox46D2F08;
char *  Ox46D3410;
char *  Ox46D3450;
char *  Ox46D35E0;
char *  Ox46D3770;
char *  Ox46D3C78;
char *  Ox46D3CB8;
char *  Ox46D3E48;
char *  Ox46D3FD8;
char *  Ox46D44E0;
char *  Ox46D4520;
char *  Ox46D46B0;
char *  Ox46D4840;
char *  Ox46D4D48;
char *  Ox46D4D88;
char *  Ox46D4F18;
char *  Ox46D50A8;
char *  Ox46D55B0;
char *  Ox46D55F0;
char *  Ox46D5780;
char *  Ox46D5910;
char *  Ox46D5E18;
char *  Ox46D5E58;
char *  Ox46D5FE8;
char *  Ox46D6178;
char *  Ox46D6680;
char *  Ox46D66C0;
char *  Ox46D6850;
char *  Ox46D69E0;
char *  Ox46D6EE8;
char *  Ox46D6F28;
char *  Ox46D70B8;
char *  Ox46D7248;
char *  Ox46D7750;
char *  Ox46D7790;
char *  Ox46D7920;
char *  Ox46D7AB0;
char *  Ox46D7FB8;
char *  Ox46D7FF8;
char *  Ox46D8188;
char *  Ox46D8318;
char *  Ox46D8820;
char *  Ox46D8860;
char *  Ox46D89F0;
char *  Ox46D8B80;
char *  Ox46D9088;
char *  Ox46D90C8;
char *  Ox46D9258;
char *  Ox46D93E8;
char *  Ox46D98F0;
char *  Ox46D9930;
char *  Ox46D9AC0;
char *  Ox46D9C50;
char *  Ox46DA158;
char *  Ox46DA198;
char *  Ox46DA328;
char *  Ox46DA4B8;
char *  Ox46DA9C0;
char *  Ox46DAA00;
char *  Ox46DAB90;
char *  Ox46DAD20;
char *  Ox46DB228;
char *  Ox46DB268;
char *  Ox46DB3F8;
char *  Ox46DB588;
char *  Ox46DBA90;
char *  Ox46DBAD0;
char *  Ox46DBC60;
char *  Ox46DBDF0;
char *  Ox46DC2F8;
char *  Ox46DC338;
char *  Ox46DC4C8;
char *  Ox46DC658;
char *  Ox46DCB60;
char *  Ox46DCBA0;
char *  Ox46DCD30;
char *  Ox46DCEC0;
char *  Ox46DD3C8;
char *  Ox46DD408;
char *  Ox46DD598;
char *  Ox46DD728;
char *  Ox46DDC30;
char *  Ox46DDC70;
char *  Ox46DDE00;
char *  Ox46DDF90;
char *  Ox46DE498;
char *  Ox46DE4D8;
char *  Ox46DE668;
char *  Ox46DE7F8;
char *  Ox46DED00;
char *  Ox46DED40;
char *  Ox46DEED0;
char *  Ox46DF060;
char *  Ox46DF568;
char *  Ox46DF5A8;
char *  Ox46DF738;
char *  Ox46DF8C8;
char *  Ox46DFDD0;
char *  Ox46DFE10;
char *  Ox46DFFA0;
char *  Ox46E0130;
char *  Ox46E0638;
char *  Ox46E0678;
char *  Ox46E0808;
char *  Ox46E0998;
char *  Ox46E0EA0;
char *  Ox46E0EE0;
char *  Ox46E1070;
char *  Ox46E1200;
char *  Ox46E1708;
char *  Ox46E1748;
char *  Ox46E18D8;
char *  Ox46E1A68;
char *  Ox46E1F70;
char *  Ox46E1FB0;
char *  Ox46E2140;
char *  Ox46E22D0;
char *  Ox46E27D8;
char *  Ox46E2818;
char *  Ox46E29A8;
char *  Ox46E2B38;
char *  Ox46E3040;
char *  Ox46E3080;
char *  Ox46E3210;
char *  Ox46E33A0;
char *  Ox46E38A8;
char *  Ox46E38E8;
char *  Ox46E3A78;
char *  Ox46E3C08;
char *  Ox46E4110;
char *  Ox46E4150;
char *  Ox46E42E0;
char *  Ox46E4470;
char *  Ox46E4978;
char *  Ox46E94A8;
char *  Ox46F5828;
char *  Ox470EE98;
char *  Ox4714C88;
char *  Ox4717238;
  Ox416A868 = touch_malloc(12);
 Ox416A8A8 =  touch_malloc(16);
 Ox416A8E8 =  touch_malloc(16) ;
 Ox416A928 =  touch_malloc(16) ;
 Ox416A968 =  touch_malloc(16) ;
 Ox416A9A8 =  touch_malloc(16) ;
 Ox416A9E8 =  touch_malloc(12) ;
 Ox416AA28 =  touch_malloc(12) ;
 Ox416AA68 =  touch_malloc(12) ;
 Ox416AAA8 =  touch_malloc(12) ;
 Ox416AAE8 =  touch_malloc(12) ;
 Ox416AB28 =  touch_malloc(12) ;
 Ox416AB68 =  touch_malloc(16) ;
 Ox416ABA8 =  touch_malloc(16) ;
 Ox416ABE8 =  touch_malloc(16) ;
 Ox416AC28 =  touch_malloc(16) ;
 Ox416AC68 =  touch_malloc(1600) ;
 Ox416B2D8 =  touch_malloc(9600) ;
 Ox416D888 =  touch_malloc(1600) ;
 Ox416DEF8 =  touch_malloc(9600) ;
 Ox41704A8 =  touch_malloc(50000) ;
 Ox417C828 =  touch_malloc(104000) ;
 Ox4195E98 =  touch_malloc(24000) ;
 Ox419BC88 =  touch_malloc(330640) ;
 Ox41EC848 =  touch_malloc(96) ;
 Ox41EC8D8 =  touch_malloc(96) ;
 Ox41EC968 =  touch_malloc(96) ;
 Ox41EC9F8 =  touch_malloc(1920) ;
 Ox41ED1A8 =  touch_malloc(40) ;
 Ox41ED200 =  touch_malloc(240) ;
 Ox41ED320 =  touch_malloc(80) ;
 Ox41ED3A0 =  touch_malloc(80) ;
 Ox41ED420 =  touch_malloc(50000) ;
 Ox41F97A0 =  touch_malloc(96000) ;
 Ox4210ED0 =  touch_malloc(10000) ;
 Ox4213610 =  touch_malloc(4000) ;
 Ox42145E0 =  touch_malloc(400) ;
 Ox42147A0 =  touch_malloc(80) ;
 Ox4214820 =  touch_malloc(1080) ;
 Ox4214C88 =  touch_malloc(40000) ;
 Ox421E8F8 =  touch_malloc(40000) ;
 Ox4228568 =  touch_malloc(3200) ;
 Ox4229218 =  touch_malloc(480) ;
 Ox4229428 =  touch_malloc(480) ;
 Ox4229638 =  touch_malloc(120) ;
 Ox42296E0 =  touch_malloc(1320) ;
 Ox4268028 =  touch_malloc(1600000) ;
 Ox4229C38 =  touch_malloc(48000) ;
 Ox42357E8 =  touch_malloc(200000) ;
 Ox43EF028 =  touch_malloc(200000) ;
 Ox441FD98 =  touch_malloc(16000) ;
 Ox4266558 =  touch_malloc(4000) ;
 Ox43EEA58 =  touch_malloc(59) ;
 Ox4267528 =  touch_malloc(68) ;
 free(Ox43EEA58);
 Ox4423C48 =  touch_malloc(200000) ;
 Ox42675A0 =  touch_malloc(12) ;
 Ox43EEAC8 =  touch_malloc(12) ;
 Ox42675E0 =  touch_malloc(24) ;
 free(Ox42675A0);
 free(Ox43EEAC8);
 free(Ox42675E0);
 Ox43EEB08 =  touch_malloc(160) ;
 Ox4267628 =  touch_malloc(68) ;
 Ox43EEBD8 =  touch_malloc(104) ;
 Ox43EEC70 =  touch_malloc(68) ;
 Ox43EECE8 =  touch_malloc(68) ;
 Ox43EED60 =  touch_malloc(68) ;
 Ox43EEDD8 =  touch_malloc(16) ;
 Ox43EEE18 =  touch_malloc(12) ;
 Ox43EEE58 =  touch_malloc(12) ;
 Ox43EEE98 =  touch_malloc(24) ;
 Ox43EEEE0 =  touch_malloc(32) ;
 Ox43EEF30 =  touch_malloc(32) ;
 Ox43EEF80 =  touch_malloc(24) ;
 free(Ox43EEE18);
 free(Ox43EEE58);
 free(Ox43EEE98);
 free(Ox43EEEE0);
 Ox43EEFC8 =  touch_malloc(32) ;
 Ox42676A0 =  touch_malloc(32) ;
 Ox44EF028 =  touch_realloc(Ox4268028,1601600) ;
 Ox44549B8 =  touch_realloc(Ox4423C48,200200) ;
 Ox44857F0 =  touch_realloc(Ox416AC68,4816) ;
 Ox416B2D8 =  touch_realloc(Ox416B2D8,4472) ;
 Ox4676098 =  touch_realloc(Ox41EC9F8,3648) ;
 Ox4676F08 =  touch_malloc(16) ;
 Ox4676F48 =  touch_malloc(16) ;
 Ox4676F88 =  touch_malloc(28) ;
 Ox41ED420 =  touch_realloc(Ox41ED420,39435) ;
 Ox41F97A0 =  touch_realloc(Ox41F97A0,54848) ;
 Ox4229C38 =  touch_realloc(Ox4229C38,34236) ;
 Ox4486AF0 =  touch_realloc(Ox42357E8,200200) ;
 Ox44B7928 =  touch_realloc(Ox43EF028,200200) ;
 Ox44E8760 =  touch_realloc(Ox4214820,10152) ;
 Ox42676F0 =  touch_malloc(612) ;
 Ox44EAF38 =  touch_malloc(7514) ;
 Ox4676FD8 =  touch_malloc(12) ;
 Ox4267988 =  touch_malloc(198) ;
 Ox44ECCC8 =  touch_malloc(20) ;
 Ox4267A80 =  touch_malloc(223) ;
 Ox44ECD10 =  touch_malloc(24) ;
 Ox4267B90 =  touch_malloc(153) ;
 Ox4267C60 =  touch_malloc(8) ;
 Ox4267C98 =  touch_malloc(63) ;
 Ox4267D08 =  touch_malloc(444) ;
 Ox44ECD58 =  touch_malloc(3118) ;
 Ox4267EF8 =  touch_malloc(76) ;
 Ox44ED9B8 =  touch_malloc(1149) ;
 Ox44EDE68 =  touch_malloc(272) ;
 Ox44EDFA8 =  touch_malloc(3827) ;
 Ox4677028 =  touch_malloc(296) ;
 Ox4677180 =  touch_malloc(3806) ;
 Ox4678090 =  touch_malloc(284) ;
 Ox46781E0 =  touch_malloc(3767) ;
 Ox4267F78 =  touch_malloc(88) ;
 Ox46790C8 =  touch_malloc(1340) ;
 Ox44EEED0 =  touch_malloc(140) ;
 Ox4679638 =  touch_malloc(1730) ;
 Ox4679D30 =  touch_malloc(1720) ;
 Ox467A418 =  touch_malloc(13832) ;
 Ox467DA50 =  touch_malloc(1656) ;
 Ox467E0F8 =  touch_malloc(26091) ;
 Ox44EEF90 =  touch_malloc(76) ;
 Ox4684718 =  touch_malloc(1171) ;
 Ox4684BE0 =  touch_malloc(1180) ;
 Ox46850B0 =  touch_malloc(18684) ;
 Ox46899E0 =  touch_malloc(20) ;
 Ox4689A28 =  touch_malloc(94) ;
 Ox4689AB8 =  touch_malloc(68) ;
 Ox4689B30 =  touch_malloc(369) ;
 Ox4689CD8 =  touch_malloc(704) ;
 Ox4689FC8 =  touch_malloc(8778) ;
 Ox468C248 =  touch_malloc(16) ;
 Ox468C288 =  touch_malloc(109) ;
 Ox468C328 =  touch_malloc(116) ;
 Ox468C3D0 =  touch_malloc(1128) ;
 Ox468C868 =  touch_malloc(600) ;
 Ox468CAF0 =  touch_malloc(6765) ;
 Ox468E590 =  touch_malloc(96) ;
 Ox468E620 =  touch_malloc(1465) ;
 Ox468EC10 =  touch_malloc(1804) ;
 Ox468F350 =  touch_malloc(17930) ;
 Ox4693990 =  touch_malloc(112) ;
 Ox4693A30 =  touch_malloc(1410) ;
 Ox4693FE8 =  touch_malloc(632) ;
 Ox4694290 =  touch_malloc(8259) ;
 Ox4696308 =  touch_malloc(692) ;
 Ox46965F0 =  touch_malloc(6618) ;
 Ox4698000 =  touch_malloc(1088) ;
 Ox4698470 =  touch_malloc(11000) ;
 Ox469AF98 =  touch_malloc(712) ;
 Ox469B290 =  touch_malloc(6737) ;
 Ox469CD18 =  touch_malloc(896) ;
 Ox469D0C8 =  touch_malloc(10488) ;
 Ox469F9F0 =  touch_malloc(112) ;
 Ox469FA90 =  touch_malloc(929) ;
 Ox469FE68 =  touch_malloc(76) ;
 Ox469FEE8 =  touch_malloc(379) ;
 Ox46A0098 =  touch_malloc(140) ;
 Ox46A0158 =  touch_malloc(1289) ;
 Ox46A0698 =  touch_malloc(36) ;
 Ox46A06F0 =  touch_malloc(288) ;
 Ox46A0840 =  touch_malloc(192) ;
 Ox46A0930 =  touch_malloc(1242) ;
 Ox46A0E40 =  touch_malloc(44) ;
 Ox46A0EA0 =  touch_malloc(386) ;
 Ox46A1058 =  touch_malloc(32) ;
 Ox46A10A8 =  touch_malloc(461) ;
 Ox46A12A8 =  touch_malloc(2148) ;
 Ox46A1B40 =  touch_malloc(18786) ;
 Ox46A64D8 =  touch_malloc(12) ;
 Ox46A6518 =  touch_malloc(90) ;
 Ox46A65A8 =  touch_malloc(2592) ;
 Ox46A6FF8 =  touch_malloc(29817) ;
 Ox46AE4A8 =  touch_malloc(312) ;
 Ox46AE610 =  touch_malloc(3709) ;
 Ox46AF4C0 =  touch_malloc(456) ;
 Ox46AF6B8 =  touch_malloc(5843) ;
 Ox46B0DC0 =  touch_malloc(1160) ;
 Ox46B1278 =  touch_malloc(11962) ;
 Ox46B4168 =  touch_malloc(296) ;
 Ox46B42C0 =  touch_malloc(2652) ;
 Ox46B4D50 =  touch_malloc(272) ;
 Ox46B4E90 =  touch_malloc(2471) ;
 Ox46B5868 =  touch_malloc(516) ;
 Ox46B5AA0 =  touch_malloc(4817) ;
 Ox46B6DA8 =  touch_malloc(528) ;
 Ox46B6FE8 =  touch_malloc(5166) ;
 Ox46B8448 =  touch_malloc(136) ;
 Ox46B8500 =  touch_malloc(1285) ;
 Ox46B8A38 =  touch_malloc(376) ;
 Ox46B8BE0 =  touch_malloc(2839) ;
 Ox46B9728 =  touch_malloc(76) ;
 Ox46B97A8 =  touch_malloc(522) ;
 Ox46B99E8 =  touch_malloc(384) ;
 Ox46B9B98 =  touch_malloc(3081) ;
 Ox46BA7D8 =  touch_malloc(40) ;
 Ox46BA830 =  touch_malloc(343) ;
 Ox46BA9B8 =  touch_malloc(144) ;
 Ox46BAA78 =  touch_malloc(950) ;
 Ox46BAE60 =  touch_malloc(132) ;
 Ox46BAF18 =  touch_malloc(1129) ;
 Ox46BB3B8 =  touch_malloc(360) ;
 Ox46BB550 =  touch_malloc(4184) ;
 Ox46BC5D8 =  touch_malloc(360) ;
 Ox46BC770 =  touch_malloc(4183) ;
 Ox46BD7F8 =  touch_malloc(932) ;
 Ox46BDBD0 =  touch_malloc(9023) ;
 Ox46BFF40 =  touch_realloc(Ox4210ED0,14920) ;
 Ox46C39B8 =  touch_realloc(Ox4213610,4464) ;
 Ox4214C88 =  touch_realloc(Ox4214C88,6224) ;
 Ox421E8F8 =  touch_realloc(Ox421E8F8,10764) ;
 Ox4228568 =  touch_realloc(Ox4228568,2544) ;
 Ox46C4B58 =  touch_realloc(Ox416D888,3200) ;
 Ox46C5808 =  touch_realloc(Ox46C4B58,6400) ;
 Ox46C7138 =  touch_malloc(12) ;
 Ox46C7178 =  touch_malloc(352) ;
 free(Ox46C7178);
 Ox46C7308 =  touch_malloc(12) ;
 Ox46C7348 =  touch_malloc(15) ;
 Ox46C7388 =  touch_malloc(352) ;
 Ox46C7518 =  touch_malloc(1235) ;
 free(Ox46C7388);
 Ox46C7A20 =  touch_malloc(12) ;
 Ox46C7A60 =  touch_malloc(12) ;
 Ox46C7AA0 =  touch_malloc(12) ;
 Ox46C7AE0 =  touch_malloc(12) ;
 free(Ox46C7138);
 Ox46C7B20 =  touch_malloc(12) ;
 free(Ox46C7518);
 Ox46C7B60 =  touch_malloc(352) ;
 free(Ox46C7B60);
 Ox46C7CF0 =  touch_malloc(352) ;
 Ox46C7E80 =  touch_malloc(1235) ;
 free(Ox46C7CF0);
 free(Ox46C7B20);
 Ox46C8388 =  touch_malloc(12) ;
 free(Ox46C7E80);
 Ox46C83C8 =  touch_malloc(352) ;
 free(Ox46C83C8);
 Ox46C8558 =  touch_malloc(352) ;
 Ox46C86E8 =  touch_malloc(1235) ;
 free(Ox46C8558);
 free(Ox46C8388);
 Ox46C8BF0 =  touch_malloc(12) ;
 free(Ox46C86E8);
 Ox46C8C30 =  touch_malloc(352) ;
 free(Ox46C8C30);
 Ox46C8DC0 =  touch_malloc(352) ;
 Ox46C8F50 =  touch_malloc(1235) ;
 free(Ox46C8DC0);
 free(Ox46C8BF0);
 Ox46C9458 =  touch_malloc(12) ;
 free(Ox46C8F50);
 Ox46C9498 =  touch_malloc(352) ;
 free(Ox46C9498);
 Ox46C9628 =  touch_malloc(352) ;
 Ox46C97B8 =  touch_malloc(1235) ;
 free(Ox46C9628);
 free(Ox46C9458);
 Ox46C9CC0 =  touch_malloc(12) ;
 free(Ox46C97B8);
 Ox46C9D00 =  touch_malloc(352) ;
 free(Ox46C9D00);
 Ox46C9E90 =  touch_malloc(352) ;
 Ox46CA020 =  touch_malloc(1235) ;
 free(Ox46C9E90);
 free(Ox46C9CC0);
 Ox46CA528 =  touch_malloc(12) ;
 free(Ox46CA020);
 Ox46CA568 =  touch_malloc(352) ;
 free(Ox46CA568);
 Ox46CA6F8 =  touch_malloc(352) ;
 Ox46CA888 =  touch_malloc(1235) ;
 free(Ox46CA6F8);
 free(Ox46CA528);
 Ox46CAD90 =  touch_malloc(12) ;
 free(Ox46CA888);
 Ox46CADD0 =  touch_malloc(352) ;
 free(Ox46CADD0);
 Ox46CAF60 =  touch_malloc(352) ;
 Ox46CB0F0 =  touch_malloc(1235) ;
 free(Ox46CAF60);
 free(Ox46CAD90);
 Ox46CB5F8 =  touch_malloc(12) ;
 free(Ox46CB0F0);
 Ox46CB638 =  touch_malloc(352) ;
 free(Ox46CB638);
 Ox46CB7C8 =  touch_malloc(352) ;
 Ox46CB958 =  touch_malloc(1235) ;
 free(Ox46CB7C8);
 free(Ox46CB5F8);
 Ox46CBE60 =  touch_malloc(12) ;
 free(Ox46CB958);
 Ox46CBEA0 =  touch_malloc(352) ;
 free(Ox46CBEA0);
 Ox46CC030 =  touch_malloc(352) ;
 Ox46CC1C0 =  touch_malloc(1235) ;
 free(Ox46CC030);
 free(Ox46CBE60);
 Ox46CC6C8 =  touch_malloc(12) ;
 free(Ox46CC1C0);
 Ox46CC708 =  touch_malloc(352) ;
 free(Ox46CC708);
 Ox46CC898 =  touch_malloc(352) ;
 Ox46CCA28 =  touch_malloc(1235) ;
 free(Ox46CC898);
 free(Ox46CC6C8);
 Ox46CCF30 =  touch_malloc(12) ;
 free(Ox46CCA28);
 Ox46CCF70 =  touch_malloc(352) ;
 free(Ox46CCF70);
 Ox46CD100 =  touch_malloc(352) ;
 Ox46CD290 =  touch_malloc(1235) ;
 free(Ox46CD100);
 free(Ox46CCF30);
 Ox46CD798 =  touch_malloc(12) ;
 free(Ox46CD290);
 Ox46CD7D8 =  touch_malloc(352) ;
 free(Ox46CD7D8);
 Ox46CD968 =  touch_malloc(352) ;
 Ox46CDAF8 =  touch_malloc(1235) ;
 free(Ox46CD968);
 free(Ox46CD798);
 Ox46CE000 =  touch_malloc(12) ;
 free(Ox46CDAF8);
 Ox46CE040 =  touch_malloc(352) ;
 free(Ox46CE040);
 Ox46CE1D0 =  touch_malloc(352) ;
 Ox46CE360 =  touch_malloc(1235) ;
 free(Ox46CE1D0);
 free(Ox46CE000);
 Ox46CE868 =  touch_malloc(12) ;
 free(Ox46CE360);
 Ox46CE8A8 =  touch_malloc(352) ;
 free(Ox46CE8A8);
 Ox46CEA38 =  touch_malloc(352) ;
 Ox46CEBC8 =  touch_malloc(1235) ;
 free(Ox46CEA38);
 free(Ox46CE868);
 Ox46CF0D0 =  touch_malloc(12) ;
 free(Ox46CEBC8);
 Ox46CF110 =  touch_malloc(352) ;
 free(Ox46CF110);
 Ox46CF2A0 =  touch_malloc(352) ;
 Ox46CF430 =  touch_malloc(1235) ;
 free(Ox46CF2A0);
 free(Ox46CF0D0);
 Ox46CF938 =  touch_malloc(12) ;
 free(Ox46CF430);
 Ox46CF978 =  touch_malloc(352) ;
 free(Ox46CF978);
 Ox46CFB08 =  touch_malloc(352) ;
 Ox46CFC98 =  touch_malloc(1235) ;
 free(Ox46CFB08);
 free(Ox46CF938);
 Ox46D01A0 =  touch_malloc(12) ;
 free(Ox46CFC98);
 Ox46D01E0 =  touch_malloc(352) ;
 free(Ox46D01E0);
 Ox46D0370 =  touch_malloc(352) ;
 Ox46D0500 =  touch_malloc(1235) ;
 free(Ox46D0370);
 free(Ox46D01A0);
 Ox46D0A08 =  touch_malloc(12) ;
 free(Ox46D0500);
 Ox46D0A48 =  touch_malloc(352) ;
 free(Ox46D0A48);
 Ox46D0BD8 =  touch_malloc(352) ;
 Ox46D0D68 =  touch_malloc(1235) ;
 free(Ox46D0BD8);
 free(Ox46D0A08);
 Ox46D1270 =  touch_malloc(12) ;
 free(Ox46D0D68);
 Ox46D12B0 =  touch_malloc(352) ;
 free(Ox46D12B0);
 Ox46D1440 =  touch_malloc(352) ;
 Ox46D15D0 =  touch_malloc(1235) ;
 free(Ox46D1440);
 free(Ox46D1270);
 Ox46D1AD8 =  touch_malloc(12) ;
 free(Ox46D15D0);
 Ox46D1B18 =  touch_malloc(352) ;
 free(Ox46D1B18);
 Ox46D1CA8 =  touch_malloc(352) ;
 Ox46D1E38 =  touch_malloc(1235) ;
 free(Ox46D1CA8);
 free(Ox46D1AD8);
 Ox46D2340 =  touch_malloc(12) ;
 free(Ox46D1E38);
 Ox46D2380 =  touch_malloc(352) ;
 free(Ox46D2380);
 Ox46D2510 =  touch_malloc(352) ;
 Ox46D26A0 =  touch_malloc(1235) ;
 free(Ox46D2510);
 free(Ox46D2340);
 Ox46D2BA8 =  touch_malloc(12) ;
 free(Ox46D26A0);
 Ox46D2BE8 =  touch_malloc(352) ;
 free(Ox46D2BE8);
 Ox46D2D78 =  touch_malloc(352) ;
 Ox46D2F08 =  touch_malloc(1235) ;
 free(Ox46D2D78);
 free(Ox46D2BA8);
 Ox46D3410 =  touch_malloc(12) ;
 free(Ox46D2F08);
 Ox46D3450 =  touch_malloc(352) ;
 free(Ox46D3450);
 Ox46D35E0 =  touch_malloc(352) ;
 Ox46D3770 =  touch_malloc(1235) ;
 free(Ox46D35E0);
 free(Ox46D3410);
 Ox46D3C78 =  touch_malloc(12) ;
 free(Ox46D3770);
 Ox46D3CB8 =  touch_malloc(352) ;
 free(Ox46D3CB8);
 Ox46D3E48 =  touch_malloc(352) ;
 Ox46D3FD8 =  touch_malloc(1235) ;
 free(Ox46D3E48);
 free(Ox46D3C78);
 Ox46D44E0 =  touch_malloc(12) ;
 free(Ox46D3FD8);
 Ox46D4520 =  touch_malloc(352) ;
 free(Ox46D4520);
 Ox46D46B0 =  touch_malloc(352) ;
 Ox46D4840 =  touch_malloc(1235) ;
 free(Ox46D46B0);
 free(Ox46D44E0);
 Ox46D4D48 =  touch_malloc(12) ;
 free(Ox46D4840);
 Ox46D4D88 =  touch_malloc(352) ;
 free(Ox46D4D88);
 Ox46D4F18 =  touch_malloc(352) ;
 Ox46D50A8 =  touch_malloc(1235) ;
 free(Ox46D4F18);
 free(Ox46D4D48);
 Ox46D55B0 =  touch_malloc(12) ;
 free(Ox46D50A8);
 Ox46D55F0 =  touch_malloc(352) ;
 free(Ox46D55F0);
 Ox46D5780 =  touch_malloc(352) ;
 Ox46D5910 =  touch_malloc(1235) ;
 free(Ox46D5780);
 free(Ox46D55B0);
 Ox46D5E18 =  touch_malloc(12) ;
 free(Ox46D5910);
 Ox46D5E58 =  touch_malloc(352) ;
 free(Ox46D5E58);
 Ox46D5FE8 =  touch_malloc(352) ;
 Ox46D6178 =  touch_malloc(1235) ;
 free(Ox46D5FE8);
 free(Ox46D5E18);
 Ox46D6680 =  touch_malloc(12) ;
 free(Ox46D6178);
 Ox46D66C0 =  touch_malloc(352) ;
 free(Ox46D66C0);
 Ox46D6850 =  touch_malloc(352) ;
 Ox46D69E0 =  touch_malloc(1235) ;
 free(Ox46D6850);
 free(Ox46D6680);
 Ox46D6EE8 =  touch_malloc(12) ;
 free(Ox46D69E0);
 Ox46D6F28 =  touch_malloc(352) ;
 free(Ox46D6F28);
 Ox46D70B8 =  touch_malloc(352) ;
 Ox46D7248 =  touch_malloc(1235) ;
 free(Ox46D70B8);
 free(Ox46D6EE8);
 Ox46D7750 =  touch_malloc(12) ;
 free(Ox46D7248);
 Ox46D7790 =  touch_malloc(352) ;
 free(Ox46D7790);
 Ox46D7920 =  touch_malloc(352) ;
 Ox46D7AB0 =  touch_malloc(1235) ;
 free(Ox46D7920);
 free(Ox46D7750);
 Ox46D7FB8 =  touch_malloc(12) ;
 free(Ox46D7AB0);
 Ox46D7FF8 =  touch_malloc(352) ;
 free(Ox46D7FF8);
 Ox46D8188 =  touch_malloc(352) ;
 Ox46D8318 =  touch_malloc(1235) ;
 free(Ox46D8188);
 free(Ox46D7FB8);
 Ox46D8820 =  touch_malloc(12) ;
 free(Ox46D8318);
 Ox46D8860 =  touch_malloc(352) ;
 free(Ox46D8860);
 Ox46D89F0 =  touch_malloc(352) ;
 Ox46D8B80 =  touch_malloc(1235) ;
 free(Ox46D89F0);
 free(Ox46D8820);
 Ox46D9088 =  touch_malloc(12) ;
 free(Ox46D8B80);
 Ox46D90C8 =  touch_malloc(352) ;
 free(Ox46D90C8);
 Ox46D9258 =  touch_malloc(352) ;
 Ox46D93E8 =  touch_malloc(1235) ;
 free(Ox46D9258);
 free(Ox46D9088);
 Ox46D98F0 =  touch_malloc(12) ;
 free(Ox46D93E8);
 Ox46D9930 =  touch_malloc(352) ;
 free(Ox46D9930);
 Ox46D9AC0 =  touch_malloc(352) ;
 Ox46D9C50 =  touch_malloc(1235) ;
 free(Ox46D9AC0);
 free(Ox46D98F0);
 Ox46DA158 =  touch_malloc(12) ;
 free(Ox46D9C50);
 Ox46DA198 =  touch_malloc(352) ;
 free(Ox46DA198);
 Ox46DA328 =  touch_malloc(352) ;
 Ox46DA4B8 =  touch_malloc(1235) ;
 free(Ox46DA328);
 free(Ox46DA158);
 Ox46DA9C0 =  touch_malloc(12) ;
 free(Ox46DA4B8);
 Ox46DAA00 =  touch_malloc(352) ;
 free(Ox46DAA00);
 Ox46DAB90 =  touch_malloc(352) ;
 Ox46DAD20 =  touch_malloc(1235) ;
 free(Ox46DAB90);
 free(Ox46DA9C0);
 Ox46DB228 =  touch_malloc(12) ;
 free(Ox46DAD20);
 Ox46DB268 =  touch_malloc(352) ;
 free(Ox46DB268);
 Ox46DB3F8 =  touch_malloc(352) ;
 Ox46DB588 =  touch_malloc(1235) ;
 free(Ox46DB3F8);
 free(Ox46DB228);
 Ox46DBA90 =  touch_malloc(12) ;
 free(Ox46DB588);
 Ox46DBAD0 =  touch_malloc(352) ;
 free(Ox46DBAD0);
 Ox46DBC60 =  touch_malloc(352) ;
 Ox46DBDF0 =  touch_malloc(1235) ;
 free(Ox46DBC60);
 free(Ox46DBA90);
 Ox46DC2F8 =  touch_malloc(12) ;
 free(Ox46DBDF0);
 Ox46DC338 =  touch_malloc(352) ;
 free(Ox46DC338);
 Ox46DC4C8 =  touch_malloc(352) ;
 Ox46DC658 =  touch_malloc(1235) ;
 free(Ox46DC4C8);
 free(Ox46DC2F8);
 Ox46DCB60 =  touch_malloc(12) ;
 free(Ox46DC658);
 Ox46DCBA0 =  touch_malloc(352) ;
 free(Ox46DCBA0);
 Ox46DCD30 =  touch_malloc(352) ;
 Ox46DCEC0 =  touch_malloc(1235) ;
 free(Ox46DCD30);
 free(Ox46DCB60);
 Ox46DD3C8 =  touch_malloc(12) ;
 free(Ox46DCEC0);
 Ox46DD408 =  touch_malloc(352) ;
 free(Ox46DD408);
 Ox46DD598 =  touch_malloc(352) ;
 Ox46DD728 =  touch_malloc(1235) ;
 free(Ox46DD598);
 free(Ox46DD3C8);
 Ox46DDC30 =  touch_malloc(12) ;
 free(Ox46DD728);
 Ox46DDC70 =  touch_malloc(352) ;
 free(Ox46DDC70);
 Ox46DDE00 =  touch_malloc(352) ;
 Ox46DDF90 =  touch_malloc(1235) ;
 free(Ox46DDE00);
 free(Ox46DDC30);
 Ox46DE498 =  touch_malloc(12) ;
 free(Ox46DDF90);
 Ox46DE4D8 =  touch_malloc(352) ;
 free(Ox46DE4D8);
 Ox46DE668 =  touch_malloc(352) ;
 Ox46DE7F8 =  touch_malloc(1235) ;
 free(Ox46DE668);
 free(Ox46DE498);
 Ox46DED00 =  touch_malloc(12) ;
 free(Ox46DE7F8);
 Ox46DED40 =  touch_malloc(352) ;
 free(Ox46DED40);
 Ox46DEED0 =  touch_malloc(352) ;
 Ox46DF060 =  touch_malloc(1235) ;
 free(Ox46DEED0);
 free(Ox46DED00);
 Ox46DF568 =  touch_malloc(12) ;
 free(Ox46DF060);
 Ox46DF5A8 =  touch_malloc(352) ;
 free(Ox46DF5A8);
 Ox46DF738 =  touch_malloc(352) ;
 Ox46DF8C8 =  touch_malloc(1235) ;
 free(Ox46DF738);
 free(Ox46DF568);
 Ox46DFDD0 =  touch_malloc(12) ;
 free(Ox46DF8C8);
 Ox46DFE10 =  touch_malloc(352) ;
 free(Ox46DFE10);
 Ox46DFFA0 =  touch_malloc(352) ;
 Ox46E0130 =  touch_malloc(1235) ;
 free(Ox46DFFA0);
 free(Ox46DFDD0);
 Ox46E0638 =  touch_malloc(12) ;
 free(Ox46E0130);
 Ox46E0678 =  touch_malloc(352) ;
 free(Ox46E0678);
 Ox46E0808 =  touch_malloc(352) ;
 Ox46E0998 =  touch_malloc(1235) ;
 free(Ox46E0808);
 free(Ox46E0638);
 Ox46E0EA0 =  touch_malloc(12) ;
 free(Ox46E0998);
 Ox46E0EE0 =  touch_malloc(352) ;
 free(Ox46E0EE0);
 Ox46E1070 =  touch_malloc(352) ;
 Ox46E1200 =  touch_malloc(1235) ;
 free(Ox46E1070);
 free(Ox46E0EA0);
 Ox46E1708 =  touch_malloc(12) ;
 free(Ox46E1200);
 Ox46E1748 =  touch_malloc(352) ;
 free(Ox46E1748);
 Ox46E18D8 =  touch_malloc(352) ;
 Ox46E1A68 =  touch_malloc(1235) ;
 free(Ox46E18D8);
 free(Ox46E1708);
 Ox46E1F70 =  touch_malloc(12) ;
 free(Ox46E1A68);
 Ox46E1FB0 =  touch_malloc(352) ;
 free(Ox46E1FB0);
 Ox46E2140 =  touch_malloc(352) ;
 Ox46E22D0 =  touch_malloc(1235) ;
 free(Ox46E2140);
 free(Ox46E1F70);
 Ox46E27D8 =  touch_malloc(12) ;
 free(Ox46E22D0);
 Ox46E2818 =  touch_malloc(352) ;
 free(Ox46E2818);
 Ox46E29A8 =  touch_malloc(352) ;
 Ox46E2B38 =  touch_malloc(1235) ;
 free(Ox46E29A8);
 free(Ox46E27D8);
 Ox46E3040 =  touch_malloc(12) ;
 free(Ox46E2B38);
 Ox46E3080 =  touch_malloc(352) ;
 free(Ox46E3080);
 Ox46E3210 =  touch_malloc(352) ;
 Ox46E33A0 =  touch_malloc(1235) ;
 free(Ox46E3210);
 free(Ox46E3040);
 Ox46E38A8 =  touch_malloc(12) ;
 free(Ox46E33A0);
 Ox46E38E8 =  touch_malloc(352) ;
 free(Ox46E38E8);
 Ox46E3A78 =  touch_malloc(352) ;
 Ox46E3C08 =  touch_malloc(1235) ;
 free(Ox46E3A78);
 free(Ox46E38A8);
 Ox46E4110 =  touch_malloc(12) ;
 free(Ox46E3C08);
 Ox46E4150 =  touch_malloc(352) ;
 free(Ox46E4150);
 Ox46E42E0 =  touch_malloc(352) ;
 Ox46E4470 =  touch_malloc(1235) ;
 free(Ox46E42E0);
 free(Ox46E4110);
 Ox46E4978 =  touch_realloc(Ox416DEF8,19200) ;
 Ox46E94A8 =  touch_malloc(50000) ;
 Ox46F5828 =  touch_malloc(104000) ;
 Ox470EE98 =  touch_malloc(24000) ;
 Ox4714C88 =  touch_malloc(9600) ;
 Ox4717238 =  touch_malloc(1600) ;
 free(Ox46C7308);
 free(Ox46C7348);
 free(Ox46C7A20);
 free(Ox46C7A60);
 free(Ox46C7AA0);
 free(Ox46C7AE0);
 free(Ox46E4470);
};
____

This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.

Any views expressed in this message are those of the sender.

Comment 19 Julian Seward 2006-08-14 13:57:23 UTC
I can reproduce this using the test program, thanks.
Following a quick run with --trace-syscalls=yes I have
a nasty feeling this is related to sys_mremap, which is
a semantic disaster area of a syscall.
Comment 20 Julian Seward 2006-08-14 14:14:10 UTC
Yep, forcing glibc to not use mremap (by making that
syscall always fail) makes the program work, as per 
the following patch (not a proper solution).  
Am investigating more ..

Index: coregrind/m_syswrap/syswrap-generic.c
===================================================================
--- coregrind/m_syswrap/syswrap-generic.c       (revision 5999)
+++ coregrind/m_syswrap/syswrap-generic.c       (working copy)
@@ -2123,6 +2123,8 @@
                     unsigned long, old_addr, unsigned long, old_size,
                     unsigned long, new_size, unsigned long, flags);
    }
+SET_STATUS_Failure(VKI_ENOSYS);
+return;
    SET_STATUS_from_SysRes(
       do_mremap((Addr)ARG1, ARG2, (Addr)ARG5, ARG3, ARG4, tid)
    );
Comment 21 Julian Seward 2006-08-16 13:44:43 UTC
Smaller version of Philippe's program which causes same problem:
#include <stdlib.h>
char * touch_malloc (int size) 
{
  char * result;
  int i;
  result = malloc (size);
  for (i = 0; i < size; i++)
    *(result + i) = 'a';

  return result;
}
char * touch_realloc (char * ptr, int size) 
{
  char * result;
  int i;
  result = realloc (ptr, size);
  for (i = 0; i < size; i++)
    *(result + i) = 'a';

  return result;
}

int main ( void )
{
  char *a1, *b1, *a2, *b2;
  a1 = touch_malloc(1600000) ;
  b1 = touch_malloc(200000) ;
  a2 = touch_realloc(a1, 1601600) ;
  b2 = touch_realloc(b1, 200000) ;
  return 0;
};
Comment 22 Julian Seward 2006-08-16 16:24:45 UTC
Fixed (svn r6003).  Please verify.

glibc's realloc for large blocks sometimes uses sys_mremap.  
V was mishandling mremap by allowing the remapping to trash
parts of existing mappings, hence causing glibc to abort with
the heap-corruption message.  When running on memcheck and massif,
glibc's realloc, and hence mremap, is not used, which is why
the program worked OK on those tools.
Comment 23 philippe.waroquiers 2006-08-22 04:07:04 UTC
>Fixed (svn r6003).  Please verify.


Tested and looks ok (verified with 3.3.0 SVN).
thanks again

Philippe


____

This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.

Any views expressed in this message are those of the sender.