#67 2017-beta1 crashing always after converting some files

[Dietmar Hoppe-Jagonak]

Strange experience with winLAME: On my PC I got it crashing always somewhere down the line, eventually. Regardless of which GUI I choose, selecting single files or some dozen, whatever conversion I've been setting (flac -> mp3, wav -> aac, ...), encoding started fine, finished files are error free, but at some point after starting it surely crashes and creates a minidump file per thread. Some minidumps had a length of zero, but all the rest shows the very same error:

Ausnahmecode:   0xC0000005
Ausnahmeinformationen:  Der Thread hat versucht, von einer virtuellen Adresse, für die er nicht über die entsprechenden Zugriffsrechte verfügt, zu lesen oder in diese Adresse zu schreiben.

Looks to me like some kind of timing issue. I'm running Windows-7 [64bit] on an AMD A8-6600K.

[Michael Fink]

Hi Dietmar,
I looked at the crash dump, and it seems that the crash comes from decoding an audio file with the LibSndFile library that doesn't have 16 bit or 32 bit sample width. Could you locate the file and attach it or send it to me, so I can try to implement decoding wave files with different sample bit widths?
In the meantime you can use the following winLAME build from Appveyor, where I put a workaround in: audio files with sample width other than 16 bit or 32 bit now give an error while decoding in winLAME. Link to build 2.17.1.14 and the compiled winLAME.exe:
https://ci.appveyor.com/project/vividos/code/build/artifacts
Thanks!
Michael

[Dietmar Hoppe-Jagonak]

Hi Michael,
sorry for my delayed reply, but I've been very busy these days... :-)
But today I've got time to do some more exhautive testings.

Firstly, for a simple reason I don't believe there's to blame a defective audio file. If indeed I had a file with a somehow weird sample width I'd expect this file to always fail format conversion. But when I did select any failed file afterwards as the only one to be processed, it ran through flawlessly.

Now to your "appveyor version". It's still crashing (at some point). But behaviour ist different than before. When crashing, one (or more) dialog windows titled "Crash Dump - Speichere Ergebnisse" do pop up. But now WinLAME somtimes doesn't stop working until I hit one of the "close"-Buttons from this dialogs. Or, if I just wait on, WinLAME succeeds its processing and even the last resulted file is correct. And I happen to find 2 or 3 "temp"-files left in my output folder regarding the same (and last) processed audio file.

Now I experimented with different numbers of selected audio files. And I observed that WinLAME is utilizing up to as many "worker" threads (meaning in parallel processed audio files) as there are cpu cores on the machine. I verified this with my Intel Xeon based workstation (where WinLAME utilized up to 12 "worker" threads) and a VirtualBox-VM. And I can say that on all machines I've been testing on, no crashing occured as long as the number of selected files wasn't higher than the number of processing threads WinLAME was willing to utilize. But as soon as one processing thread at least has "to wrap around" (be reused, restarted, or whatever WinLAME does internally)) desaster strikes and crash dumps do occur.

I hope this somewhat lengthy explanation of mine wasn't more confusing than illuminative...
But to me it looks like audio processing in itself here isn't the source of the problem. Let me know how I can be of further assistance if needed.

Dietmar

[Michael Fink]

Hi Dietmar,
thanks for your research. You reported that you got the dialog "Crash Dump - Speichere Ergebnisse". Could you provide me with the actual crash dump file that was created? This would be helpful.

In the meantime I fixed some potential bugs, so maybe you could test using the latest appveyor build of winLAME:
https://ci.appveyor.com/project/vividos/code/build/artifacts (should be build 2.17.1.21).
Thank you!

Regards,
Michael

[Michael Fink]

Hi Dietmar,
I found the bug in winLAME leading to the crash. Please retest with the newly released winLAME 2017 beta 2 version. Thanks!
Regards,
Michael

[Dietmar Hoppe-Jagonak]

Hi Michael,
just to let you know: it's working now as intended! Thank you for your work and commitment.
There's still an immediate crash when using FLAC encoded files. But it's the new release 1.0.28 of libsndfile who ist to blame. I tried the older release 1.0.27 and everything was fine :-)

Regards,
Dietmar

[Michael Fink]

Hi Dietmar,
thanks for letting me know! For the FLAC issue: It seems the libsndfile developers are already working on it, see: https://github.com/erikd/libsndfile/issues/254
I reverted back to libsndfile 1.0.27 and will check for new version of libsndfile before releasing the next beta version.
Regards,
Michael