[arch-general] xcb_wait_for_reply () from /usr/lib/libxcb.so.1 causing kdesktop crash on x86_64 (is this an upstream issue?) - Arch-general - lists.archlinux.org

newer
Re: [arch-general]...

[arch-general] xcb_wait_for_reply () from /usr/lib/libxcb.so.1 causing kdesktop crash on x86_64 (is this an upstream issue?)

older
[arch-general] Kernel Panic on x64...

David C. Rankin

19 Feb 2011 19 Feb '11

1:39 a.m.

Guys, I have run into an issue that is only causing problems on x86_64. It looks like libxcb. The kcrash file is here: [2k] http://www.3111skyline.com/dl/dt/trinity/errors/x86_64/kdesktop-1.kcrash I need to figure out if this is an upstream libxcb issue or possibly a package issue. How do I figure this out? -- David C. Rankin, J.D.,P.E.

Show replies by date

Rémy Oudompheng

19 Feb 19 Feb

10:23 a.m.

On 2011/2/19 David C. Rankin wrote:

Guys,

I have run into an issue that is only causing problems on x86_64. It looks like libxcb. The kcrash file is here:

[2k] http://www.3111skyline.com/dl/dt/trinity/errors/x86_64/kdesktop-1.kcrash

I need to figure out if this is an upstream libxcb issue or possibly a package issue. How do I figure this out?

Hello, Your backtrace doesn't give any information: you might need to recompile xcb with debug symbols. Do you have messages in the console? It vaguely looks like a failed assertion, so giving more information about what events are actally happening around is also useful. Rémy.

David C. Rankin

6:05 p.m.

On 02/19/2011 03:23 AM, Rémy Oudompheng wrote:

Hello,

Your backtrace doesn't give any information: you might need to recompile xcb with debug symbols. Do you have messages in the console? It vaguely looks like a failed assertion, so giving more information about what events are actally happening around is also useful.

Rémy.

Thank you Rémy! That's the help I needed. I'll go rebuild xcb with debugging turned on. I'll look at how the PKGBUILD works, but depending on what it builds with, I may need help know what flags to set. Will report back :) -- David C. Rankin, J.D.,P.E.

David C. Rankin

7:19 p.m.

On 02/19/2011 11:05 AM, David C. Rankin wrote:

On 02/19/2011 03:23 AM, Rémy Oudompheng wrote:

...
Hello,

Your backtrace doesn't give any information: you might need to recompile xcb with debug symbols. Do you have messages in the console? It vaguely looks like a failed assertion, so giving more information about what events are actally happening around is also useful.

Rémy.

Thank you Rémy!

That's the help I needed. I'll go rebuild xcb with debugging turned on. I'll look at how the PKGBUILD works, but depending on what it builds with, I may need help know what flags to set. Will report back :)

Grrr.... How do I add a debugging flag? Do I use CFLAGS=-DEBUG? CPPFLAGS=-DEBUG? add --enable-debug? I've checked ./configure --help and it is silent on the issue. I've added the --enable-debug below. It builds fine, but is only slightly larger than the original: -rw-r--r-- 1 david david 274088 Feb 19 12:12 libxcb-1.7-1-x86_64.pkg.tar.xz -rw-r--r-- 1 david david 273996 Feb 19 11:46 libxcb-1.7-1-x86_64.pkg.tar.xz.sav Do I need to enable debugging in another manner? The build() is: build() { cd "${srcdir}/${pkgname}-${pkgver}" patch -Np1 -i "${srcdir}/libxcb-1.1-no-pthread-stubs.patch" libtoolize --force --copy aclocal autoconf automake --add-missing PYTHON=python2 ./configure --prefix=/usr --enable-xinput --enable-debug make make DESTDIR="${pkgdir}" install install -m755 -d "${pkgdir}/usr/share/licenses/${pkgname}" install -m644 COPYING "${pkgdir}/usr/share/licenses/${pkgname}/" } Any help appreciated :) -- David C. Rankin, J.D.,P.E.

Richard Schütz

