it got a little chaotic in the validated news/release thread, please allow me to summarize here:
---
Version from rarewarez (jan 11. 11:11) crashed while encoding a file with --alt-preset fast standard
Unhandled exception at 0x0041e40b in lame.exe: 0xC0000005: Access violation reading location 0x4e525315.
too bad I dont have the debug symbols.. disassembly then
0041E3FC mov edx,dword ptr [esp+10h]
0041E400 mov edi,dword ptr [esp+14h]
0041E404 mov ecx,dword ptr [edx+edi*8+459A2Ch]
--> 0041E40B mov cl,byte ptr [eax+ecx]
0041E40E shl ecx,18h
0041E411 sar ecx,18h
0041E414 add ebp,ecx
WinXP blabla very stable, Celeron 1.7 nothing Overclocked
---
--preset fast medium crashes also, but a few 100 frames later then apfs. both 100% reproduceable here
00430287 fst dword ptr [edx+0Ch]
0043028A mov ecx,dword ptr [edx]
-->0043028C fld qword ptr [ecx*8-57B4B120h]
00430293 faddp st(3),st
00430295 fxch st(2)
in the line where it crashed (arrow), ecx is a value over 1.2 billion, type unsigned long.
multiplied with *8 -> overflow error maybe, I'm not very apt in assembler
in the apfs case, it looks very similar. In the fast preset code (vbr-new still?) there might be an opertion with an ulong *8.. but I'm to lazy to check out the code now
normal presets (no fast) all work fine
---
Mitiok compile (ICL 4.5) crashes too with my Body Count track and ap fast std, same place.
---
So, now I compiled it myself with MSVC 7.0 (Visual Studio 2002), no NASM
It still crashes in release config on fast preset medium/standard, debug config runs fine.
I was able to get a callstack from the release build eventually:
> lame.exe!_mdct_sub48() + 0x9b6 C
lame.exe!_count_bits() + 0x84 C
lame.exe!_bin_search_StepSize() + 0x4e C
lame.exe!_VBR_noise_shaping() + 0x348 C
lame.exe!_VBR_iteration_loop() + 0x115 C
disassembly for top line (mdct_sub48()):
00421236 fadd qword ptr [ebx*8-57B6E880h]
again a very large number (1.2 billion) multiplied with 8, which might cause an ulong overflow.
thanks for your interest, trying to get some debug symbols to work..