Hi,
* A Mennucc <[EMAIL PROTECTED]> [2008-07-20 15:58]:
> when playing
> lol-mplayer.wmv
> mplayer hangs forever (or, at least, more than I wish to wait)
> 
> it happens with both Debian and SVN version

I am rechecking these issues atm.
1.0~rc2-18 does crash on amd64 here, the reason is a null 
ptr dererence in libfaad2 line 221:
#0  ifilter_bank (fb=<value optimized out>, window_sequence=<value optimized 
out>, window_shape=<value optimized out>, window_shape_prev=<value optimized 
out>, freq_in=0x7fff1d48f5f0, time_out=0x0, overlap=0x0, object_type=0x2, 
frame_len=<value optimized out>) at filtbank.c:221
#1  0x0000000000640278 in reconstruct_single_channel (hDecoder=0x1290a20, 
ics=0x7fff1d490646, sce=0x7fff1d490640, spec_data=0x7fff1d4957f0) at 
specrec.c:928
#2  0x000000000062e23d in single_lfe_channel_element (hDecoder=0x1290a20, 
ld=0x7fff1d4960d0, channel=0x2, tag=0x7fff1d496047 "\n\003") at syntax.c:596
#3  0x000000000062e35a in decode_sce_lfe (hDecoder=0x4, hInfo=0xa92280, ld=0x0, 
id_syn_ele=<value optimized out>) at syntax.c:345

filtbank.c:
219         for (i = 0; i < nlong; i+=4)
220         {
221             time_out[i]   = overlap[i]   + 
MUL_F(transf_buf[i],window_long_prev[i]);
222             time_out[i+1] = overlap[i+1] + 
MUL_F(transf_buf[i+1],window_long_prev[i+1]);
223             time_out[i+2] = overlap[i+2] + 
MUL_F(transf_buf[i+2],window_long_prev[i+2]);
224             time_out[i+3] = overlap[i+3] + 
MUL_F(transf_buf[i+3],window_long_prev[i+3]);
225         }

The function is called from libfaad2/specrec.c reconstruct_single_channel:
 928         ifilter_bank(hDecoder->fb, ics->window_sequence, ics->window_shape,
 929             hDecoder->window_shape_prev[sce->channel], spec_coef,
 930             hDecoder->time_out[sce->channel], 
hDecoder->fb_intermed[sce->channel],
 931             hDecoder->object_type, hDecoder->frameLength);

sce->channel is is not NULL at the beginning of the function.
sce->channel is 2 while the lenght of fb_intermed is only 2 and [2] is NULL.
The value gets lost between decode_sce_lfe() and single_lfe_channel_element().

fb_intermed gets allocated in specrec.c line 788 and following:
gdb> break specrec.c :794
Breakpoint 4 at 0x63fc20: file specrec.c, line 794.
gdb> continue
_______________________________________________________________________________
Error while running hook_stop:
Value can't be converted to integer.
Breakpoint 4, reconstruct_channel_pair (hDecoder=0x211aa20, 
ics1=0x7fff93dd7796, ics2=0x7fff93dda068, cpe=0x7fff93dd7790, 
spec_data1=0x7fff93ddd140, spec_data2=0x7fff93ddc940) at specrec.c:795
795     in specrec.c
gdb> print hDecoder->frameLength
$6 = 0x400
gdb> print hDecoder->fb_intermed[0]
$7 = (real_t *) 0x219f300
gdb> print hDecoder->fb_intermed[2]
$8 = (real_t *) 0x0

 788     if (hDecoder->fb_intermed[channel] == NULL)
 789     {
 790         hDecoder->fb_intermed[channel] = 
(real_t*)faad_malloc(hDecoder->frameLength*sizeof(real_t));
 791         memset(hDecoder->fb_intermed[channel], 0, 
hDecoder->frameLength*sizeof(real_t));
 792     }

If I made no mistake before and after hDecoder->fb_intermed[channel] is NULL.
gdb> print hDecoder->frameLength 
$11 = 0x400
gdb> print sizeof(real_t)
$12 = 0x4
So it tries to allocate 4096 bytes.

Andreas, I fail to see why this should result in NULL. Any idea?

At the time of the crash it definitely only crashes because of a null ptr 
derefence which
is no security issue in this case. But as it writes data to the location before 
dereferencing
this could be more problematic.

Kind regards
Nico


-- 
Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.

Attachment: pgpWMfEaDe1Hh.pgp
Description: PGP signature

Reply via email to