Crash on GNUstep

Crash on GNUstep

[Germán Arias]

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.

Re: Crash on GNUstep

[Tekk]

[-- 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)

Re: Crash on GNUstep

[chad]

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.
> 
> 

Re: Crash on GNUstep

[Glenn Morris]

chad wrote:

> Can you provide some detail on how to reproduce the crash?

1) Run a GNUstep build.

> I'm not seeing it on macosx

Re: Crash on GNUstep

[Glenn Morris]

Glenn Morris wrote:

> chad wrote:
>
>> Can you provide some detail on how to reproduce the crash?
>
> 1) Run a GNUstep build.

To elaborate, I doubt if more than a handful of people have tried to
build the current trunk under GNUstep (I have; it wasn't usable, though
I wasn't sure if my GNUstep installation was messed up). I'm sure it has
lots of issues that are unlikely to be directly mirrored on Mac OS X.

Re: Crash on GNUstep

[Glenn Morris]

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.

Re: Crash on GNUstep

[chad]

On Dec 1, 2011, at 2:41 PM, Glenn Morris wrote:

> Glenn Morris wrote:
> 
>> chad wrote:
>> 
>>> Can you provide some detail on how to reproduce the crash?
>> 
>> 1) Run a GNUstep build.

Sure, but the OP asked specifically if ``this problem is present on Mac or not'', I assume (without knowledge, admittedly) as an aid to debugging the GNUstep issue.

*Chad

Re: Crash on GNUstep

[Adrian Robert]

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

Re: Crash on GNUstep

[Germán Arias]

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.