[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

GitLab Migration User  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|NEW |RESOLVED

--- Comment #20 from GitLab Migration User  ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance:
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/522.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066
Bug 99066 depends on bug 103656, which changed state.

Bug 103656 Summary: get_cpuid inline asm violates red zone
https://bugs.freedesktop.org/show_bug.cgi?id=103656

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #19 from EoD  ---
(In reply to Tanu Kaskinen from comment #16)
> 
> Sorry, I never filed that bug, because I got distracted by other stuff.
> Would you be able to report the bug?
I reported it and it has been "RESOLVED INVALID" shortly after. 

In order to stay on the actual ORC issue here, I think it might be best to move
the get_cpuid discussion to bug 103656

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

EoD  changed:

   What|Removed |Added

 Depends on||103656


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=103656
[Bug 103656] get_cpuid inline asm violates red zone
-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #17 from EoD  ---
(In reply to Tanu Kaskinen from comment #16)
> (In reply to EoD from comment #15)
> > Could you link the bug report by any chance?
> 
> Sorry, I never filed that bug, because I got distracted by other stuff.
> Would you be able to report the bug?

Sure, but are you able to reproduce the issue with GCC 5.5, 6.4 or even 7.2? 
I cna just copy the problem with get_cpuid() here, but it might be easier
if I had a way to reproduce the issue here. How did you create/read the asm?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #16 from Tanu Kaskinen  ---
(In reply to EoD from comment #15)
> Could you link the bug report by any chance?

Sorry, I never filed that bug, because I got distracted by other stuff. Would
you be able to report the bug?

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #15 from EoD  ---
(In reply to Tanu Kaskinen from comment #12)
> I guess I'll have to prepare a bug report for GCC next (I'm not sure if it's
> a compiler bug, but hopefully they'll tell me).

Could you link the bug report by any chance?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #14 from Tanu Kaskinen  ---
I was asked for more information about the cpuid crash, so here we go:

This is the code that GCC generates for get_cpuid() on x32:

0xf7b6a270   push   %rbp
0xf7b6a271 mov%esp,%ebp
0xf7b6a273 mov%edi,-0x4(%ebp)
0xf7b6a277 mov%rcx,%rax
0xf7b6a27a    mov%r8,%rcx
0xf7b6a27d    mov%esi,-0x8(%ebp)
0xf7b6a281    mov%edx,-0xc(%ebp)
0xf7b6a285    mov%eax,-0x10(%ebp)
0xf7b6a289    mov%ecx,-0x14(%ebp)
0xf7b6a28d    mov-0x4(%ebp),%eax  [breakpoint]
0xf7b6a291    push   %rbx
0xf7b6a292    cpuid
0xf7b6a294    mov%ebx,%esi
0xf7b6a296    pop%rbx
0xf7b6a297    mov-0x8(%ebp),%edi
0xf7b6a29b    mov%eax,(%edi)  [segfault]
0xf7b6a29e    mov-0xc(%ebp),%eax
0xf7b6a2a2    mov%esi,(%eax)
0xf7b6a2a5    mov-0x10(%ebp),%eax
0xf7b6a2a9    mov%ecx,(%eax)
0xf7b6a2ac    mov-0x14(%ebp),%eax

"[breakpoint]" marks the place where the execution stops if you set a
breakpoint with "break get_cpuid". "[segfault]" marks the place where the crash
happens.

Before the breakpoint there's the code that copies the function parameters to
the stack as follows:

%edi is the "op" parameter. It's saved to -0x4(%ebp).
%rcx is the "c" parameter. It's moved to %rax and from %rax to -0x10(%ebp).
%r8 is the "d" parameter. It's moved to %rcx and from %rcx to -0x14(%ebp).
%esi is the "a" parameter. It's saved to -0x8(%ebp).
%edx is the "b" parameter. It's saved to -0xc(%ebp).

The stack pointer is not updated when the parameters are saved to the stack.
Since the stack pointer points to the beginning of the frame, the push
instruction overwrites 8 bytes from the beginning of the frame, overwriting the
"op" and "a" parameters.

I think the push is done, because the %rbx register is special in that it must
always have the same value when returning from a function as it had when the
function started. The cpuid instruction modifies the %rbx register, so that's
why we need to save and restore the %rbx register.

After the pop, this happens:

0xf7b6a297    mov-0x8(%ebp),%edi

This reads the stack from the position where the "a" parameter was saved. The
compiler seems to assume that it has the same value that was written there in
the beginning of the function, but the push instruction has written some random
garbage there.

0xf7b6a29b    mov%eax,(%edi)  [segfault]

This is supposed to save the return value (well, one part of the return value)
of the cpuid instruction to the address stored in %edi, but we just wrote
garbage to %edi, so we end up dereferencing using garbage as the pointer (in my
tests the value in %edi was 1).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

Arun Raghavan  changed:

   What|Removed |Added

 CC||wim.taym...@gmail.com

--- Comment #13 from Arun Raghavan  ---
Also CC'ing Wim in case he's seen this before.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #12 from Tanu Kaskinen  ---
I found out the reason for the get_cpuid() crash. The function looks like this
(slightly edited for readability):

static void get_cpuid(uint32_t op,
  uint32_t *a, uint32_t *b, uint32_t *c, uint32_t *d) {
__asm__ __volatile__ (
"  push %%rbx  \n\t"
"  cpuid   \n\t"
"  mov %%ebx, %%esi\n\t"
"  pop %%rbx   \n\t"

: "=a" (*a), "=S" (*b), "=c" (*c), "=d" (*d)
: "0" (op)
);
}

When building without optimizations, the function parameters are saved in the
stack. The stack pointer register isn't updated, however, so our push
instruction ends up overwriting the op and a parameters! Before that happens,
the op parameter is saved in the eax register, and the stack memory for op
won't be needed after that, so that's fine, but the a parameter is replaced
with whatever happened to be in the rbx register. When trying to save the cpuid
result in the memory pointed to by a, a segfault happens, because a is an
invalid pointer at that point.

If the stack pointer was updated when the compiler wrote the parameters in the
stack, this would have been avoided. So is this a compiler bug? I'm not sure. I
found out that the AMD64 ABI allows the compiler to not update the stack
pointer in functions that don't call other functions. However, if the stack
pointer is not updated, inline assembly that relies on the stack pointer will
not work as intended (as seen here), so maybe the compiler should always update
the stack pointer if it sees that the function contains inline assembly code
that has push/pop instructions?

This code happens to work on a "normal" 64-bit system by chance, because the
memory layout for the pointers is a bit different, and the push operation will
only overwrite the op parameter, which does no harm. When building with
optimizations, I guess the function parameters aren't saved in the stack, so
that will also avoid the crash.

I guess I'll have to prepare a bug report for GCC next (I'm not sure if it's a
compiler bug, but hopefully they'll tell me).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #11 from Tanu Kaskinen  ---
A small status update: I managed to reproduce the crash in an x32 chroot. Then
I built pulseaudio without optimizations, because I didn't like gdb telling me
"optimized out" when I asked it something, and now I get a segfault during
startup in pulsecore/cpu-x86.c:33 get_cpuid(). I'll try to figure out the cpuid
segfault first, but if that'll turn out to be too difficult, I'll continue by
taking the crashing volume code and putting it in a small self-contained test
case.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #10 from EoD  ---
(In reply to Tanu Kaskinen from comment #9)
> Did you try with module-null-sink? If the crash only happens with HDMI, I
> will likely not be able to reproduce it.

Yes, it also happens with a null-sink. The backtrace looks basically identical
on the steps #0, #1 and #2.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #9 from Tanu Kaskinen  ---
Did you try with module-null-sink? If the crash only happens with HDMI, I will
likely not be able to reproduce it.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #8 from EoD  ---
(In reply to Tanu Kaskinen from comment #7)
> Debugging this isn't going to be fun. The backtrace isn't very helpful,
> because the crash happens in ORC-generated code that can be only debugged by
> reading the assembly code. I'm tempted to disable ORC in pulseaudio until
> ORC gets fixed (or until someone shows that this is actually a pulseaudio
> bug)... but let's not give up quite yet.
> 
> I could try to reproduce this, but I don't have HDMI and I don't have an x32
> environment. Can you reproduce this with module-null-sink instead of the
> HDMI output? As for the x32 environment, do you think it would be possible
> for me to run an x32 environment in a chroot in an otherwise 64-bit system?

I tried a chroot inside my amd64 system and I can reproduce the crash there.
But I do have a multilib (glibc/gcc) setup with amd64, x86 and x32.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #7 from Tanu Kaskinen  ---
Debugging this isn't going to be fun. The backtrace isn't very helpful, because
the crash happens in ORC-generated code that can be only debugged by reading
the assembly code. I'm tempted to disable ORC in pulseaudio until ORC gets
fixed (or until someone shows that this is actually a pulseaudio bug)... but
let's not give up quite yet.

I could try to reproduce this, but I don't have HDMI and I don't have an x32
environment. Can you reproduce this with module-null-sink instead of the HDMI
output? As for the x32 environment, do you think it would be possible for me to
run an x32 environment in a chroot in an otherwise 64-bit system?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #6 from EoD  ---
Created attachment 128733
  --> https://bugs.freedesktop.org/attachment.cgi?id=128733=edit
svolume-orc-gen.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #5 from EoD  ---
Created attachment 128732
  --> https://bugs.freedesktop.org/attachment.cgi?id=128732=edit
pulseaudio gdb backtrace

Here is a gdb backtrace for the pulseaudio instance

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #4 from EoD  ---
Created attachment 128708
  --> https://bugs.freedesktop.org/attachment.cgi?id=128708=edit
pavucontrol gdb backtrace

(In reply to Tanu Kaskinen from comment #3)
> Do you know how to get a backtrace with gdb?

What backtrace did you have in mind? I ran a backtrace on pavucontrol while
changing the volume slider for the HDMI sink (see attachment).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #3 from Tanu Kaskinen  ---
Do you know how to get a backtrace with gdb?

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #2 from EoD  ---
(In reply to Tanu Kaskinen from comment #1)
> It's weird that this doesn't happen with the analog sink. The difference
> could be due to having hardware volume for the analog sink but not for the
> hdmi sink. Can you reproduce this on either sink if you set "flat-volumes =
> no" in ~/.config/pulse/daemon.conf and change a stream volume rather than a
> sink volume?

The option does not make a difference, but I found a few more patterns:

- When I just *start* pavucontrol while mplayer is playing via pulse, I get an
segfault. The same happens when pavucontrol is running and mplayer is started.

- When I try to switch an analog stream to a hdmi stream in pavucontrol, I get
a segfault as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

[pulseaudio-tickets] [Bug 99066] Pulseaudio segfaults when ORC is used on x32

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99066

--- Comment #1 from Tanu Kaskinen  ---
It's weird that this doesn't happen with the analog sink. The difference could
be due to having hardware volume for the analog sink but not for the hdmi sink.
Can you reproduce this on either sink if you set "flat-volumes = no" in
~/.config/pulse/daemon.conf and change a stream volume rather than a sink
volume?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs