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.
pgpWMfEaDe1Hh.pgp
Description: PGP signature