7:35 p.m.

How do I add a debugging flag? Do I use CFLAGS=-DEBUG? CPPFLAGS=-DEBUG? add --enable-debug? I've checked ./configure --help and it is silent on the issue. I've added the --enable-debug below. It builds fine, but is only slightly larger than the original:

-rw-r--r-- 1 david david 274088 Feb 19 12:12 libxcb-1.7-1-x86_64.pkg.tar.xz -rw-r--r-- 1 david david 273996 Feb 19 11:46 libxcb-1.7-1-x86_64.pkg.tar.xz.sav

Do I need to enable debugging in another manner?

You must add 'options=(!strip)' to the PKGBUILD. Otherwise the debugging symbols will be removed by makepkg automatically after the build process. 'export CFLAGS="$CFLAGS -g"' and 'export CXXFLAGS="$CXXFLAGS -g"' tell the compiler to build the binaries with debugging symbols. -- Regards, Richard Schütz

David C. Rankin

8:07 p.m.

On 02/19/2011 12:35 PM, Richard Schütz wrote:

...
How do I add a debugging flag? Do I use CFLAGS=-DEBUG? CPPFLAGS=-DEBUG? add --enable-debug? I've checked ./configure --help and it is silent on the issue. I've added the --enable-debug below. It builds fine, but is only slightly larger than the original:

-rw-r--r-- 1 david david 274088 Feb 19 12:12 libxcb-1.7-1-x86_64.pkg.tar.xz -rw-r--r-- 1 david david 273996 Feb 19 11:46 libxcb-1.7-1-x86_64.pkg.tar.xz.sav

Do I need to enable debugging in another manner?

You must add 'options=(!strip)' to the PKGBUILD. Otherwise the debugging symbols will be removed by makepkg automatically after the build process.

'export CFLAGS="$CFLAGS -g"' and 'export CXXFLAGS="$CXXFLAGS -g"' tell the compiler to build the binaries with debugging symbols.

(whack!) Thanks Richard :) -- David C. Rankin, J.D.,P.E.

David C. Rankin

8:11 p.m.

On 02/19/2011 12:35 PM, Richard Schütz wrote:

...
How do I add a debugging flag? Do I use CFLAGS=-DEBUG? CPPFLAGS=-DEBUG? add --enable-debug? I've checked ./configure --help and it is silent on the issue. I've added the --enable-debug below. It builds fine, but is only slightly larger than the original:

-rw-r--r-- 1 david david 274088 Feb 19 12:12 libxcb-1.7-1-x86_64.pkg.tar.xz -rw-r--r-- 1 david david 273996 Feb 19 11:46 libxcb-1.7-1-x86_64.pkg.tar.xz.sav

Do I need to enable debugging in another manner?

You must add 'options=(!strip)' to the PKGBUILD. Otherwise the debugging symbols will be removed by makepkg automatically after the build process.

'export CFLAGS="$CFLAGS -g"' and 'export CXXFLAGS="$CXXFLAGS -g"' tell the compiler to build the binaries with debugging symbols.

That's better: -rw-r--r-- 1 david david 295756 Feb 19 13:11 libxcb-1.7-1-x86_64.pkg.tar.xz -rw-r--r-- 1 david david 273996 Feb 19 11:46 libxcb-1.7-1-x86_64.pkg.tar.xz.sav -- David C. Rankin, J.D.,P.E.

David C. Rankin

8:18 p.m.

On 02/19/2011 03:23 AM, Rémy Oudompheng wrote:

On 2011/2/19 David C. Rankin wrote:

...
Guys,

I have run into an issue that is only causing problems on x86_64. It looks like libxcb. The kcrash file is here:

[2k] http://www.3111skyline.com/dl/dt/trinity/errors/x86_64/kdesktop-1.kcrash

I need to figure out if this is an upstream libxcb issue or possibly a package issue. How do I figure this out?

Hello,

Your backtrace doesn't give any information: you might need to recompile xcb with debug symbols. Do you have messages in the console? It vaguely looks like a failed assertion, so giving more information about what events are actally happening around is also useful.

