[Lame-dev] [ lame-Bugs-1873074 ] Lame_enc.dll 3,97 crash

[SourceForge.net <no...@so...>]

Bugs item #1873074, was opened at 2008-01-16 20:28
Message generated for change (Comment added) made by setosha
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100290&aid=1873074&group_id=290

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Anton Sergunov (setosha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lame_enc.dll 3,97 crash

Initial Comment:
Hello. I got some crash logs from users. Lame fails in the same place

bitstream.c Line: 122 
bs->buf[bs->buf_byte_idx] = 0; 
There 0xC0000005: Access violation writing location

bs->buf_byte_idx crash values are 0x4a70, 0x6188, 0x4a50

Call stcack:
bitstream.c Line: 211 
bitstream.c Line: 831 

Seems like it happens when user convert very big file (~20 hrs) such an audio book. CBR 192kbps.

----------------------------------------------------------------------

>Comment By: Anton Sergunov (setosha)
Date: 2008-01-20 06:46

Message:
Logged In: YES 
user_id=1983192
Originator: YES

beEncodeChunk always get the same dwSamples argument. It's never changes.
The last sample appended by zeros to be the same lenght. 

----------------------------------------------------------------------

Comment By: Anton Sergunov (setosha)
Date: 2008-01-17 16:52

Message:
Logged In: YES 
user_id=1983192
Originator: YES

Correct code:

res=beInitStream(&be_cfg,&dwSamples,&dwBufferSize,&hBeStream);
pRemaindBuffer = new __int16[dwSamples];
pOutputBuffer = new BYTE[dwBufferSize];

while(eof) {
 [full filling pRemaindBuffer with audio data]

 res = beEncodeChunk(hBeStream, dwSamples, pRemaindBuffer, pOutputBuffer,
&dwOutput);
 WriteFile(m_hFile, pOutputBuffer, dwOutput, &dwWrited, NULL);
}
res = beDeinitStream(hBeStream, pOutputBuffer, &dwOutput);
WriteFile(m_hFile, pOutputBuffer, dwOutput, &dwWrited, NULL);


----------------------------------------------------------------------

Comment By: Anton Sergunov (setosha)
Date: 2008-01-17 16:49

Message:
Logged In: YES 
user_id=1983192
Originator: YES

No I just write output buffer to file.

I test it in Vista and XP. It not crashes. But I has ~20 .dmp files,
whith
crash in the same place.

Converting goes well, but failing at 100% progress.

Seems it's just lame buffer overrun bug.

My code:
res=beInitStream(&be_cfg,&dwSamples,&dwBufferSize,&hBeStream);
pRemaindBuffer = new __int16[dwSamples];
pOutputBuffer = new BYTE[dwBufferSize];

while(eof) {
 [full filling pRemaindBuffer with audio data]

 res = beEncodeChunk(hBeStream, dwSamples, pRemaindBuffer, pOutputBuffer,
&dwOutput);
 WriteFile(m_hFile, pOutputBuffer, dwOutput, &dwWrited, NULL);
}

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-01-17 16:37

Message:
Logged In: NO 

No I just write output buffer to file.

I test it in Vista and XP. It not crashes. But I has ~20 .dmp files, whith
crash in the same place.

Converting goes well, but failing at 100% progress.

Seems it's just lame buffer overrun bug.

----------------------------------------------------------------------

Comment By: Robert Hegemann (robert)
Date: 2008-01-17 16:02

Message:
Logged In: YES 
user_id=1106
Originator: NO

Does your application allow to write files larger than 2GB? Are you
buffering the mp3 in RAM?

Once I experimented with Direct Show video capturing, I figured out that
the largest chunk of data I could hold in memory was circa 1.6 GB (my
Windows XP system had 2 GB RAM installed).

20 hours at 192 kbps, now how many bytes do we use:

20 * 60 * 60   = 72000 seconds
192 * 1000 / 8 = 24000 bytes per second
72000 * 24000  = 1728000000 bytes == 1.609 GB

Just for the records: the lame program, compiled without large file
support, does get into trouble when it reaches the 2GB file size limit,
after encoding 24 hours 51 minutes 18 seconds and 485 milliseconds, at 192
kbps. But there seems to be no problem when writing into /dev/null, so the
LAME encoding core should be doing well with data for several days. 


Ciao Robert

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100290&aid=1873074&group_id=290