Don't get fooled by the name. I had a short look at the Emacs GIT source code yesterday and things are a lot more complicated as they seem. (Aren't they always?) What is called Pixmap here should be an EmacsImage object if the code in nsimage.m behaves correctly. Emacs just reuses the X function call prototype for Cocoa but expects completely differnet behaviour from it. No idea why they do it that way. From what Icould see I would expect that we are notdealing with an X Pixmap here and that the real problem may be somewhere else. But the last time I tried to track down an issue in Emacs I failed, because of this unusual code structure.
Fred On the road Am 24.12.2011 um 05:47 schrieb Germán Arias <[email protected]>: > You are right this is confusing. But maybe is possible delete this code > that don't have sense. > > On 2011-12-23 03:07:24 -0600 Ivan Vučica <[email protected]> wrote: > >> I'm new to Xlib, but isn't Pixmap an integer? How could have one ever sent >> an >> Objective-C message to an integer? >> >> Shouldn't there be a wrapper around this integer if one wants to retain it? >> >> Why bother retaining an object which is not a part of Objective-C reference >> counting system? >> >> I'm confused. :) >> >> Regards, >> >> Ivan Vučica >> via phone >> >> On 23. 12. 2011., at 02:47, Germán Arias <[email protected]> wrote: >> >>> Currently Emacs.app crash at launch with GNUstep. It worked fine >>> previously. I thought >>> it was caused by changes in emacs, but someone has confirmed it works fine >>> with the stable >>> packages of GNUstep (I will test it tomorrow). So the problem could be in >>> gnustep. Below I >>> add the backtrace. The app crash because can't retain a pixmap. >>> >>> Here the backtrace: >>> >>> (gdb) backtrace >>> #0 objc_msg_lookup (receiver=0x1400016, op=0x8482710) >>> at /home/german/Instalados/GCC/gcc-4.6.0/libobjc/sendmsg.c:397 >>> #1 0x082657b0 in ns_retain_object (obj=0x1400016) at nsterm.m:466 >>> #2 0x08255ac2 in XGetImage (display=0x89af8e8, pixmap=0x1400016, x=0, y=0, >>> width=64, height=64, plane_mask=4294967295, format=2) at image.c:160 >>> #3 0xb50a62ea in ?? () from /usr/lib/libcairo.so.2 >>> #4 0x089af8e8 in ?? () >>> #5 0x01400016 in ?? () >>> #6 0x00000000 in ?? () >>> (gdb) >>> >>> >>> At frame 2 the function XGetImage is: >>> >>> XImagePtr >>> XGetImage (Display *display, Pixmap pixmap, int x, int y, >>> unsigned int width, unsigned int height, >>> unsigned long plane_mask, int format) >>> { >>> /* TODO: not sure what this function is supposed to do.. */ >>> ns_retain_object (pixmap); >>> return pixmap; >>> } >>> >>> And at frame 1 the function ns_retain_object is: >>> >>> void >>> ns_retain_object (void *obj) >>> /* >>> -------------------------------------------------------------------------- >>> Retain an object (callable from C) >>> >>> -------------------------------------------------------------------------- >>> */ >>> { >>> [(id)obj retain]; >>> } >>> >>> Can this problem be related with the changes about how the images >>> are handled? Any idea? Thanks. >>> >>> >>> _______________________________________________ >>> Gnustep-dev mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/gnustep-dev >> >> > > > _______________________________________________ > Gnustep-dev mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
