headers
Charles philip Chan | 15 Jul 21:45
X-Face

Re: [Emacs.app dev]: Problems compiling Emacs.app with GNUstep

Adrian Robert <adrian.b.robert <at> gmail.com> writes:

Sorry for the late reply.

> If there is any way to find out which line of source code is leading
> to this "autorelease called without pool" that would be very helpful
> information.

I am still getting the error, this time with Emacs cvs. What is the best way
to debug this? I tried putting gdb before "$MAKE" but it produces no
back trace:

,----[ Output from gdb ]
|  Program exited with code 02.
| (gdb) bt
| No stack.
| (gdb)
| No stack.
`----

I have included this in case some one on the gnustep user list can shed
some light on it:

gmake[1]: Entering directory `/usr/src/packages/BUILD/emacs/src'
cd ../lisp; gmake -w autoloads EMACS=../src/bootstrap-emacs
gmake[2]: Entering directory `/usr/src/packages/BUILD/emacs/lisp'
EMACSLOADPATH=/usr/src/packages/BUILD/emacs/lisp LC_ALL=C ../src/bootstrap-emacs -batch
--no-site-file --multibyte -l autoload \
           --eval "(setq generate-autoload-cookie \";;;###cal-autoload\")" \
           --eval "(setq generated-autoload-file
(Continue reading)

Permalink | Reply |
headers
Fred Kiefer | 15 Jul 23:25

Re: [Emacs.app dev]: Problems compiling Emacs.app with GNUstep

Not sure what you are trying to do here, but you definitly don't want to 
debug make, you want to debug the  bootstrap-emacs.

Most likely you will want to send the following command:

EMACSLOADPATH=/usr/src/packages/BUILD/emacs/lisp LC_ALL=C  gdb 
../src/bootstrap-emacs -batch --no-site-file --multibyte -l autoload \
             --eval "(setq generate-autoload-cookie 
\";;;###cal-autoload\")" \
             --eval "(setq generated-autoload-file 
\"/usr/src/packages/BUILD/emacs/lisp/calendar/cal-loaddefs.el\")" \
             --eval "(setq make-backup-files nil)" \
             -f batch-update-autoloads \
/usr/src/packages/BUILD/emacs/lisp/calendar

(Sorry the mail program puts in stupid line breaks, just get them out again)

Fred

Charles philip Chan wrote:
> Adrian Robert <adrian.b.robert <at> gmail.com> writes:
> 
> Sorry for the late reply.
> 
>> If there is any way to find out which line of source code is leading
>> to this "autorelease called without pool" that would be very helpful
>> information.
> 
> I am still getting the error, this time with Emacs cvs. What is the best way
> to debug this? I tried putting gdb before "$MAKE" but it produces no
(Continue reading)

Permalink | Reply |
headers
Charles philip Chan | 15 Jul 23:50
X-Face

Re: [Emacs.app dev]: Problems compiling Emacs.app with GNUstep

Fred Kiefer <fredkiefer <at> gmx.de> writes:

> Not sure what you are trying to do here, but you definitly don't want
> to debug make, you want to debug the  bootstrap-emacs.

I am trying to debug why Emacs.app (which just got committed to EMacs
cvs) won't compile with GNUstep.

> EMACSLOADPATH=/usr/src/packages/BUILD/emacs/lisp LC_ALL=C  gdb
> ../src/bootstrap-emacs -batch --no-site-file --multibyte -l autoload \
> ...

Thanks Fred, you put me on the right track, I needed to add "--args" to
gdb to get a backtrace. Can you comment on this bt?


#0  0xb7f51410 in __kernel_vsyscall ()
#1  0xb7296c26 in kill () from /lib/libc.so.6
#2  0x08168526 in abort () at emacs.c:432
#3  0xb7731245 in _terminate () at NSException.m:697
#4  0xb77314e6 in _NSFoundationUncaughtExceptionHandler (exception=0x854b1c0) at NSException.m:724
#5  0xb7731cb7 in -[NSException raise] (self=0x854b1c0, _cmd=0xb7b22a20) at NSException.m:864
#6  0xb773170b in +[NSException raise:format:arguments:] (self=0xb7b22480, _cmd=0xb7b22a08, 
    name=0xb7b22208, format=0xb7b36000, argList=0xbfc0b8dc " Í°·sN©·") at NSException.m:767
#7  0xb7731643 in +[NSException raise:format:] (self=0xb7b22480, _cmd=0xb7b369b0, name=0xb7b22208, 
    format=0xb7b36000) at NSException.m:753
#8  0xb777b904 in -[NSObject doesNotRecognizeSelector:] (self=0xb7b0d0a0, _cmd=0xb7b36aa8, 
    aSelector=0x8409570) at NSObject.m:1705
#9  0xb777bae0 in -[NSObject forwardInvocation:] (self=0xb7b0d0a0, _cmd=0x8465b38,
(Continue reading)

Permalink | Reply |
headers
Adrian Robert | 16 Jul 02:02

Re: [Emacs.app dev]: Problems compiling Emacs.app with GNUstep


On Jul 15, 2008, at 5:50 PM, Charles philip Chan wrote:
>
> Thanks Fred, you put me on the right track, I needed to add "-- 
> args" to
> gdb to get a backtrace. Can you comment on this bt?
>
> #0  0xb7f51410 in __kernel_vsyscall ()
> #1  0xb7296c26 in kill () from /lib/libc.so.6
> #2  0x08168526 in abort () at emacs.c:432
> #3  0xb7731245 in _terminate () at NSException.m:697
> #4  0xb77314e6 in _NSFoundationUncaughtExceptionHandler  
> (exception=0x854b1c0) at NSException.m:724
> ...
> #11 0xb6e457d5 in __vacall_r () from /usr/local/lib/libcallback.so.0
> #12 0xb7b827c0 in returnTypeInfo ()
>    from /usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1.17
> #13 0xbfc0ba64 in ?? ()
> #14 0x00000004 in ?? ()
> #15 0xbfc0ba98 in ?? ()
> #16 0x00000000 in ?? ()

Hmm, I'm wondering why things get lost here..  It's been a while,  
maybe this is something inevitable, but I also remember when I was  
doing this a lot I would build Emacs.app with no optimization (remove  
-O2 in the compile script) and also use the debug version of the  
GNUstep libraries (I forget how I did this).  This definitely helps gdb.
Permalink | Reply |
headers
Charles philip Chan | 16 Jul 02:25
X-Face

Re: [Emacs.app dev]: Problems compiling Emacs.app with GNUstep

Adrian Robert <adrian.b.robert <at> gmail.com> writes:

Hello Adrian:

> Hmm, I'm wondering why things get lost here..  It's been a while,
> maybe this is something inevitable, but I also remember when I was
> doing this a lot I would build Emacs.app with no optimization (remove
> -O2 in the compile script) and also use the debug version of the
> GNUstep libraries (I forget how I did this).  This definitely helps
> gdb.

OK, I will make another backtrace with the debug version of GNUstep and
get back to you.

Charles


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep <at> gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Permalink | Reply |
headers
Charles philip Chan | 16 Jul 04:14
X-Face

Re: [Emacs.app dev]: Problems compiling Emacs.app with GNUstep

Adrian Robert <adrian.b.robert <at> gmail.com> writes:

> Hmm, I'm wondering why things get lost here..  It's been a while,
> maybe this is something inevitable, but I also remember when I was
> doing this a lot I would build Emacs.app with no optimization (remove
> -O2 in the compile script) and also use the debug version of the
> GNUstep libraries (I forget how I did this).  This definitely helps
> gdb.

Here is the back trace done with the debug version of GNUstep:


Starting program: /usr/src/packages/BUILD/emacs/src/bootstrap-emacs -batch --no-site-file
--multibyte -l autoload --eval \(setq\ generate-autoload-cookie\ \ \ \ \ \ \ \ \ \ \ \ \
\"\;\;\;\#\#\#cal-autoload\"\) --eval \(setq\ generated-autoload-file\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
\ \ \"/usr/src/packages/BUILD/emacs/lisp/calendar/cal-loaddefs.el\"\) --eval \(setq\
make-backup-files\ nil\) -f batch-update-autoloads /usr/src/packages/BUILD/emacs/lisp/calendar
[Thread debugging using libthread_db enabled]
[New Thread 0xb6c1e6d0 (LWP 10708)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb6c1e6d0 (LWP 10708)]
0xb7fca410 in __kernel_vsyscall ()
#0  0xb7fca410 in __kernel_vsyscall ()
#1  0xb730fc26 in kill () from /lib/libc.so.6
#2  0x08168526 in abort () at emacs.c:432
#3  0xb77aa245 in _terminate () at NSException.m:697
#4  0xb77aa4e6 in _NSFoundationUncaughtExceptionHandler (exception=0x854b1b8) at NSException.m:724
#5  0xb77aacb7 in -[NSException raise] (self=0x854b1b8, _cmd=0xb7b9ba20) at NSException.m:864
(Continue reading)

Permalink | Reply |
headers
Richard Frith-Macdonald | 16 Jul 08:29

Re: [Emacs.app dev]: Problems compiling Emacs.app with GNUstep


On 16 Jul 2008, at 03:14, Charles philip Chan wrote:

> Adrian Robert <adrian.b.robert <at> gmail.com> writes:
>
>> Hmm, I'm wondering why things get lost here..  It's been a while,
>> maybe this is something inevitable, but I also remember when I was
>> doing this a lot I would build Emacs.app with no optimization (remove
>> -O2 in the compile script) and also use the debug version of the
>> GNUstep libraries (I forget how I did this).  This definitely helps
>> gdb.
>
> Here is the back trace done with the debug version of GNUstep:
>
> Starting program: /usr/src/packages/BUILD/emacs/src/bootstrap-emacs - 
> batch --no-site-file --multibyte -l autoload --eval \(setq\ generate- 
> autoload-cookie\ \ \ \ \ \ \ \ \ \ \ \ \ \"\;\;\;\#\#\#cal-autoload 
> \"\) --eval \(setq\ generated-autoload-file\ \ \ \ \ \ \ \ \ \ \ \ \  
> \ \ \ \ \ \ \ \ \ \ \ \ \"/usr/src/packages/BUILD/emacs/lisp/ 
> calendar/cal-loaddefs.el\"\) --eval \(setq\ make-backup-files\ nil\)  
> -f batch-update-autoloads /usr/src/packages/BUILD/emacs/lisp/calendar
> [Thread debugging using libthread_db enabled]
> [New Thread 0xb6c1e6d0 (LWP 10708)]
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0xb6c1e6d0 (LWP 10708)]
> 0xb7fca410 in __kernel_vsyscall ()
> #0  0xb7fca410 in __kernel_vsyscall ()
> #1  0xb730fc26 in kill () from /lib/libc.so.6
> #2  0x08168526 in abort () at emacs.c:432
(Continue reading)

Permalink | Reply |
headers
Charles philip Chan | 16 Jul 13:54
X-Face

Re: [Emacs.app dev]: Problems compiling Emacs.app with GNUstep

Richard Frith-Macdonald <richard <at> tiptree.demon.co.uk> writes:

Hello Richard:

> Your application has reached the point of being terminated by an
> uncaught exception handler ... that means that it will have printed
> out the details of the exception to stderr, so you should be able to
> look at that and perhaps get a bit more information.

,----[ stderr ]
| 2008-07-16 06:36:33.353 bootstrap-emacs[6601] autorelease called without pool for object (8504ac8)
of class NSMethodSignature in thread <NSThread: 0x84f1260>
| 2008-07-16 06:36:33.363 bootstrap-emacs[6601] autorelease called without pool for object (85052f0)
of class GSCodeBuffer in thread <NSThread: 0x84f1260>
| 2008-07-16 06:36:33.372 bootstrap-emacs[6601] autorelease called without pool for object (854e138)
of class NSMethodSignature in thread <NSThread: 0x84f1260>
| 2008-07-16 06:36:33.381 bootstrap-emacs[6601] autorelease called without pool for object (853b848)
of class GSFFIInvocation in thread <NSThread: 0x84f1260>
| 2008-07-16 06:36:33.387 bootstrap-emacs[6601] autorelease called without pool for object (8544ce8)
of class GSCInlineString in thread <NSThread: 0x84f1260>
| 2008-07-16 06:36:33.395 bootstrap-emacs[6601] autorelease called without pool for object (8555b00)
of class NSException in thread <NSThread: 0x84f1260>
| 2008-07-16 06:36:33.403 bootstrap-emacs[6601] autorelease called without pool for object (8556d90)
of class GSMutableArray in thread <NSThread: 0x84f1260>
| ../src/bootstrap-emacs: Uncaught exception NSInvalidArgumentException, reason:
NSAutoreleasePool(class) does not recognize (null)
| Fatal error (6)gmake[2]: *** [/usr/src/packages/BUILD/emacs/lisp/emacs-lisp/bytecomp.elc] Aborted
`----

