[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [bisected] Unstable desktop experience with kernel > 2.6.38



Hi,

I have the strong impression that commit
37a9d912b24f96a0591773e6e6c3642991ae5a70 (futex: Sanitize
cmpxchg_futex_value_locked API) breaks something more general on
IA-64.

Yesterday, I though that PulseAudio was involved in the Iceweasel
crash and the X restart when hitting the tab key while in a GNOME
terminal window. Well, this is definitely the case, but PulseAudio is
probably not the root cause, only a side effect.

As you may remember, I was also unable to start up a gdb session
yesterday. This is still true, but with kernel > 2.6.38 only.
Rebooting my system with kernel <= 2.6.38 makes gdb happy again.

Is there a way to debug gdb itself? I didn't found a gdb-dbg package.
The idea is trying to collect various stack traces from various
incorrectly running programs with kernel > 2.6.38 in order to converge
to _the_ binary or library impacted by the cmpxchg_futex change and
that renders IA-64 barely usable at this time.

     Émeric


Le 4 février 2012 19:32, Émeric Maschino <emeric.maschino@gmail.com> a écrit :
> Hi,
>
> Just to let you know that, as could have been guessed from my initial
> post (http://lists.debian.org/debian-ia64/2012/01/msg00016.html),
> PulseAudio is involved. Uninstalling pulseaudio,
> pulseaudio-esound-compat, pulseaudio-module-x11, pulseaudio-utils and
> gstreamer0.10-pulseaudio packages "fixes" the issue. Obviously, you
> get no more sound :-(.
>
> Is there something in PulseAudio source code that hasn't been updated
> (maybe only on IA-64?) following commit
> 37a9d912b24f96a0591773e6e6c3642991ae5a70 (futex: Sanitize
> cmpxchg_futex_value_locked API)?
>
> The bad news: I can't provide more information at this time as all the
> programs that I've tried to ran through gdb (most notably iceweasel
> and gnome-terminal as they were my easy to reproduce scenarii) are
> receiving SIGTRAP signal, and bt full reports No symbol table info
> available. I however have debug packages installed.
>
>     Émeric
>
>
> Le 28 janvier 2012 20:21, Patrick Baggett <baggett.patrick@gmail.com> a écrit :
>> From looking at:
>>
>> http://neil.brown.name/git?p=linux-2.6;a=blobdiff;f=arch/ia64/include/asm/futex.h;h=b0728404dad05c9349aea95d4e28b91b1b363a21;hp=c7f0f062239cd541112ecbe10cdd34dc54672eec;hb=37a9d912b24f96a0591773e6e6c3642991ae5a70;hpb=522d7decc0370070448a8c28982c8dfd8970489e
>>
>> It doesn't look like the return value (r8) is actually being set beyond
>> initialized to 0. If there is some ia64 instruction that modifies it, GCC
>> doesn't know about it from the inline assembly (r8 doesn't appear in the
>> inputs/outputs list). From looking at the x86 version (agh, inline asm is
>> hard to parse), it does modify the return value based on whether the
>> comparison was a success or not, and the return value is certainly used by
>> the callers.
>>
>> Patrick
>>
>> On Sat, Jan 28, 2012 at 6:43 AM, Émeric Maschino <emeric.maschino@gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> Just to let you know that I've bisected this issue to commit
>>> 37a9d912b24f96a0591773e6e6c3642991ae5a70
>>> (futex: Sanitize cmpxchg_futex_value_locked API).
>>>
>>>     Émeric
>>>
>>>
>>>
>>> Le 17 janvier 2012 23:11, Émeric Maschino <emeric.maschino@gmail.com> a
>>> écrit :
>>> > Hi,
>>> >
>>> > Since there's a workaround allowing us to go kernel > 2.6.38
>>> > (http://lists.debian.org/debian-ia64/2012/01/msg00013.html), I
>>> > obviously updated my Testing system to current
>>> > linux-image-3.1.0-1-mckinley_3.1.8-2_ia64.deb.
>>> >
>>> > Well, graphical desktop experience is _unstable_. When I say "desktop
>>> > experience", I'm talking about basic desktop tasks, not fancy OpenGL
>>> > rendering. I have at least two reproducible scenari (I'm running Gnome
>>> > Classic):
>>> > - random X restart while typing into a GNOME terminal window
>>> > - Iceweasel killed when I try to click on the Back button or while
>>> > trying to click on the Edit menu.
>>> >
>>> > For the latter one, I managed to get a stack trace with gdb, before
>>> > gdb itself core dumped (huge core available if interested!) or X is
>>> > restarted... It seems that something goes wrong with PulseAudio when
>>> > running kernel 3.1:
>>> >
>>> > Program received signal SIGABRT, Aborted.
>>> > [Switching to Thread 0x7002b5231e0 (LWP 2282)]
>>> > 0xa000000000040721 in __kernel_syscall_via_break ()
>>> >
>>> > Thread 19 (Thread 0x7002b5231e0 (LWP 2282)):
>>> > #0  0xa000000000040721 in __kernel_syscall_via_break ()
>>> > No symbol table info available.
>>> > #1  0x200000000031a900 in raise () from /lib/ia64-linux-gnu/libc.so.6.1
>>> > No symbol table info available.
>>> > #2  0x2000000000322eb0 in abort () from /lib/ia64-linux-gnu/libc.so.6.1
>>> > No symbol table info available.
>>> > #3  0x000007001612a310 in pa_mutex_unlock ()
>>> >   from /usr/lib/ia64-linux-gnu/libpulsecommon-1.0.so
>>> > No symbol table info available.
>>> > #4  0x000007001604f8b0 in poll_func ()
>>> >   from /usr/lib/ia64-linux-gnu/libpulse.so.0
>>> > No symbol table info available.
>>> >
>>> > Rebooting my Testing system with good old kernel 2.6.38-5 brings a
>>> > stable desktop experience back.
>>> >
>>> > I've performed regression testing: the issue is already there with
>>> > linux-image-2.6.39-rc4-mckinley_2.6.39~rc4-1~experimental.1_ia64.deb,
>>> > the immediate successor to
>>> > linux-image-2.6.38-2-mckinley_2.6.38-5_ia64.deb in
>>> > snapshot.debian.org. Latest available
>>> > linux-image-3.2.0-rc7-mckinley_3.2~rc7-1~experimental.1_ia64.deb still
>>> > provides unstable desktop experience.
>>> >
>>> > Does this sound familiar to someone? Is this problem already known and
>>> > reported somewhere or is it worth filing a bug and going the git
>>> > bisect route?
>>> >
>>> >     Émeric
>>>
>>>
>>> --
>>> To UNSUBSCRIBE, email to debian-ia64-REQUEST@lists.debian.org
>>> with a subject of "unsubscribe". Trouble? Contact
>>> listmaster@lists.debian.org
>>> Archive:
>>> http://lists.debian.org/CAA9xbM5Gw5tZFOvtzykk8E8U6WKDfBEqrhBLM_As9qq7wqQ@mail.gmail.com
>>>
>>


Reply to: