Bug 603496

s/suspected to/suspected two/

Filed upstream as https://bugzilla.gnome.org/show_bug.cgi?id=621566

Thanks!

Could someone try if it's still a problem in rawhide when using the 0.10.23.2 prerelease?
(If noone is on rawhide, you could also try copying its libgstpulse.so - though I haven't tested if that works)

Initial tests using gstreamer-plugins-good-0.10.23.2 are promising, I'll do something more rigorous here in a bit.

alright, 0.10.23.2 looks like a winner here, I cannot make it misbehave at all.

confirmed fix coming in gst-plugins-good , reassigning there.

*** Bug 609225 has been marked as a duplicate of this bug. ***

I mocked a copy of 0.10.23.4-1 for fc13 (along with the gstreamer & gstreamer-plugins-base), and it fixed this right up for me on both desktops which had this problem.  Will we be seeing this in fc13 updates-testing anytime soon?

looks like 0.10.30 is on the way.

gstreamer-0.10.30-1.fc13,gstreamer-plugins-base-0.10.30-1.fc13,gstreamer-plugins-good-0.10.24-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/gstreamer-0.10.30-1.fc13,gstreamer-plugins-base-0.10.30-1.fc13,gstreamer-plugins-good-0.10.24-1.fc13

gstreamer-0.10.30-1.fc13, gstreamer-plugins-base-0.10.30-1.fc13, gstreamer-plugins-good-0.10.24-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Looks like gstreamer 0.10.30 + orc is actually worse than the earlier version. Now, rather than produce jittery playback after I play two tracks successfully, I get a seg fault in liborc after successfully playing one track. gstreamer's use of orc is new for 0.10.30.

(gdb) run --sync --nocrashhandler --nofork
Starting program: /usr/bin/juk --sync --nocrashhandler --nofork
[Thread debugging using libthread_db enabled]
[New Thread 0xb27f2b70 (LWP 13796)]
[Thread 0xb27f2b70 (LWP 13796) exited]
[New Thread 0xb27f2b70 (LWP 13797)]
[Thread 0xb27f2b70 (LWP 13797) exited]
[New Thread 0xb27f2b70 (LWP 13798)]
[New Thread 0xadbfeb70 (LWP 13799)]
[Thread 0xadbfeb70 (LWP 13799) exited]
[New Thread 0xadbfeb70 (LWP 13800)]
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
[New Thread 0xa8ffeb70 (LWP 13802)]
[New Thread 0xa83ffb70 (LWP 13803)]
[New Thread 0xa77ffb70 (LWP 13804)]
[New Thread 0xa6bffb70 (LWP 13805)]
[Thread 0xb27f2b70 (LWP 13798) exited]
[New Thread 0xb27f2b70 (LWP 13806)]
[New Thread 0xa5cffb70 (LWP 13807)]
[Thread 0xa5cffb70 (LWP 13807) exited]
[New Thread 0xa5cffb70 (LWP 13852)]
[New Thread 0xa52feb70 (LWP 13853)]
[New Thread 0xa48fdb70 (LWP 13854)]
[New Thread 0xa3efcb70 (LWP 13855)]
[Thread 0xadbfeb70 (LWP 13800) exited]
[New Thread 0xadbfeb70 (LWP 13856)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa77ffb70 (LWP 13804)]
0x010e5967 in orc_x86_emit_push (compiler=0xa6c09380, size=4, reg=37)
    at orcx86.c:120
120         *compiler->codeptr++ = 0x50 + orc_x86_get_regnum(reg);
(gdb) bt
#0  0x010e5967 in orc_x86_emit_push (compiler=0xa6c09380, size=4, reg=37)
    at orcx86.c:120
#1  0x010e5c40 in orc_x86_emit_prologue (compiler=0xa6c09380) at orcx86.c:866
#2  0x010e21ba in orc_compiler_sse_assemble (compiler=0xa6c09380)
    at orcprogram-sse.c:566
#3  0x010cfbdc in orc_program_compile_full (program=0xa6c072b8, target=
    0x1127660, flags=1) at orccompiler.c:215
#4  0x010cfcc1 in orc_program_compile_for_target (program=0xa6c072b8, target=
    0x1127660) at orccompiler.c:127