Rémy.

Here is the kcrash with libxcb recompiled with !strip and 'export CFLAGS="$CFLAGS -g"' and 'export CXXFLAGS="$CXXFLAGS -g"' http://www.3111skyline.com/dl/dt/trinity/arch/err/x86_64/kdesktop-libxcb-deb... It fills in a few more blanks in the _xcb_ functions: #10 0x00007f7c0725d460 in malloc () from /lib/libc.so.6 #11 0x00007f7c0379f91a in _xcb_in_read () from /usr/lib/libxcb.so.1 #12 0x00007f7c0379dbfa in _xcb_conn_wait () from /usr/lib/libxcb.so.1 #13 0x00007f7c0379f1af in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 #14 0x00007f7c07aacafd in _XReply () from /usr/lib/libX11.so.6 Could this be further up in libc? -- David C. Rankin, J.D.,P.E.

David C. Rankin

22 Feb 22 Feb

7:29 p.m.

New subject: [arch-general] [SOLVED - it's glibc - upstream or Arch?] was Re: xcb_wait_for_reply () from /usr/lib/libxcb.so.1 causing kdesktop crash on x86_64 (is this an upstream issue?)

On 02/19/2011 01:18 PM, David C. Rankin wrote:

On 02/19/2011 03:23 AM, Rémy Oudompheng wrote:

...
On 2011/2/19 David C. Rankin wrote:

...
Guys,

I have run into an issue that is only causing problems on x86_64. It looks like libxcb. The kcrash file is here:

[2k] http://www.3111skyline.com/dl/dt/trinity/errors/x86_64/kdesktop-1.kcrash

current kdesktop.kcrash: http://www.3111skyline.com/dl/dt/trinity/arch/err/x86_64/kdesktop-alchemy.kc...

...
...
I need to figure out if this is an upstream libxcb issue or possibly a package issue. How do I figure this out?

<snip>

Could this be further up in libc?

Details from Trinity List Discussion: On 02/21/2011 08:41 PM, David C. Rankin wrote:

...
On 02/21/2011 05:09 PM, PICCORO McKAY Lenz wrote:

...
...
uff i reading this http://lists.freedesktop.org/archives/xcb/2010-March/005818.html and seem like that!

any help fron anybody here!

I'll follow up there. I can't believe that an libxcb problem would still be around a year later. <snip>

Guys, The problem is glibc-2.13-4. I have about 5 Arch/Trinity Virtualbox VMs. On one I had not updated, I started Trinity x86_64 and there was NO kdesktop crash. I then proceeded to update the VM to the current Arch packages which included: [2011-02-22 11:13] Generating locales... [2011-02-22 11:13] en_US.UTF-8... done [2011-02-22 11:13] en_US.ISO-8859-1... done [2011-02-22 11:13] Generation complete. [2011-02-22 11:13] upgraded glibc (2.13-3 -> 2.13-4) <snip> [2011-02-22 11:17] upgraded kernel26 (2.6.37-6 -> 2.6.37.1-1) [2011-02-22 11:17] upgraded kernel26-headers (2.6.37-6 -> 2.6.37.1-1) <snip> [2011-02-22 11:18] upgraded trinity-kdelibs (1220926-1 -> 1222098-1) [2011-02-22 11:18] upgraded trinity-kdebase (1221507-1 -> 1221588-1) On next reboot/restart, I got the kdesktop.kcrash (see current link above). So then I downgraded glibc (2.13-4 -> 2.13-3), restarted Trinity -> perfect! No kdesktop,kcrash. Do you think this could be a packaging/patch issue with Arch, or do you think is going to be glibc itself? It looks like glibc to me, but I thought I'd ask first here before going to the glibc folks in case it was something that you guys wanted to look at. Thanks. -- David C. Rankin, J.D.,P.E.

4817

Age (days ago)

4820

Last active (days ago)

Download

8 comments

3 participants

tags

participants (3)

David C. Rankin
Richard Schütz
Rémy Oudompheng