Could you also provide the gst, gstg-plugins, ... versions?

1143> rpm -q -a 'gst*'
gstreamer-devel-0.10.30-1.fc13.i686
gstreamer-tools-0.10.30-1.fc13.i686
gstreamer-plugins-good-0.10.25-1.fc13.i686
gstreamer-plugins-base-0.10.30-1.fc13.i686
gstreamer-python-0.10.16-1.fc12.i686
gstreamer-rtsp-0.10.5-1.fc13.i686
gstreamer-0.10.30-1.fc13.i686
gstreamer-plugins-bad-free-0.10.20-1.fc13.i686
1144> rpm -q -a 'fluendo*'
fluendo-codecs-windowsmedia-bundle-10-2.i386
1145>

Does 
gst-launch audiotestsrc ! volume volume=0.5 ! autoaudiosink
work for you?

No, it crashes exactly the same way juk does:

(gdb) run audiotestsrc ! volume volume=0.5 ! autoaudiosink
Starting program: /usr/bin/gst-launch audiotestsrc ! volume volume=0.5 ! autoaudiosink
[Thread debugging using libthread_db enabled]
process 3060 is executing new program: /usr/bin/gst-launch-0.10
[Thread debugging using libthread_db enabled]
Setting pipeline to PAUSED ...                                                  
[New Thread 0xb7cc3b70 (LWP 3063)]                                              
[New Thread 0xb30feb70 (LWP 3064)]                                              
Pipeline is PREROLLING ...                                                      
                                                                                
Program received signal SIGSEGV, Segmentation fault.                            
[Switching to Thread 0xb30feb70 (LWP 3064)]                                     
0x0017a367 in orc_x86_emit_push () from /usr/lib/liborc-0.4.so.0                
Missing separate debuginfos, use: debuginfo-install gstreamer-0.10.30-1.fc13.i686                                                                               
(gdb) bt                                                                        
#0  0x0017a367 in orc_x86_emit_push () from /usr/lib/liborc-0.4.so.0            
#1  0x0017a510 in orc_x86_emit_prologue () from /usr/lib/liborc-0.4.so.0        
#2  0x001764ea in orc_compiler_sse_assemble () from /usr/lib/liborc-0.4.so.0    
#3  0x00163354 in orc_program_compile_full () from /usr/lib/liborc-0.4.so.0     
#4  0x00163437 in orc_program_compile_for_target ()                             
   from /usr/lib/liborc-0.4.so.0                                                
#5  0x00163477 in orc_program_compile () from /usr/lib/liborc-0.4.so.0          
#6  0x0015600b in ?? () from /usr/lib/gstreamer-0.10/libgstvolume.so            
#7  0x00154984 in ?? () from /usr/lib/gstreamer-0.10/libgstvolume.so            
#8  0x00154e36 in ?? () from /usr/lib/gstreamer-0.10/libgstvolume.so
#9  0x04ea2237 in ?? () from /usr/lib/libgstbase-0.10.so.0
#10 0x04ea29c8 in ?? () from /usr/lib/libgstbase-0.10.so.0
#11 0x04dea97d in ?? () from /usr/lib/libgstreamer-0.10.so.0
#12 0x04deb397 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#13 0x04e9b8a2 in ?? () from /usr/lib/libgstbase-0.10.so.0
#14 0x04e180b1 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#15 0x04e19718 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#16 0x006dd214 in ?? () from /lib/libglib-2.0.so.0
#17 0x006db210 in ?? () from /lib/libglib-2.0.so.0
#18 0x005f3919 in start_thread () from /lib/libpthread.so.0
#19 0x00535cce in clone () from /lib/libc.so.6
(gdb) disassemble 0x0017a367
Dump of assembler code for function orc_x86_emit_push:
...
0x0017a35c <+92>:    call   0x15f3ac <orc_x86_get_regnum@plt>
   0x0017a361 <+97>:    mov    -0x1c(%ebp),%edx
   0x0017a364 <+100>:   add    $0x50,%eax
=> 0x0017a367 <+103>:   mov    %al,(%edx)
   0x0017a369 <+105>:   add    $0x1,%edx
