Re: INLINE_SYSCALL fails on x86_64

[mcirsta at frugalware dot org]

> 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
>
 Hi,

Thanks for your response. It turn out that was only an ... endpoint I
think it the term. I wasn't very experienced with Linux debugging nor KDE
, Qt debugging with GDB. I've managed to kind of isolate the problem to
KDE and the X sever.
 It's still the new glibc that makes it crash somehow in the end but I'm
almost certain it can't be blamed. The behavior was undefined long before
that and it finally crashed. It was about pixmaps with x being -23232 and
y being 32454 so there was no way this could have worked. Fixing the code
higher up should fix this problem.
 The only other issue I've bumped into is that I seem to have some
problems when creating new threads, something about none being
available... Not sure this is glibc related.