* Re: Crash on GNUstep
2011-12-01 22:09 Crash on GNUstep Germán Arias
@ 2011-12-01 22:17 ` Tekk
2011-12-01 22:26 ` chad
` (2 subsequent siblings)
3 siblings, 0 replies; 9+ messages in thread
From: Tekk @ 2011-12-01 22:17 UTC (permalink / raw)
To: Germán Arias; +Cc: emacs-devel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 943 bytes --]
On Thu, 1 Dec 2011, Germán Arias wrote:
> 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.
>
>
>
If I had to guess, no. The core issue looks like it's in cairo, which I'm
pretty sure would be a different build on osx(though I imagine most people
on osx would use aquamacs to avoid X deps anyway)
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Crash on GNUstep
2011-12-01 22:09 Crash on GNUstep Germán Arias
2011-12-01 22:17 ` Tekk
@ 2011-12-01 22:26 ` chad
2011-12-01 22:35 ` Glenn Morris
2011-12-01 22:50 ` Glenn Morris
2011-12-03 1:37 ` Adrian Robert
3 siblings, 1 reply; 9+ messages in thread
From: chad @ 2011-12-01 22:26 UTC (permalink / raw)
To: Germán Arias; +Cc: emacs-devel
Can you provide some detail on how to reproduce the crash?
I'm not seeing it on macosx if I do simple things like open/edit/write/close files or view (jpg, png) images. The reference to libcairo also suggests that the problem is not on the macosx path.
Hope that helps,
*Chad
On Dec 1, 2011, at 2:09 PM, Germán Arias wrote:
> 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.
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Crash on GNUstep
2011-12-01 22:09 Crash on GNUstep Germán Arias
2011-12-01 22:17 ` Tekk
2011-12-01 22:26 ` chad
@ 2011-12-01 22:50 ` Glenn Morris
2011-12-03 1:37 ` Adrian Robert
3 siblings, 0 replies; 9+ messages in thread
From: Glenn Morris @ 2011-12-01 22:50 UTC (permalink / raw)
To: Germán Arias; +Cc: emacs-devel
Germán Arias wrote:
> Emacs.app (rev 106570) crash with:
>
> (gdb) backtrace
Please obtain a full backtrace from an unoptimized build, and open a bug
report (using M-x report-emacs-bug to get all the details about your
system). Thanks.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Crash on GNUstep
2011-12-01 22:09 Crash on GNUstep Germán Arias
` (2 preceding siblings ...)
2011-12-01 22:50 ` Glenn Morris
@ 2011-12-03 1:37 ` Adrian Robert
2011-12-03 5:02 ` Germán Arias
3 siblings, 1 reply; 9+ messages in thread
From: Adrian Robert @ 2011-12-03 1:37 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Crash on GNUstep
2011-12-03 1:37 ` Adrian Robert
@ 2011-12-03 5:02 ` Germán Arias
0 siblings, 0 replies; 9+ messages in thread
From: Germán Arias @ 2011-12-03 5:02 UTC (permalink / raw)
To: emacs-devel
On 2011-12-02 19:37:47 -0600 Adrian Robert <Adrian.B.Robert@gmail.com>
wrote:
>
> 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.
6 months ago, Emacs.app didn't show this problem. Suddenly I had
problems
to compile (problems with native Objc exceptions) and I leave this for
a time.
Now it compiles OK, but crash. I'm using GNUstep from SVN (we are near
to a
release). So I don't know if something has changed in emacs, or if is
a problem
in gnustep. Tomorrow I will make an unoptimized build to send the bug
report.
Thanks.
^ permalink raw reply [flat|nested] 9+ messages in thread