...
(gdb) info registers
eax            0x55     85
ecx            0x0      0
edx            0x0      0
ebx            0x1bc97c 1821052
esp            0xb30fda80       0xb30fda80
ebp            0xb30fdac8       0xb30fdac8
esi            0xb2507ff0       -1303347216
edi            0x25     37
eip            0x17a367 0x17a367 <orc_x86_emit_push+103>
eflags         0x10206  [ PF IF RF ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
(gdb)

Okay, I've got the same packages installed, but this bug is not reproducible by me.
Is there something special about your setup?

No, just vanilla Fedora 13 on a Dell precision workstation 530n. There are others having this same problem. See: 629816, 630372, 630518. I removed the fluendo decoders, and the problem is still there. I started seeing this problem when gst started using liborc.

Okay, thanks. I did not look around for bugs. Now I reassigned them all to orc.

orc-0.4.9-1.fc13 has been pushed to the Fedora 13 testing repository.
Please test the update and try to reproduce your problem after installing the most recent version using
 su -c 'yum --enablerepo=updates-testing update orc'. 

 If your problem still persists, please make note of it in this bug report and
you can provide feedback for this update (so it get's pushed to Fedora 13 stable) here: https://admin.fedoraproject.org/updates/orc-0.4.9-1.fc13

orc-0.4.9-1.fc13 causes gst-launch, etc to crash with an assertion failure:

(gdb) run audiotestsrc ! volume volume=0.5 ! autoaudiosink
Starting program: /usr/bin/gst-launch audiotestsrc ! volume volume=0.5 ! autoaudiosink
[Thread debugging using libthread_db enabled]
process 21119 is executing new program: /usr/bin/gst-launch-0.10
[Thread debugging using libthread_db enabled]
Setting pipeline to PAUSED ...
[New Thread 0xb7cc3b70 (LWP 21122)]
[New Thread 0xb30feb70 (LWP 21123)]
Pipeline is PREROLLING ...
ORC: ERROR: orccodemem.c(235): orc_code_region_allocate_codemem(): failed to create exec map
ORC: ERROR: orccodemem.c(144): orc_code_region_get_free_chunk(): assertion failed: 0

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb30feb70 (LWP 21123)]
0x00110416 in ?? ()
Missing separate debuginfos, use: debuginfo-install gstreamer-0.10.30-1.fc13.i686
(gdb) bt
#0  0x00110416 in ?? ()
#1  0x00482d11 in raise () from /lib/libc.so.6
#2  0x004845ea in abort () from /lib/libc.so.6
#3  0x00165d00 in orc_code_region_get_free_chunk ()
   from /usr/lib/liborc-0.4.so.0
#4  0x00165d32 in orc_code_allocate_codemem () from /usr/lib/liborc-0.4.so.0
#5  0x00169837 in orc_program_compile_full () from /usr/lib/liborc-0.4.so.0
#6  0x00169977 in orc_program_compile_for_target ()
   from /usr/lib/liborc-0.4.so.0
#7  0x001699b7 in orc_program_compile () from /usr/lib/liborc-0.4.so.0
#8  0x0015600b in ?? () from /usr/lib/gstreamer-0.10/libgstvolume.so
#9  0x00154984 in ?? () from /usr/lib/gstreamer-0.10/libgstvolume.so
#10 0x00154e36 in ?? () from /usr/lib/gstreamer-0.10/libgstvolume.so
#11 0x04ea2237 in ?? () from /usr/lib/libgstbase-0.10.so.0
#12 0x04ea29c8 in ?? () from /usr/lib/libgstbase-0.10.so.0
#13 0x04dea97d in ?? () from /usr/lib/libgstreamer-0.10.so.0
#14 0x04deb397 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#15 0x04e9b8a2 in ?? () from /usr/lib/libgstbase-0.10.so.0
#16 0x04e180b1 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#17 0x04e19718 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#18 0x006dd214 in ?? () from /lib/libglib-2.0.so.0
#19 0x006db210 in ?? () from /lib/libglib-2.0.so.0
#20 0x005f3919 in start_thread () from /lib/libpthread.so.0
#21 0x00535cce in clone () from /lib/libc.so.6
(gdb)

Thanks for the feedback. 
Currently there is no new release and I am not able to reproduce this problem.

If you are willing you could try to build orc by hand and see if the problem still exists.

Fabian, I root-caused the problem. On my machine, I use tmpfs for /tmp, and mount it thusly:

tmpfs on /tmp type tmpfs (rw,noexec,nosuid,size=256m,rootcontext="system_u:object_r:tmp_t:s0")

Mounting /tmp noexec causes the following code in orccodemem.c, function
orc_compiler_allocate_codemem to fail:

compiler->program->code_exec = mmap (NULL, SIZE, PROT_READ|PROT_EXEC, MAP_SHARED, fd, 0);
  if (compiler->program->code_exec == MAP_FAILED) {
    ORC_COMPILER_ERROR(compiler, "failed to create exec map");
    return;
  }

Thus orc_compiler_allocate_codemem() returns without ever having done the following initialization:

compiler->program->code_size = SIZE;
compiler->codeptr = compiler->program->code;

Thus, compiler->codeptr is NULL, which later causes the seg fault in orc_x86_emit_push().

I'm sure if you mount /tmp as a separate filesystem and specify "noexec", you'll recreate the problem.

Mounting /tmp as a separate filesystem w/ noexec specified is a common method of helping to secure one's machine by preventing programs in /tmp from running.

Mmapping a file into the processes' address space which will be then be filled with instructions and then executed by the current process sounds great; although doing it in /tmp seems to me to open a potentially huge security hole. I know the code unlinks the file right after it's created, so perhaps it's a non-issue. Still, I'd run it by some security gurus to see if it passes muster.

So I guess the questions that need answering are:

1) Is orc mapping in executable files in /tmp wise?
2) Should compiler->codeptr be check for validity before use?

