1.17.02.54 Crash after export to MP3 using lame_enc

[dathmod]

Full Version:
OpenMPT v1.17.02.52-54 (older unsure)

Has the bug occured in previous versions? If yes, please specify version(s):
52,53,54 (This will happen from 52)


Description of the bug:
When I export a song using the Export to MP3 funcion it does the job and creates correctly the file. The crash occurs if you press playback button an so other things.

How often does it happen?:
Happens all the time

How to reproduce (step by step description):
Open or create a song. Export to MP3 using any lame encoder config (bitrate, samplerate...). Then press the play button or change between tabs. Crash will appear.

PD: I dont know if is a problem with OpenMPT, but i use this function to preview my songs instead a WAV (small hard disk) Anyway, a suggestion or something to prevent the breakdown would be welcome. Thanks.

[dathmod]

Two images of the crash, (I have istalled VS2008 to compile the latest code of OpenMPT 5 week ago but at this time I cant do this )
In the second screenshot appears the VS debug window. May be useful.

http://yfrog.com/5j85373225jx

[Saga Musix]

Just to be sure, does this mean that it didn't happen with .51 and older versions?

[dathmod]

I tried with versions 1.17.02.48-54 and these has the bug. The only variation of the bug appearing is only the number of plays, about 2-4 times, but when you change the tab of the program will hang. I am testing with older versions.

EDIT: Versions from .47-54 are more faster than .46 this means by program speed and "creation" of the bug (for .46, play and stop OpenMPT while changing tabs, about 16 times is required)

[Saga Musix]

It's very strange that I don't get this bug in debug mode, but it definitely appeared using a "normal" MPT build. Hm...

Another interesting thing is that the "latest additions" section in MPT 1.16's file_id.diz says:

- Fixed MP3 bug when exporting multiple times

strange!

[Slor]

Has this been circled around to at all since the previous posts?  I happened to run into the issue myself today in both 1.17.02.54 and 1.16.0194 (running in 64-bit Win7), and I found this thread while looking for a solution.

I grabbed the latest development source from SVN and have at least been able to trap the error in the debugger, so I can dig a bit deeper and see what I can find if nobody else is working on it.  If someone is, then I'll leave well enough alone for now.

Thanks
James

[Saga Musix]

I have not really looked into this since then. If you want to do some deeper investigation, by all means, do it!

[Slor]

Will do then.  Looks like a nice little heap corruption from what I've seen so far.

[jmkz]

It's very strange that I don't get this bug in debug mode, but it definitely appeared using a "normal" MPT build. Hm...

Another interesting thing is that the "latest additions" section in MPT 1.16's file_id.diz says:

- Fixed MP3 bug when exporting multiple times

strange!

Jojo, can you give me a build of OpenMPT in debug mode? I like to find more about this...

[Saga Musix]

How would that help? As said, I was not able to reproduce the bug with a debug build. That aside, I think the debug builds made with VS2008 on Win7 are not compatible with Windows XP (or you probably need VS2008 installed).

[Saga Musix]

How to not fix heap corruptions (but how to find them):

Code: [Select]

dstBuffer = (LPBYTE)GlobalAllocPtr(GHND, dwDstBufSize + 16384);
I have finally found the cause for this problem (since it also crashes in debug mode now, maybe because I'm using a different OS) and the next version of OpenMPT should no longer crash when exporting to MP3.

[jmkz]

Nice Jojo!   I have tested many times the test build and it really gone!
 
PS: cytrek have his own post on bug tracker: http://bugs.openmpt.org/view.php?id=97

[Saga Musix]

I noticed that the current fix might not work with ACM codecs (I wonder if anyone is still using them...) - to be corrected in the next update.

[Saga Musix]

I'm going to move this to the archive since the original reporter hasn't shown up in a long time and the fix has been confirmed by two other people.