Emulator

Does this only happen in GC games?

Uh possible problem line:

h = _mm_crc32_u64(h, data[0]);

Which is inside a ifdef block:
#if _M_SSE >= 0x402

Your Dolphin is compiled for SSE > 4.02 ?

Where did you get your compiled copy from?

#elif _MSC_VER >= 1500 // Visual Studio 2008
#define _M_SSE 0x402
#endif

Why is SSE4 assumed just because you have visual studio 2008? :|

i think all sse* functions are compiled and at runtime the function pointer(s) are set to the highest sse based on the detected cpuinfo.
Maybe it is not done everywhere

parlane, my git-543 SSE4,2 a few branches included, i compiled it myself with VS 2010 and ICC, but i compiling with ICC about for two months, but crashes started even before, a had the same with normal builds

What exact CPU type and model do you have? The code checks if the CPU has SSE4.2 before using the CRC32 hash.

Also, does you build have this change included? rb8bef29bcc5a

On second thoughts, the dump looks like a general memory leak and probably has nothing to do with the hash function or the gc pad.

My cpu Core i5 2500K, yes i have rb8bef29bcc5a on board, but it's updated to rc3293b1a1 by NeoBrain, does it makes any difference?

I'm beginning to doubt, is it my ICC builds or smth else, i try to compile Common part without SSE4,2 and test

I've done my tests, this issue is pretty random, but i tested on two games which are always were most crashable with this, MP3 about 10-15 to crash and SMG about *the same time, i compiled my build with SSE4,2 turned off for Common project, and i think parlane was right, i played for two hours in MP3 than shuted down the game not emu and after played in SMG for an hour and still playing yet no crashes

skidau if that is correct, then that just leaves:

h = _mm_crc32_u64(h, data[0]);

h or data to be invalid at this point?

Commenting out "h = _mm_crc32_u64(h, data[0]);" is equivalent to Accurate Texture Cache = off.

Instead, try turning off SSE4.2 support on line 516:

else if (cpu_info.bSSE4_2 && !useHiresTextures) // sse crc32 version

"Instead, try turning off SSE4.2 support on line 516:

else if (cpu_info.bSSE4_2 && !useHiresTextures) // sse crc32 version"
skidau, i could test it, but how should i do it?

Autoran, delete these lines in Hash.cpp:

#if _M_SSE >= 0x402
else if (cpu_info.bSSE4_2 && !useHiresTextures) // sse crc32 version
{
ptrHashFunction = &GetCRC32;
}
#endif

Commenting out "h = _mm_crc32_u64(h, data[0]);" is equivalent to Accurate Texture Cache = off.

I never suggested that :(

Will test today's later

Commented out those line, seem's to be pretty stable so far
but i've encountered some other exceptions

Unhandled Exception
Code: 0xC0000005
Call stack info:
ntdll!0x770632D0 : RtlFreeHeap
ISOProperties.cpp(275) : CISOProperties::CreateDirectoryTree
dockart.cpp(301) : wxAuiDefaultDockArt::wxAuiDefaultDockArt

Unhandled Exception
Code: 0xC0000005
Call stack info:
ntdll!0x770632D0 : RtlFreeHeap

Unhandled Exception
Code: 0xC0000005
Call stack info:
FrameAui.cpp(810) : CFrame::ReloadPanes

Unhandled Exception
Code: 0xC0000005
Call stack info:
FrameAui.cpp(810) : CFrame::ReloadPanes

These look's nothing like hash, happend on build with non-SSE Common

And btw, what means these messages with no .cpp problem file
Unhandled Exception
Code: 0xC0000005
Call stack info:
ntdll!0x770632D0 : RtlFreeHeap

Call stack info:
0xFD79CACD : ?
0x2619C500 : ?
ntdll!0x77019D8D : RtlDecodePointer

Autoran, try applying the patch in Issue 4588, Comment 31 here:

http://code.google.com/p/dolphin-emu/issues/detail?id=4588#c31

I've applied but this issue was pretty rear i don't know will it happen again or not

Last two days i've got only two of
Unhandled Exception
Code: 0xC0000005
Call stack info:
ntdll!0x770632D0 : RtlFreeHeap
not FrameAui, or smth concrete