BTW, the code I refer to here is orc-0.4.6-1.fc13.i686.

Michael, thanks for your comprehensive bug-hunt :)
I agree with you, that mapping an orc program in /tmp might raise security concerns. But I'm not in the position to answer that question.

But I pointed the maintainer to this bug.

I just had a look at the sources. A lot changed since 0.4.6 Could you try 0.4.9 and see if this problem still persists?

Fabian, the problem still exists in 0.4.9, although you do get a useful assert:

/tmp mounted noexec:

82> gst-launch audiotestsrc ! volume volume=0.5 ! autoaudiosink
Setting pipeline to PAUSED ...                                                  
Pipeline is PREROLLING ...                                                      
ORC: ERROR: orccodemem.c(235): orc_code_region_allocate_codemem(): failed to create exec map                                                                    
ORC: ERROR: orccodemem.c(144): orc_code_region_get_free_chunk(): assertion failed: 0                                                                            
Abort(coredump)                                                                 
83>

At least you know now the problem has something to do with "map" and "exec". :)

remounting /tmp with exec of course works.

So - I can not reproduce the problem with 0.4.9 when I just mount a tmpfs noexec as orc will fall back to my homedir.

Could you try to figure out to what path orc is falling back (and failing)?

I finally am able to reproduce this problem :)
Stock Fedora 13 install wit SElinux enabled (supose enforcing) and a noexec tmp tmpfs directory.

$ mkdir /tmp/noexec
$ sudo mount -ttmpfs -onoexec none /tmp/noexec/
$ TMPDIR=/tmp/noexec/ gst-launch audiotestsrc ! volume volume=0.5 ! autoaudiosink
Leitung wird auf PAUSIERT gesetzt ...
Leitung läuft vor …
ORC: ERROR: orccodemem.c(235): orc_code_region_allocate_codemem(): failed to create exec map
ORC: ERROR: orccodemem.c(144): orc_code_region_get_free_chunk(): assertion failed: 0
Abgebrochen (Speicherabzug geschrieben)

And I can also say, that the current git master solves this problem :)
Michael, thanks for working out this problem (selinux combo).

Fabian, thank you for tackling this problem. I'm glad to hear it is already fixed in a forth-coming release. I missed the selinux connection because I always run the fedora default.

I really do think that orc should be creating its exec file in the user's home directory, rather than /tmp. That would alleviate my security concerns.

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

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

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

orc-0.4.10-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/orc-0.4.10-1.fc13

orc-0.4.10-1.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update orc'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/orc-0.4.10-1.fc13

orc-0.4.10-1.fc13 works just fine, thanks.

orc-0.4.10-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.