#5  0x010cfcf7 in orc_program_compile (program=0xa6c072b8) at orccompiler.c:108
#6  0x0112c00b in orc_process_int16 (d1=0xa84e1318, p1=7535, n=2304)
    at tmp-orc.c:135
#7  0x0112a984 in volume_process_int16 (self=0x84e6278 [GstVolume], bytes=
    0xa84e1318, n_bytes=4608) at gstvolume.c:729
#8  0x0112ae36 in volume_transform_ip (base=0x84e6278 [GstVolume], outbuf=
    0xa84c55e0 [GstBuffer]) at gstvolume.c:1015
#9  0x070f1237 in gst_base_transform_handle_buffer (
    trans=<value optimized out>, inbuf=0xa84c55e0 [GstBuffer], outbuf=
    0xa77fee0c) at gstbasetransform.c:2050
#10 0x070f19c8 in gst_base_transform_chain (pad=0x84f9cb8 [GstPad], buffer=
    0xa84c55e0 [GstBuffer]) at gstbasetransform.c:2169
#11 0x0703997d in gst_pad_chain_data_unchecked (pad=0x84f9cb8 [GstPad], 
    is_buffer=1, data=0xa84c55e0) at gstpad.c:4176
#12 0x0703a397 in gst_pad_push_data (pad=0x84e09a0 [GstPad], is_buffer=1, data=
    0xa84c55e0) at gstpad.c:4405
#13 0x070f1a1f in gst_base_transform_chain (pad=0x84e08d8 [GstPad], buffer=
    0xa84c55e0 [GstBuffer]) at gstbasetransform.c:2190
#14 0x0703997d in gst_pad_chain_data_unchecked (pad=0x84e08d8 [GstPad], 
    is_buffer=1, data=0xa84c55e0) at gstpad.c:4176
#15 0x0703a397 in gst_pad_push_data (pad=0x84e0810 [GstPad], is_buffer=1, data=
    0xa84c55e0) at gstpad.c:4405
#16 0x01170935 in gst_queue_push_one (pad=0x84e0810 [GstPad])
    at gstqueue.c:1083
#17 gst_queue_loop (pad=0x84e0810 [GstPad]) at gstqueue.c:1185
#18 0x070670b1 in gst_task_func (task=0x86c3148 [GstTask]) at gsttask.c:271
#19 0x07068718 in default_func (tdata=0x868ab38, pool=0x843f008 [GstTaskPool])
    at gsttaskpool.c:68
#20 0x00438214 in g_thread_pool_thread_proxy (data=0x843c7b0)
    at gthreadpool.c:315
#21 0x00436210 in g_thread_create_proxy (data=0xa84046d8) at gthread.c:1893
#22 0x00334919 in start_thread () from /lib/libpthread.so.0
#23 0x00276cbe in clone () from /lib/libc.so.6
(gdb) list
115         ORC_ASM_CODE(compiler,"  pushw %%%s\n", orc_x86_get_regname_16(reg));
116         *compiler->codeptr++ = 0x66;
117         *compiler->codeptr++ = 0x50 + orc_x86_get_regnum(reg);
118       } else {
119         ORC_ASM_CODE(compiler,"  pushl %%%s\n", orc_x86_get_regname(reg));
120         *compiler->codeptr++ = 0x50 + orc_x86_get_regnum(reg);
121       }
122     }
123
124     void
(gdb) print compiler
$3 = (OrcCompiler *) 0xa6c09380
(gdb) print *compiler->codeptr
Cannot access memory at address 0x0
(gdb)

Sounds like a separate issue, which deserves opening a new bug (though I've not experienced it myself yet, listening to amarok playlists a bunch since the update).

Looks like yet another JIT causing yet another memory protection issue (see also our eternal struggle with the WebKit JavaScript JIT), this time it's ORC which replaces the previously used canned optimized inner loops from liboil.

This problem (orc + gstreamer 10.30) is either gstreamer generating bad oil code that orc is choking on, or orc is choking on valid oil code generated by gstreamer. It's 100% reproducible. Any suggestions as to what category I should use to submit a bug for this problem? Thanks.