emacs-devel
[Top][All Lists]
Advanced

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

Re: Crash on GNUstep


From: Adrian Robert
Subject: Re: Crash on GNUstep
Date: Sat, 3 Dec 2011 01:37:47 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Germán Arias <german <at> xelalug.org> writes:

> 
> Emacs.app (rev 106570) crash with:
> 
> (gdb) backtrace
> #0  objc_msg_lookup (receiver=0x1200016, op=0x84836b0)
>      at /home/german/Instalados/GCC/gcc-4.6.0/libobjc/sendmsg.c:397
> #1  0x08266900 in ns_retain_object (obj=0x1200016) at nsterm.m:466
> #2  0x08256b62 in XGetImage (display=0x89b4c88, pixmap=0x1200016, x=0, 
> y=0,
>      width=64, height=64, plane_mask=4294967295, format=2) at 
> image.c:160
> #3  0xb508c2ea in ?? () from /usr/lib/libcairo.so.2
> #4  0x089b4c88 in ?? ()
> #5  0x01200016 in ?? ()
> #6  0x00000000 in ?? ()
> 
> I would like know if this problem is present on Mac or not. If not, 
> should be a problem with latest changes in gnustep. Thanks.

Hi,

I don't remember a whole lot about how this code works, but the
XGetImage function at image.c:160 is kind of a way to fake out
some of the other image code which was originally written around
X-windows to work under NS.  It appears that w32 does not take
this approach here, and maybe NS shouldn't be either, since it
looks like what has happened in this case is that somehow the
linking has caused cairo's attempt to call the real X function to
enter into our code instead of the X library which is doubtless
also linked.

On the Mac there won't be any external libraries trying to make X
calls so it couldn't happen, but I'm not sure why it never
occurred in my original testing on GNUstep either.  The code
should probably be changed to follow the approach NT does by
skipping implementing and calling this function entirely.

thanks,
Adrian





reply via email to

[Prev in Thread] Current Thread [Next in Thread]