Am I doing something wrong here?

[JamesSchumacher]

Can someone take a look at this source and tell me if they see anything wrong with it? Thanks. I get an intermittent bug that happens at random. It crashes, but it crashes at different points on different data sets, and it should not. No index calculation (other than the hash code, the and mask should prevent any index out of bounds) is done based on any supplied data buffer.

I want to know why I am getting this access violation. I looked at the code, and I see nothing wrong with it - then again, it's probably something in front of my face that I am missing. Then again, I am working without a debugger to be able to track it down as well. Someone with a debugger could help me out big time.

[spartygw]

James I successfully built and ran your code after replacing your call to ::CreateFileA with a valid temp file on my computer.

Want to attach an input file that's causing a crash?

-gw

[Zachm]

I got it to crash fairly easy. The debug info:

Heap block at 00A56F40 modified at 00A56F94 past requested size of 4c
This may be due to a corruption of the heap, and indicates a bug in .exe or any of the DLLs it has loaded.

Stack trace:
msvcr80d.dll!_CrtIsValidHeapPointer(const void * pUserData=0x00a56f68) Line 2072 C++
msvcr80d.dll!_free_dbg_nolock(void * pUserData=0x00a56f68, int nBlockUse=1) Line 1279 + 0x9 bytes C++
msvcr80d.dll!_free_dbg(void * pUserData=0x00a56f68, int nBlockUse=1) Line 1220 + 0xd bytes C++
msvcr80d.dll!operator delete(void * pUserData=0x00a56f68) Line 54 + 0x10 bytes C++
LZJS3::Compressor::FindBestMatch(unsigned long & dwHashIndexRef=4294967295) Line 510 + 0x18 bytes C++
LZJS3::Compressor::EncodeMatch() Line 175 + 0xc bytes C++
LZJS3::Compressor::CompressLoop() Line 125 + 0x8 bytes C++
LZJS3::Compressor::Compress() Line 39 + 0x8 bytes C++
!WinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * __formal=0x00171f04, char * __formal=0x00171f04) Line 47 C++
__tmainCRTStartup() Line 589 + 0x35 bytes C
WinMainCRTStartup() Line 414 C


I havn't the time to figure what's wrong at the moment, but I hope this helps.

Regards,
Zachm

[spartygw]

Okay, I did get it to crash as well by using a larger test input file. My original file was only 1755 bytes. It crashes on another file that is 40KB.

I'll look at it later today and see if I can figure it out.

-gw

[spartygw]

The memory you're allocating at line 388 in Compressor.cpp is not a large enough block.

I didn't spend more than 5 minutes looking at it to figure out what you're trying to do there but pdwIndices is definitely the buffer causing the problem. If I change the line to

unsigned long * pdwIndices = new unsigned long[dwAlloc*2];

And allocate twice the bytes the app runs no problem. I would closely at the previous line:

const unsigned long dwAlloc = m_dwWindowSize / 3;

and make sure dwAlloc is large enough.

Hope this helps.

-gw

[JamesSchumacher]

The memory you're allocating at line 388 in Compressor.cpp is not a large enough block.

I didn't spend more than 5 minutes looking at it to figure out what you're trying to do there but pdwIndices is definitely the buffer causing the problem. If I change the line to

unsigned long * pdwIndices = new unsigned long[dwAlloc*2];

And allocate twice the bytes the app runs no problem. I would closely at the previous line:

const unsigned long dwAlloc = m_dwWindowSize / 3;

and make sure dwAlloc is large enough.

Hope this helps.

-gw

Yeah, I figured that out two weeks ago or so. The reason is because I was not incrementing by 3 every time through like I shouldn't.

Anyways, the code in question here is no longer an 'issue'. I have a different code base on compression now. I am actually working on a setup in which I am defining 'single symbols' to be adjustable. Meaning they can be anywhere from 1 bit to 32 bits.

12 bits is harder to match than 8 bits, however... More data is taken from the input, less comparisons (50% less) and when we do get a match, better compression by 50%.

This is in theory.

[spartygw]

How about marking the thread [RESOLVED] then so other people don't waste their time trying to help you with something you solved weeks ago?

-gw

[JamesSchumacher]

The listed *.zip file has NOTHING to do with my current algorithm.

BTW... Here is what I mean.

How's this for ratio and speed? (http://otpufw.bay.livefilestore.com/y1pbWpzl1P0buIJNqL1sPaxDP6xHTQ3UxNoOFd23xgo72rSYBdBzoycJLczu_KbCwSRtt_5oSKItGOr_c-FTlFP-A/HowThisForSpeed.gif)