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).
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
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
Does it work with --tool=none ?
>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.
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.
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.
> 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.
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)?
> 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.
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.
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.
> 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?
>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.
>------- 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.
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.
>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.
>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.
>------- 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.
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.
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) );
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; };
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.
>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.