> However, the fact that the stacktrace shows the method
(Continue reading)

Permalink | Reply |
headers
Richard Frith-Macdonald | 16 Jul 15:00

Re: [Emacs.app dev]: Problems compiling Emacs.app with GNUstep


On 16 Jul 2008, at 12:54, Charles philip Chan wrote:
>
> #8  0xb7752980 in -[NSObject doesNotRecognizeSelector:]  
> (self=0xb7ae20e0, _cmd=0xb7b0bae8,
>    aSelector=0x8409570) at NSObject.m:1705
> #9  0xb7752b5c in -[NSObject forwardInvocation:] (self=0xb7ae20e0,  
> _cmd=0x8465b58,
>    anInvocation=0x853b4c8) at NSObject.m:1733
> #10 0xb7808866 in GSFFIInvocationCallback (cif=0x8544900,  
> retp=0xbf8bdf20, args=0xbf8bded0,
>    user=0x8544900) at GSFFIInvocation.m:547
> #11 0xb6e1a5da in ffi_closure_SYSV_inner (closure=0xb755c000,  
> respp=0xbf8bdf2c, args=0xbf8bdf40)
>    at src/x86/ffi.c:267
> #12 0xb6e1a92a in ffi_closure_SYSV () from /usr/local/lib/libffi.so.5
> #13 0x0827a831 in ns_alloc_autorelease_pool () at nsterm.m:519
> #14 0x08169dd7 in main (argc=15, argv=0xbf8be384) at emacs.c:1419

