This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: INLINE_SYSCALL fails on x86_64
On 4/22/2012 8:01 PM, mcirsta@frugalware.org wrote:
> Ever since the upgrade to gblic 2.15 I've been having a weird problem
> reported by KDE, it's crash that I've been able to trace back to poll.c ,
> line 87 (/sysdeps/unix/sysv/linux).
> I'm running Linux, kernel 3.3 , 64 bit, it's a less know distribution,
> Frugalware, for which I'm also a maintainer. Other people using 2.15 have
> reported this and it disappears when going back to 2.14. Also on i686
> everything runs just fine.
> You can see the patches we apply here:
> http://git.frugalware.org/gitweb/gitweb.cgi?p=frugalware-current.git;a=tree;f=source/base/glibc
> but there aren't many.
> Also I can't think of any special build flags being used.
> Stack trace is here:
>
> Thread 2 (Thread 0x7f35cb0b2700 (LWP 1380)):
> #0 0x00007f35e49a6fbf in __GI___poll (fds=<optimized out>,
> nfds=<optimized out>, timeout=<optimized out>) at
> ../sysdeps/unix/sysv/linux/poll.c:87
> #1 0x00007f35e16cf024 in g_main_context_iterate.isra.23 () from
> /usr/lib/libglib-2.0.so.0
> #2 0x00007f35e16cf144 in g_main_context_iteration () from
> /usr/lib/libglib-2.0.so.0
> #3 0x00007f35e5fc3676 in
> QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
> () from /usr/lib/libQtCore.so.4
> #4 0x00007f35e5f945bf in
> QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from
> /usr/lib/libQtCore.so.4
> #5 0x00007f35e5f94848 in
> QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
> /usr/lib/libQtCore.so.4
> #6 0x00007f35e5e997f0 in QThread::exec() () from /usr/lib/libQtCore.so.4
> #7 0x00007f35e5f7518f in ?? () from /usr/lib/libQtCore.so.4
> #8 0x00007f35e5e9c73b in ?? () from /usr/lib/libQtCore.so.4
> #9 0x00007f35e5c06dbe in start_thread (arg=0x7f35cb0b2700) at
> pthread_create.c:305
> #10 0x00007f35e49aeadd in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
>
> I've been able to find some differences in sysdep.h (
> sysdeps/unix/sysv/linux/x86_64/sysdep.h ) in the ASM code. Is this code
> used ? Could it have caused the problem.
Yes, that code is definitely used.
The poll call is sufficiently simple that it is a glibc
compiled assembly wrapper around the syscall.
The x86_64 sysdep.h file contains the definitions used
to create the assembly wrapper around the poll syscall.
You can know the poll syscall is an assembly wrapper
because it's defined here:
./sysdeps/unix/sysv/syscalls.list:poll - poll Ci:pii poll
Thus if you can isolate which change broke your application
then we can get closer to the root of the problem.
Cheers,
Carlos.
--
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026