i got some simple code file
mangen.c:
///////////// begin of the file
void mangen(int* data)
{
for(int j=0; j<100; j++)
for(int i=0; i<100; i++)
data[j*100+i] = 111;
}
//////// end of the file
I compile it with mingw (on win32)
c:\mingw\bin\gcc -std=c99 -c mangen.c -fno-exceptions -march=core2 -mtune=generic -mfpmath=both -msse2
it yeilds to mangen.o file which is 400 bytes
00000000 4C 01 03 00 00 00 00 00-D8 00 00 00 0A 00 00 00 L...............
00000010 00 00 05 01 2E 74 65 78-74 00 00 00 00 00 00 00 .....text.......
00000020 00 00 00 00 4C 00 00 00-8C 00 00 00 00 00 00 00 ....L...........
00000030 00 00 00 00 00 00 00 00-20 00 30 60 2E 64 61 74 ........ .0`.dat
00000040 61 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 a...............
00000050 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000060 40 00 30 C0 2E 62 73 73-00 00 00 00 00 00 00 00 #.0..bss........
00000070 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000080 00 00 00 00 00 00 00 00-80 00 30 C0 55 89 E5 83 ..........0.U...
00000090 EC 10 C7 45 FC 00 00 00-00 EB 34 C7 45 F8 00 00 ...E......4.E...
000000A0 00 00 EB 21 8B 45 FC 6B-D0 64 8B 45 F8 01 D0 8D ...!.E.k.d.E....
000000B0 14 85 00 00 00 00 8B 45-08 01 D0 C7 00 6F 00 00 .......E.....o..
000000C0 00 83 45 F8 01 83 7D F8-63 7E D9 83 45 FC 01 83 ..E...}.c~..E...
000000D0 7D FC 63 7E C6 C9 C3 90-2E 66 69 6C 65 00 00 00 }.c~.....file...
000000E0 00 00 00 00 FE FF 00 00-67 01 6D 61 6E 67 65 6E ........g.mangen
000000F0 2E 63 00 00 00 00 00 00-00 00 00 00 5F 6D 61 6E .c.........._man
00000100 67 65 6E 00 00 00 00 00-01 00 20 00 02 01 00 00 gen....... .....
00000110 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000120 2E 74 65 78 74 00 00 00-00 00 00 00 01 00 00 00 .text...........
00000130 03 01 4B 00 00 00 00 00-00 00 00 00 00 00 00 00 ..K.............
00000140 00 00 00 00 2E 64 61 74-61 00 00 00 00 00 00 00 .....data.......
00000150 02 00 00 00 03 01 00 00-00 00 00 00 00 00 00 00 ................
00000160 00 00 00 00 00 00 00 00-2E 62 73 73 00 00 00 00 .........bss....
00000170 00 00 00 00 03 00 00 00-03 01 00 00 00 00 00 00 ................
00000180 00 00 00 00 00 00 00 00-00 00 00 00 04 00 00 00 ................
Now I need to know where is the binary chunk containing
above function body in here
Could someone provide some simple code that will allow me to retrive
this boundaries ?
(assume that function body may be shorter or longer and also
there may be other functions or data in source fite added so
it will move in chunk but I suspect procedure to localise it
should be not very complex.
You can use objdump -Fd mangen.o to find out file offset and lenght of a function.
Alternatively, you can use readelf -s mangen.o to find out size of a function.
You may define something like int abc = 0x11223344; in the beginning and end of function and use the constants to locate the function body.
You can use objdump or nm.
For instance, try:
nm mangen.o
Or
objdump -t mangen.o
If you need to use your own code, have a look here:
http://www.rohitab.com/discuss/topic/38591-c-import-table-parser/
It will give you something to start with. You can find much more information about the format in MSDN.
If you are into Python, there is nice tool/library (including source code) that can be helpful:
https://code.google.com/p/pefile/
Related
I extracted a large number of bytes from an ISO into Notepad++ and ended up with 131,076 characters worth of space-separated values.
I would like to find where there occur at least three specific values within a fixed number of bytes of each other.
As an example, I would like the values 11, 12, and B4 to be highlighted if they are within 18 bytes (=53 characters) of each other, in this:
03 00 1F 06 01 15 12 10 00 00 00 00 00 05 00 00 00 00
04 00 3B 06 02 25 02 11 00 03 06 00 00 85 65 88 00 00
05 00 24 06 11 15 12 10 00 06 09 00 00 0C 7C 1A 00 00
06 00 41 04 12 24 01 11 00 00 00 00 00 42 00 00 00 00
07 00 26 03 11 15 12 01 00 00 00 00 00 B4 00 00 00 00
08 00 0E 06 10 15 11 11 00 08 00 00 00 CB 7C 00 00 00
09 00 0A 00 10 11 01 21 00 06 00 00 00 68 BD 00 00 00
0A 00 5B 07 10 10 20 11 00 00 00 00 00 3D 00 00 00 00
0B 00 40 00 12 24 01 12 00 00 00 00 00 00 00 00 00 00
The required result is the following, where the square brackets indicate which values need to be highlighted:
03 00 1F 06 01 15 12 10 00 00 00 00 00 05 00 00 00 00
04 00 3B 06 02 25 02 11 00 03 06 00 00 85 65 88 00 00
05 00 24 06 11 15 12 10 00 06 09 00 00 0C 7C 1A 00 00
06 00 41 04 12 24 01 11 00 00 00 00 00 42 00 00 00 00
07 00 26 03[11]15[12]01 00 00 00 00 00[B4]00 00 00 00
08 00 0E 06 10 15 11 11 00 08 00 00 00 CB 7C 00 00 00
09 00 0A 00 10 11 01 21 00 06 00 00 00 68 BD 00 00 00
0A 00 5B 07 10 10 20 11 00 00 00 00 00 3D 00 00 00 00
0B 00 40 00 12 24 01 12 00 00 00 00 00 00 00 00 00 00
Can this be done? (If not, is it possible to do so for only two values?)
Notes:
The values can appear in any order.
I don't want to clear the data around the values, just highlight them or make them stand out so that I can track and use the values to understand how a certain table works within an ISO.
The above example contains line-feeds/carriage returns just for readability. The actual data doesn't contain any - all the values are space-separated only.
I am using openssl in my project. When I exit my application I get "Detected memory leaks!" in Visual Studio 2013.
Detected memory leaks!
Dumping objects ->
{70202} normal block at 0x056CB738, 12 bytes long.
Data: <8 j > 38 E8 6A 05 00 00 00 00 04 00 00 00
{70201} normal block at 0x056CB6E8, 16 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{70200} normal block at 0x056CB698, 20 bytes long.
Data: < l > 00 00 00 00 E8 B6 6C 05 00 00 00 00 04 00 00 00
{70199} normal block at 0x056AE838, 12 bytes long.
Data: < l > 04 00 00 00 98 B6 6C 05 00 00 00 00
{70198} normal block at 0x056CB618, 64 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{70197} normal block at 0x056CB578, 96 bytes long.
Data: < l 3 3 > 18 B6 6C 05 00 FE C0 33 C0 FD C0 33 08 00 00 00
Object dump complete.
When I add
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
_CrtSetBreakAlloc(70202);
to main main function I always get a breakpoint at the allocation of the x509 store, no matter for which of the 6 numbers (70202,...) I set the break point.
I initialize and uninitialize the x509 store in a class' constructor and destructor (see below).
Is there anything else I need to look out for when using the x509_STORE?
Foo::CSCACerts::CSCACerts(void)
{
m_store = X509_STORE_new();
}
Foo::CSCACerts::~CSCACerts(void)
{
X509_STORE_free( m_store );
}
because of some (strange) problems in my C++-project I used Visual Leak Detector (for the first time), to check the project on memory leaks.
So I got i.a. the follwoing reports:
WARNING: Visual Leak Detector detected memory leaks!
---------- Block 4 at 0x004D07B0: 200 bytes ----------
Leak Hash: 0xD2D1B4A0, Count: 1, Total 200 bytes
Call Stack (TID 8796):
ucrtbase.dll!malloc()
f:\dd\vctools\crt\vcstartup\src\heap\new_scalar.cpp (19): LASS.exe!operator new() + 0x8 bytes
clr.dll!0x72D616E5()
Data:
28 75 14 03 00 00 00 00 01 00 00 00 00 00 00 00 (u...... ........
9A 99 99 99 99 99 B9 3F 50 00 00 00 0A 00 00 00 .......? P.......
00 00 00 00 F4 01 00 00 00 00 00 00 01 00 00 00 ........ ........
7B 14 AE 47 E1 7A 74 3F 14 00 00 00 BA FF FF FF {..G.zt? ........
00 00 00 00 F4 01 00 00 00 00 00 00 01 00 00 00 ........ ........
7B 14 AE 47 E1 7A 84 3F 00 00 00 00 64 00 00 00 {..G.z.? ....d...
00 00 00 00 01 00 00 00 14 00 00 00 46 00 00 00 ........ ....F...
00 00 00 00 64 00 00 00 00 00 00 00 F4 01 00 00 ....d... ........
01 00 00 00 B8 E2 13 03 F0 AD 18 03 00 00 00 00 ........ ........
C8 E2 13 03 C8 AB 18 03 00 00 00 00 78 E3 13 03 ........ ....x...
B8 AC 18 03 00 00 00 00 68 E2 13 03 E8 AC 18 03 ........ h.......
00 00 00 00 14 00 00 00 01 00 00 00 64 00 00 00 ........ ....d...
01 00 00 00 00 00 00 00 ........ ........
---------- Block 20 at 0x004D0880: 200 bytes ----------
Leak Hash: 0xD2D1B4A0, Count: 1, Total 200 bytes
Call Stack (TID 8796):
ucrtbase.dll!malloc()
f:\dd\vctools\crt\vcstartup\src\heap\new_scalar.cpp (19): LASS.exe!operator new() + 0x8 bytes
clr.dll!0x72D616E5()
Data:
78 74 14 03 00 00 00 00 01 00 00 00 00 00 00 00 xt...... ........
9A 99 99 99 99 99 B9 3F 50 00 00 00 0A 00 00 00 .......? P.......
00 00 00 00 F4 01 00 00 00 00 00 00 01 00 00 00 ........ ........
7B 14 AE 47 E1 7A 74 3F 14 00 00 00 BA FF FF FF {..G.zt? ........
00 00 00 00 F4 01 00 00 00 00 00 00 01 00 00 00 ........ ........
7B 14 AE 47 E1 7A 84 3F 00 00 00 00 64 00 00 00 {..G.z.? ....d...
00 00 00 00 01 00 00 00 14 00 00 00 46 00 00 00 ........ ....F...
00 00 00 00 64 00 00 00 00 00 00 00 F4 01 00 00 ....d... ........
01 00 00 00 38 E2 13 03 00 F0 15 03 00 00 00 00 ....8... ........
B8 E1 13 03 88 00 7F 05 00 00 00 00 08 E2 13 03 ........ ........
20 FF 7E 05 00 00 00 00 E8 E1 13 03 80 FF 7E 05 ..~..... ......~.
00 00 00 00 14 00 00 00 01 00 00 00 64 00 00 00 ........ ....d...
01 00 00 00 00 00 00 00 ........ ........
---------- Block 31 at 0x0053E1B8: 72 bytes ----------
Leak Hash: 0x3F88029B, Count: 1, Total 72 bytes
Call Stack (TID 8796):
ucrtbase.dll!malloc()
f:\dd\vctools\crt\vcstartup\src\heap\new_scalar.cpp (19): LASS.exe!operator new() + 0x8 bytes
clr.dll!0x72D616E5()
Data:
60 BC 55 00 40 3E 80 05 A0 3F 80 05 A0 3F 80 05 `.U.#>.. .?...?..
60 BB 55 00 20 34 18 03 00 00 00 00 00 00 00 00 `.U..4.. ........
00 00 00 00 20 00 00 00 2F 00 00 00 80 BC 55 00 ........ /.....U.
00 2E 18 03 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
20 00 00 00 2F 00 00 00 ..../... ........
---------- Block 33 at 0x0055BB60: 8 bytes ----------
Leak Hash: 0xA49C5AA6, Count: 1, Total 8 bytes
Call Stack (TID 8796):
ucrtbase.dll!malloc()
f:\dd\vctools\crt\vcstartup\src\heap\new_scalar.cpp (19): LASS.exe!operator new() + 0x8 bytes
clr.dll!0x72D616E5()
Data:
C8 E1 53 00 00 00 00 00
..S..... ........
//And many more...
Unfortunatly I do not understand, what VLD wants to say is the problem.
With a double-click on the "f:\dd..."-lines it should set my courser to the line with the problem, shouldn´t it? But it dosen´t.
My question is now: How do I get to the area of the problem or in other words "how do I read these reports"?
In addition:
I use Visual Studio 2015
The project is a C++ Windows Forms Project
I included the vld.h in the additional includes and the lib-directory to the additional libraries of the project
In the main() I use #include <vld.h> and _CrtDumpMemoryLeaks();
EDIT:
My Main (a reduced version, but gives similar reports):
//some class-includes
#include <vld.h>
using namespace System;
using namespace System::Windows::Forms;
using namespace std;
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
[STAThread]
void Main()
{
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);
Experiment* experiment = new Experiment();
Experiment_List* running_experiments = new Experiment_List();
while(!experiment->end) {
experiment= new Experiment();
LASS::MainWindow form(experiment, running_experiments);
form.ShowDialog();
if(!experiment->end){
running_experiments->register_experiment(experiment);
}
}
running_experimente->end_all();
_CrtDumpMemoryLeaks();
exit(0);
}
Unfortunatley there are about 40 classes, that I do not want to post...
I don't know where the problem exact is.
For me, it helps to run the program in RELEASE Mode, instead of DEBUG mode.
I suppose, my problem is the handling of managed and unmanaged code together.
I have unmanaged code inside managed code.
It seams as if CLR use a different new operator in Debug mode. Not as conform as the c++ standard.
According to: Using push_back() for STL List in C++ causes Access Violation, Crash
If you malloc() a C++ class, no constructors will be called for any of
that class's fields
And the VS will step into a constructor in class new_scalar.cpp.
Folks say that is depending of the Visual Leak Detector (VLD). You use them in your includes.
In the End, try to distinguish your code with
#pragma managed
and
#pragma unmanaged
And run in RELEASE mode.
I am testing my dll that I created. It in turn use several other dlls. My Dll tester application reports memory leaks when I start the test application and exit without doing anything except loading dll using LoadLibrary. It doesn't show the exact files in my dll source code. There are no leaks if I don't load the dll. It is an MFC dll and has App class. I removed everything from the dll's app class so it does nothing but I still get memory leaks report when I load it. I created another set of dummy dll and test application but that doesn't report any leaks so it has to do with my original dll, perhaps its linkage with other dlls?
I have tried using _crtBreakAlloc = {allocation_#}; technique but it doesn't stop the debugger either. I am quite lost if this memory leak is real. I see from documentation it can report false positive. Could this be false positive just because my dll is linked to bunch of other dlls? I can't think of anything else because I have commented out all functionality from dll.
Here is the memory leak erros
Detected memory leaks!
Dumping objects ->
{250} client block at 0x00567E40, subtype c0, 64 bytes long.
a CDynLinkLibrary object at $00567E40, 64 bytes long
a CDynLinkLibrary object at $00567E40, 64 bytes long
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {244} normal block at 0x00567C20, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {243} normal block at 0x00567BC8, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {242} normal block at 0x00567B58, 52 bytes long.
Data: < x > E4 B8 07 78 11 00 00 00 11 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {241} normal block at 0x00566C08, 40 bytes long.
Data: < x > E4 B8 07 78 0B 00 00 00 0B 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {240} normal block at 0x00566BA8, 32 bytes long.
Data: < x > E4 B8 07 78 07 00 00 00 07 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {239} normal block at 0x00566B50, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {238} normal block at 0x00566AE0, 46 bytes long.
Data: < x > E4 B8 07 78 0E 00 00 00 0E 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {237} normal block at 0x00566A70, 48 bytes long.
Data: < x > E4 B8 07 78 0F 00 00 00 0F 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {235} normal block at 0x005676B0, 42 bytes long.
Data: < x > E4 B8 07 78 0C 00 00 00 0C 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {234} normal block at 0x00567658, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {233} normal block at 0x00567600, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {232} normal block at 0x00567590, 50 bytes long.
Data: < x > E4 B8 07 78 10 00 00 00 10 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {231} normal block at 0x00567538, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {230} normal block at 0x005674E0, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {229} normal block at 0x00567488, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {228} normal block at 0x00567430, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {227} normal block at 0x005673D8, 24 bytes long.
Data: < x > E4 B8 07 78 03 00 00 00 03 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {226} normal block at 0x00567380, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {225} normal block at 0x00567328, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {224} normal block at 0x005672C0, 40 bytes long.
Data: < x > E4 B8 07 78 0B 00 00 00 0B 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {223} normal block at 0x00567268, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {222} normal block at 0x00567200, 44 bytes long.
Data: < x > E4 B8 07 78 0D 00 00 00 0D 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {221} normal block at 0x00567198, 38 bytes long.
Data: < x > E4 B8 07 78 0A 00 00 00 0A 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {220} normal block at 0x00567140, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {219} normal block at 0x005670E8, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {218} normal block at 0x00567080, 38 bytes long.
Data: < x > E4 B8 07 78 0A 00 00 00 0A 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {217} normal block at 0x00567028, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {216} normal block at 0x00566FD0, 24 bytes long.
Data: < x > E4 B8 07 78 03 00 00 00 03 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {215} normal block at 0x00566F78, 24 bytes long.
Data: < x > E4 B8 07 78 03 00 00 00 03 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {214} normal block at 0x00566F18, 36 bytes long.
Data: < x > E4 B8 07 78 09 00 00 00 09 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {213} normal block at 0x00566EC0, 24 bytes long.
Data: < x > E4 B8 07 78 03 00 00 00 03 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {212} normal block at 0x00566E68, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {211} normal block at 0x00566E10, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {210} normal block at 0x00566DB8, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {209} normal block at 0x00566D60, 24 bytes long.
Data: < x > E4 B8 07 78 03 00 00 00 03 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {208} normal block at 0x00566D08, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {207} normal block at 0x00566CB0, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {206} normal block at 0x00561918, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {205} normal block at 0x005618C0, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {204} normal block at 0x00561868, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {202} normal block at 0x005669F8, 60 bytes long.
Data: < x > E4 B8 07 78 15 00 00 00 15 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {201} normal block at 0x00566988, 46 bytes long.
Data: < x > E4 B8 07 78 0E 00 00 00 0E 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {200} normal block at 0x00566920, 42 bytes long.
Data: < x > E4 B8 07 78 0C 00 00 00 0C 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {199} normal block at 0x005668C8, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {198} normal block at 0x00566868, 32 bytes long.
Data: < x > E4 B8 07 78 07 00 00 00 07 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {197} normal block at 0x00566800, 44 bytes long.
Data: < x > E4 B8 07 78 0D 00 00 00 0D 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {196} normal block at 0x00566790, 50 bytes long.
Data: < x > E4 B8 07 78 10 00 00 00 10 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {195} normal block at 0x00566718, 60 bytes long.
Data: < x > E4 B8 07 78 15 00 00 00 15 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {194} normal block at 0x005666C0, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {193} normal block at 0x00566040, 48 bytes long.
Data: < x > E4 B8 07 78 0F 00 00 00 0F 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {192} normal block at 0x00561C98, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {81} normal block at 0x00561BA0, 32 bytes long.
Data: < x > E4 B8 07 78 07 00 00 00 07 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {80} normal block at 0x00561B48, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {79} normal block at 0x00561AE0, 44 bytes long.
Data: < x > E4 B8 07 78 0D 00 00 00 0D 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {78} normal block at 0x00561A80, 34 bytes long.
Data: < x > E4 B8 07 78 08 00 00 00 08 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {77} normal block at 0x00561A20, 30 bytes long.
Data: < x > E4 B8 07 78 06 00 00 00 06 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {76} normal block at 0x005613D0, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {75} normal block at 0x005619A8, 56 bytes long.
Data: < x > E4 B8 07 78 13 00 00 00 13 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {74} normal block at 0x00561378, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {72} normal block at 0x005617F8, 48 bytes long.
Data: < x > E4 B8 07 78 0F 00 00 00 0F 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {71} normal block at 0x005617A0, 28 bytes long.
Data: < x > E4 B8 07 78 05 00 00 00 05 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {70} normal block at 0x00561748, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {69} normal block at 0x005616D0, 54 bytes long.
Data: < x > E4 B8 07 78 12 00 00 00 12 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {68} normal block at 0x00561670, 34 bytes long.
Data: < x > E4 B8 07 78 08 00 00 00 08 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {67} normal block at 0x00561618, 22 bytes long.
Data: < x > E4 B8 07 78 02 00 00 00 02 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {66} normal block at 0x005615B8, 36 bytes long.
Data: < x > E4 B8 07 78 09 00 00 00 09 00 00 00 01 00 00 00
Object dump complete.
Is there another way I can double check the memory leaks don't exist? I installed deleaker as well but it is buggy program, it holds on pdb files and was not releasing it...that caused me more pain.
According to the following MSKB article, this is probably expected:
Memory leaks are reported when you use multiple MFC DLLs
Quoting from the linked page:
These memory leaks are reported when multiple versions of the MFC DLL
are loaded in the same process. Since MFC extension (AFXDLL) DLLs
require the exact same MFC DLL as the call application, this problem
can only occur when using MFC regular (USRDLL) DLLs or ActiveX
Controls (OCX) that use the shared version of MFC.
The most common case is mixing ANSI (MFC4xd.DLL) and UNICODE
(MFC4xxUd.DLL) versions of MFC in the same process. This can also
occur when mixing MFC42d.DLL and MFC40d.DLL.
And as far as resolving the "problem" goes:
These memory leak notifications are false, and can be ignored. Since
neither copy of MFC knows about the other ones, it's not easy to stop
these false leaks from being reported.
I have searched the web for an way to convert the TMX Data into some sort of usable data but I cannot seem to use Zlib to inflate the data I get back from a Base64 Decode function. I'm unaware if that's how it works, but from what I looked around and I'm guessing That I am supposed to Deflate the code, then inflate it with Zlib.
So: TMX Data -> Base64 -> Decode -> Decoded Data -> Zlib -> Inflate -> Usable Data?
Here's my source code:
const std::string EncryptedString = "eJxjZGBgYMSCZYCYHYilccgPNnVqOLAQmjp2PFgPiJmh6iSBWApKI7OlkNTQAgMA4AIDoQ==";
FILE *wfile;
// Will contain decoded data
wfile = fopen("testFile", "w");
fprintf(wfile, base64_decode(EncryptedString).c_str());
Then I open the same file with the decoded data, which is:
xœcd```Ä‚e€˜ˆ¥qÈ6uj8°š:v<Xˆ™¡ê$X
J#³¥ÔÐ
And try to inflate it with Zlib using the Zlib inflate function in the doc's
FILE *source;
// Contains decoded data.
source = fopen("testFile", "r");
FILE *dest;
// We write decompressed data to this file.
dest = fopen("testOutFile", "w");
zerr(Z_Inflate(source, dest));
Yet Zlib returns an error message of "Invalid or incomplete deflate data"
Here's the code for the Zlib Function:
inline int Z_Inflate(FILE *source, FILE *dest)
{
int ret;
unsigned have;
z_stream strm;
Bytef in[CHUNK];
Bytef out[CHUNK];
/* allocate inflate state */
strm.zalloc = Z_NULL;
strm.zfree = Z_NULL;
strm.opaque = Z_NULL;
strm.avail_in = 0;
strm.next_in = Z_NULL;
ret = inflateInit(&strm);
if (ret != Z_OK)
return ret;
/* decompress until deflate stream ends or end of file */
do {
strm.avail_in = fread(in, 1, CHUNK, source);
if (ferror(source)) {
(void)inflateEnd(&strm);
return Z_ERRNO;
}
if (strm.avail_in == 0)
break;
strm.next_in = in;
/* run inflate() on input until output buffer not full */
do {
strm.avail_out = CHUNK;
strm.next_out = out;
ret = inflate(&strm, Z_NO_FLUSH);
assert(ret != Z_STREAM_ERROR); /* state not clobbered */
switch (ret) {
case Z_NEED_DICT:
ret = Z_DATA_ERROR; /* and fall through */
case Z_DATA_ERROR:
case Z_MEM_ERROR:
(void)inflateEnd(&strm);
return ret;
}
have = CHUNK - strm.avail_out;
if (fwrite(out, 1, have, dest) != have || ferror(dest)) {
(void)inflateEnd(&strm);
return Z_ERRNO;
}
} while (strm.avail_out == 0);
/* done when inflate() says it's done */
} while (ret != Z_STREAM_END);
/* clean up and return */
(void)inflateEnd(&strm);
return ret == Z_STREAM_END ? Z_OK : Z_DATA_ERROR;
}
/* report a zlib or i/o error */
inline void zerr(int ret)
{
fputs("zpipe: ", stderr);
switch (ret) {
case Z_ERRNO:
if (ferror(stdin))
fputs("error reading stdin\n", stderr);
if (ferror(stdout))
fputs("error writing stdout\n", stderr);
break;
case Z_STREAM_ERROR:
fputs("invalid compression level\n", stderr);
break;
case Z_DATA_ERROR:
fputs("invalid or incomplete deflate data\n", stderr);
break;
case Z_MEM_ERROR:
fputs("out of memory\n", stderr);
break;
case Z_VERSION_ERROR:
fputs("zlib version mismatch!\n", stderr);
}
}
Any help would be greatly appreciated as I would love to use the tiled editor for my map files. It's seeming to be more of a headache.
Worked for me. After decoding the base64 string, I get in hex:
78 9c 63 64 60 60 60 c4 82 65 80 98 1d 88 a5 71
c8 0f 36 75 6a 38 b0 10 9a 3a 76 3c 58 0f 88 99
a1 ea 24 81 58 0a 4a 23 b3 a5 90 d4 d0 02 03 00
e0 02 03 a1
That is a valid zlib stream that decodes with no errors to this in hex:
01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
01 00 00 00 01 00 00 00 1c 00 00 00 07 00 00 00
1b 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
1c 00 00 00 07 00 00 00 1b 00 00 00 01 00 00 00
01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
01 00 00 00 01 00 00 00 1c 00 00 00 07 00 00 00
1b 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
1c 00 00 00 07 00 00 00 1b 00 00 00 01 00 00 00
01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
01 00 00 00 01 00 00 00 1c 00 00 00 07 00 00 00
1b 00 00 00 01 00 00 00 26 00 00 00 26 00 00 00
26 00 00 00 26 00 00 00 26 00 00 00 26 00 00 00
12 00 00 00 07 00 00 00 1b 00 00 00 01 00 00 00
07 00 00 00 07 00 00 00 07 00 00 00 07 00 00 00
07 00 00 00 07 00 00 00 07 00 00 00 2e 00 00 00
03 00 00 00 01 00 00 00 19 00 00 00 1a 00 00 00
19 00 00 00 19 00 00 00 1a 00 00 00 19 00 00 00
1a 00 00 00 03 00 00 00 01 00 00 00 01 00 00 00
01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
What kind of machine are you on? If it's Windows (shudder), you may need to make sure that your stdio functions are not trying to do end-of-line conversions. Use fopen(..., "wb") and fopen(..., "rb") for binary writing and reading.