So now you know where the problem occurs ... line 519 of nsterm.m ...  
maybe that's some help.

> Interesting. Is libffi the preferred library now?

I suppose so ... the rationale for preferring ffcall was that it  
worked on more platforms, but with the latest releases of GNUstep-base  
I believe this is no longer the case.
Using libffi is much better for debug (when you want to look at a  
stack trace) and is essential for using native exceptions (with ffcall  
the native exception code is unable to unwind the stack and likely to
(Continue reading)

Permalink | Reply |
headers
Charles philip Chan | 16 Jul 16:17
X-Face

Re: [Emacs.app dev]: Problems compiling Emacs.app with GNUstep

Richard Frith-Macdonald <richard <at> tiptree.demon.co.uk> writes:

> I suppose so ... the rationale for preferring ffcall was that it
> worked on more platforms, but with the latest releases of GNUstep-base
> I believe this is no longer the case.

Thanks fo the info and all the help. Have a nice vacation. ;-)

Charles


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep <at> gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Permalink | Reply |
headers
Cezar Halmagean | 16 Jul 02:10

Re: [Emacs.app dev]: Problems compiling Emacs.app with GNUstep

I've downloaded the cvs code and cd emacs/nextstept && ./compile

Undefined symbols:
   "_tgetflag", referenced from:
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
   "_tgetent", referenced from:
       _init_tty in term.o
   "_tgetnum", referenced from:
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
       _init_tty in term.o
   "_BC", referenced from:
       _BC$non_lazy_ptr in cm.o
   "_PC", referenced from:
(Continue reading)

Permalink | Reply |
headers
Charles philip Chan | 16 Jul 02:24
X-Face

Re: [Emacs.app dev]: Problems compiling Emacs.app with GNUstep

Cezar Halmagean <cezar <at> mixandgo.com> writes:

Hello Cezar:

> I've downloaded the cvs code and cd emacs/nextstept && ./compile

IIRC, you are using Mac OS X. Can you please make a new thread about
your problem? This thread is about compiling Emacs.app with GNUstep and
not Mac OS X. This will confuse Adrian.

Thanks.

Charles


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep <at> gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Permalink | Reply |

Gmane