INLINE_SYSCALL fails on x86_64

Carlos O'Donell carlos_odonell@mentor.com
Thu Apr 26 20:55:00 GMT 2012


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



More information about the Libc-help mailing list