Win 32bit port broken - crash on import

[masc4ii]

Since Caching is merged, the 32bit Windows version is not able to open MLV files and crashes. It happens since the very first commits with the new caching.

[ilia3101]

Thanks for letting me know. Is there any chance that we are exceeding the 4GB ram limit on 32bit?
EDIT: probably not/very unlikely

[ilia3101]

Also, I think with only 4GB ram, caching might not even be worth it(?), as it wouldn't cover many frames with most video resolutions, also luckily not many people running 32-bit machines anymore. Maybe this is a lazy solution, but what do you think of something like:

#if defined(_WIN32) && !defined(_WIN64)
    #define NO_CACHING
#endif

Do you disagree?

[masc4ii]

Qt is by standard 32bit on Windows. A 64bit version of the environment you must build yourself. As I know we had no 4GB limit on Windows anymore. So when we (or anybody) want to use the standard delivered libraries, we have 32bit libs on a 64bit system. Is it the cache size which causes the problem?

setMlvRawCacheLimitMegaBytes( m_pMlvObject, 100 ); makes no difference. No matter which file size, the App crashes.

[ilia3101]

Qt is by standard 32bit on Windows. A 64bit version of the environment you must build yourself.
That's not great :(

Is it the cache size which causes the problem?
Maybe. Were you testing the 32bit build on a 64bit machine with more than 8GB of RAM?
If so, the problem is probably easy to solve with some limit from Qt part of app (setMlvRawCacheLimit..).
Otherwise, we'll have to look at crash reports and try to see what goes wrong, and I'll probably have to set up a win32 vm.

[masc4ii]

The PC has exactly 8GB RAM. setMlvRawCacheLimitMegaBytes( m_pMlvObject, 100 ); makes no difference. No matter which file size, the App crashes. The 64bit version from bouncyball works good without crash!
Edit: crash report says MLVAPP.exe was crashing. Really?!
Edit2: last revision before the caching merge is working fine... so there must be the issue anywhere... (I know, a lot changed there)

[bouncyball-git]

[win 32bit crash on mlv import] Debugger always bails out on the line 208 of 'frame_caching.c'
[linux 64bit crashes often] the reason is line 264 of the 'frame_caching.c': fclose(file);

if(file) fclose(file); <- this patch works and no crashes are encountered after it. strange because 'file' only lives in this local scope, however there are more threads working with the same opened file. Something's wrong here. Linux always very sensitive about this king of stuff.

[masc4ii]

Thx bouncyball. On Win 32bit I can't debug, because I have no zlibd.dll... or how can you debug?

[ilia3101]

always bails out on the line 208 of 'frame_caching.c'
makes no sense :(
[linux 64bit crashes often] the reason is line 264 of the 'frame_caching.c': fclose(file);
That must mean the file is failing to open in the first place :/ So cache is not even working there sometimes :(

[bouncyball-git]

Yup, right, makes no sense at all :)

Debugging is difficult without some lib debug versions. But "run to line" feature sometimes helps a lot.

[bouncyball-git]

I patched the code now it works. But I think we are walking on the sharp blade with all those caching threads running in the background and hogging almost 100% of all cores!

Example: when I import several MLVs and activating cache, then starting to change videos quickly (clicking on them randomly) after some clicks app crashes and debugger always bails out on 77th line of AudioPlayback.cpp. Look at this line yourself. Some simultaneous access to some resources!

Well... I don't like this any more :) and why this thread code (function) works if caching is off by default when app been crashing on windows 32bit?

Edit: is multithreaded caching design the same in cocoa app?

[masc4ii]

On OSX it does not crash when I click randomly on the session clips also with Caching active. AudioPlayback again? Oh no... why has Linux so big problems with audio?
delete m_pAudioOutput; ??? Oh man... if that does not work, what shall we do then?

[bouncyball-git]

Unfortunately it still crashes when audio playback is off in the menu. ON THE SAME LINE ;)

[bouncyball-git]

When file is big enough caching drives me crazy. Whole PC stalls and unresponsive some annoying time. System monitor shows almost 100% load on all 4 cores 4 threads :)

I don't really think that cache should be THAT big. It should be just big enough to have positive impact on performance.

[masc4ii]

Audioplayback is off and you get a crash in AudioPlayback? Very interesting! :-/

[bouncyball-git]

Yup, s..t happens :)