C-g crash in C-x C-f (OSX Lion)

C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

As previously mentioned Emacs.app reliably crashes for me
on Lion in trunk builds.

Crash happens if I was waiting in C-x C-f and at some point
later after having switched away and back to Emacs.app
decide to cancel the the file open by pressing C-g.

This time around I saved the OS-provided stacktrace.

Is this of any use to track down the source?

Identifier:      org.gnu.Emacs
Version:         Version 24.0.92 (9.0)
Code Type:       X86 (Native)

Date/Time:       2011-12-12 13:58:40.521 +0100
OS Version:      Mac OS X 10.7.2 (11C74)
Report Version:  9

Interval Since Last Report:          2175927 sec
Crashes Since Last Report:           110
Per-App Interval Since Last Report:  126761 sec
Per-App Crashes Since Last Report:   3

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000026ce000

VM Regions Near 0x26ce000:
    __DATA 0000000001b00000-0000000001c00000 [ 1024K] rw-/rw- SM=COW
    /Users/USER/*/Emacs.app/Contents/MacOS/Emacs
--> MALLOC_SMALL 0000000002000000-0000000002706000 [ 7192K] rw-/rwx SM=ZER

    MALLOC_SMALL 0000000002706000-0000000002721000 [  108K] rw-/rwx SM=PRV

Application Specific Information:
objc[47317]: garbage collection is OFF
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x94fa5332 __kill + 10
1   libsystem_kernel.dylib        	0x94fa4932 kill$UNIX2003 + 32
2   org.gnu.Emacs                 	0x0009e004 fatal_error_signal + 324
3   libsystem_c.dylib             	0x9adc659b _sigtramp + 43
4   ???                           	0xffffffff 0 + 4294967295
5   libsystem_c.dylib             	0x9ad61bdd abort + 167
6   org.gnu.Emacs                 	0x0018433d ns_term_shutdown + 141
7   org.gnu.Emacs                 	0x0009bd67 shut_down_emacs + 247
8   org.gnu.Emacs                 	0x0009dfce fatal_error_signal + 270
9   libsystem_c.dylib             	0x9adc659b _sigtramp + 43
10  ???                           	0xffffffff 0 + 4294967295
11  org.gnu.Emacs                 	0x000ab8ae read_char + 6174
12  org.gnu.Emacs                 	0x000af005 read_key_sequence + 7093
13  org.gnu.Emacs                 	0x000b0d7b command_loop_1 + 5915
14  org.gnu.Emacs                 	0x00117256 internal_condition_case + 230
15  org.gnu.Emacs                 	0x000af645 command_loop_2 + 69
16  org.gnu.Emacs                 	0x0011731f internal_catch + 175
17  org.gnu.Emacs                 	0x000b1371 recursive_edit_1 + 353
18  org.gnu.Emacs                 	0x000cdf4d read_minibuf + 2381
19  org.gnu.Emacs                 	0x000cb470 Fread_from_minibuffer + 224
20  org.gnu.Emacs                 	0x00113d68 Ffuncall + 1128
21  org.gnu.Emacs                 	0x0014d7bd exec_byte_code + 1693
22  org.gnu.Emacs                 	0x001164ed funcall_lambda + 349
23  org.gnu.Emacs                 	0x00113dd5 Ffuncall + 1237
24  org.gnu.Emacs                 	0x000ccfb8 Fcompleting_read + 104
25  org.gnu.Emacs                 	0x00113d68 Ffuncall + 1128
26  org.gnu.Emacs                 	0x0014d7bd exec_byte_code + 1693
27  org.gnu.Emacs                 	0x001164ed funcall_lambda + 349
28  org.gnu.Emacs                 	0x00113dd5 Ffuncall + 1237
29  org.gnu.Emacs                 	0x0014d7bd exec_byte_code + 1693
30  org.gnu.Emacs                 	0x001164ed funcall_lambda + 349
31  org.gnu.Emacs                 	0x00113dd5 Ffuncall + 1237
32  org.gnu.Emacs                 	0x0014d7bd exec_byte_code + 1693
33  org.gnu.Emacs                 	0x001166f6 funcall_lambda + 870
34  org.gnu.Emacs                 	0x00113dd5 Ffuncall + 1237
35  org.gnu.Emacs                 	0x0014d7bd exec_byte_code + 1693
36  org.gnu.Emacs                 	0x0014d111 Fbyte_code + 65
37  org.gnu.Emacs                 	0x00115a1b eval_sub + 1547
38  org.gnu.Emacs                 	0x001134f2 Feval + 98
39  org.gnu.Emacs                 	0x0010ed95 Fcall_interactively + 677
40  org.gnu.Emacs                 	0x00113bee Ffuncall + 750
41  org.gnu.Emacs                 	0x00116b21 call3 + 49
42  org.gnu.Emacs                 	0x0009eaa0 Fcommand_execute + 560
43  org.gnu.Emacs                 	0x000afe7f command_loop_1 + 2079
44  org.gnu.Emacs                 	0x00117256 internal_condition_case + 230
45  org.gnu.Emacs                 	0x000af645 command_loop_2 + 69
46  org.gnu.Emacs                 	0x0011731f internal_catch + 175
47  org.gnu.Emacs                 	0x000b132c recursive_edit_1 + 284
48  org.gnu.Emacs                 	0x000a1456 Frecursive_edit + 214
49  org.gnu.Emacs                 	0x0009de72 main + 6802
50  org.gnu.Emacs                 	0x00002a15 start + 53

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib        	0x94fa690a kevent + 10
1   libdispatch.dylib             	0x90471c58 _dispatch_mgr_invoke + 969
2   libdispatch.dylib             	0x904706a7 _dispatch_mgr_thread + 53

Thread 2:
0   libsystem_kernel.dylib        	0x94fa602e __workq_kernreturn + 10
1   libsystem_c.dylib             	0x9ad70ccf _pthread_wqthread + 773
2   libsystem_c.dylib             	0x9ad726fe start_wqthread + 30

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x00000000  ebx: 0x00000006  ecx: 0xbfffdcfc  edx: 0x94fa5332
  edi: 0x003e2b70  esi: 0x00000006  ebp: 0xbfffdd18  esp: 0xbfffdcfc
   ss: 0x0000001f  efl: 0x00000286  eip: 0x94fa5332   cs: 0x00000007
   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
  cr2: 0xacd9d738
Logical CPU: 0

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 8
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 1188
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=128.3M resident=41.3M(32%)
swapped_out_or_unallocated=87.0M(68%)
Writable regions: Total=94.5M written=1384K(1%) resident=13.1M(14%)
swapped_out=0K(0%) unallocated=81.4M(86%)

REGION TYPE                      VIRTUAL
===========                      =======
ATS (font support)                 31.8M
ATS (font support) (reserved)         4K reserved VM address space (unallocated)
CG backing stores                  2456K
CG image                             12K
CG raster data                       64K
CG shared images                   3408K
CoreGraphics                          8K
CoreServices                       2040K
MALLOC                             21.6M
MALLOC guard page                    48K
Memory tag=240                        4K
Memory tag=242                       12K
Stack                              65.0M
VM_ALLOCATE                        16.1M
__CI_BITMAP                          80K
__DATA                             26.7M
__DATA/__OBJC                        80K
__IMAGE                            1256K
__IMPORT                              4K
__LINKEDIT                         42.3M
__OBJC                             1412K
__PAGEZERO                            4K
__TEXT                             86.0M
__UNICODE                           544K
mapped file                       152.2M
shared memory                       312K
shared pmap                        10.7M
===========                      =======
TOTAL                             463.7M
TOTAL, minus reserved VM space    463.7M

Re: C-g crash in C-x C-f (OSX Lion)

[chad]

On Dec 12, 2011, at 5:11 AM, Carsten Mattner wrote:

> As previously mentioned Emacs.app reliably crashes for me
> on Lion in trunk builds.

FWIW, I cannot reproduce this on Lion/10.7.2 with bzr head.

*Chad

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

Hello.

I can't reproduce this either.  Can you reproduce this?  Does it happen with -Q?
Can you compile Emacs with debugging enabled and run Emacs in gdb?

	Jan D.

12 dec 2011 kl. 14:11 skrev Carsten Mattner:

> As previously mentioned Emacs.app reliably crashes for me
> on Lion in trunk builds.
> 
> Crash happens if I was waiting in C-x C-f and at some point
> later after having switched away and back to Emacs.app
> decide to cancel the the file open by pressing C-g.
> 
> This time around I saved the OS-provided stacktrace.
> 
> Is this of any use to track down the source?
> 
> Identifier:      org.gnu.Emacs
> Version:         Version 24.0.92 (9.0)
> Code Type:       X86 (Native)
> 
> Date/Time:       2011-12-12 13:58:40.521 +0100
> OS Version:      Mac OS X 10.7.2 (11C74)
> Report Version:  9
> 
> Interval Since Last Report:          2175927 sec
> Crashes Since Last Report:           110
> Per-App Interval Since Last Report:  126761 sec
> Per-App Crashes Since Last Report:   3
> 
> Crashed Thread:  0  Dispatch queue: com.apple.main-thread
> 
> Exception Type:  EXC_BAD_ACCESS (SIGABRT)
> Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000026ce000
> 
> VM Regions Near 0x26ce000:
>    __DATA 0000000001b00000-0000000001c00000 [ 1024K] rw-/rw- SM=COW
>    /Users/USER/*/Emacs.app/Contents/MacOS/Emacs
> --> MALLOC_SMALL 0000000002000000-0000000002706000 [ 7192K] rw-/rwx SM=ZER
> 
>    MALLOC_SMALL 0000000002706000-0000000002721000 [  108K] rw-/rwx SM=PRV
> 
> Application Specific Information:
> objc[47317]: garbage collection is OFF
> abort() called
> 
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   libsystem_kernel.dylib        	0x94fa5332 __kill + 10
> 1   libsystem_kernel.dylib        	0x94fa4932 kill$UNIX2003 + 32
> 2   org.gnu.Emacs                 	0x0009e004 fatal_error_signal + 324
> 3   libsystem_c.dylib             	0x9adc659b _sigtramp + 43
> 4   ???                           	0xffffffff 0 + 4294967295
> 5   libsystem_c.dylib             	0x9ad61bdd abort + 167
> 6   org.gnu.Emacs                 	0x0018433d ns_term_shutdown + 141
> 7   org.gnu.Emacs                 	0x0009bd67 shut_down_emacs + 247
> 8   org.gnu.Emacs                 	0x0009dfce fatal_error_signal + 270
> 9   libsystem_c.dylib             	0x9adc659b _sigtramp + 43
> 10  ???                           	0xffffffff 0 + 4294967295
> 11  org.gnu.Emacs                 	0x000ab8ae read_char + 6174
> 12  org.gnu.Emacs                 	0x000af005 read_key_sequence + 7093
> 13  org.gnu.Emacs                 	0x000b0d7b command_loop_1 + 5915
> 14  org.gnu.Emacs                 	0x00117256 internal_condition_case + 230
> 15  org.gnu.Emacs                 	0x000af645 command_loop_2 + 69
> 16  org.gnu.Emacs                 	0x0011731f internal_catch + 175
> 17  org.gnu.Emacs                 	0x000b1371 recursive_edit_1 + 353
> 18  org.gnu.Emacs                 	0x000cdf4d read_minibuf + 2381
> 19  org.gnu.Emacs                 	0x000cb470 Fread_from_minibuffer + 224
> 20  org.gnu.Emacs                 	0x00113d68 Ffuncall + 1128
> 21  org.gnu.Emacs                 	0x0014d7bd exec_byte_code + 1693
> 22  org.gnu.Emacs                 	0x001164ed funcall_lambda + 349
> 23  org.gnu.Emacs                 	0x00113dd5 Ffuncall + 1237
> 24  org.gnu.Emacs                 	0x000ccfb8 Fcompleting_read + 104
> 25  org.gnu.Emacs                 	0x00113d68 Ffuncall + 1128
> 26  org.gnu.Emacs                 	0x0014d7bd exec_byte_code + 1693
> 27  org.gnu.Emacs                 	0x001164ed funcall_lambda + 349
> 28  org.gnu.Emacs                 	0x00113dd5 Ffuncall + 1237
> 29  org.gnu.Emacs                 	0x0014d7bd exec_byte_code + 1693
> 30  org.gnu.Emacs                 	0x001164ed funcall_lambda + 349
> 31  org.gnu.Emacs                 	0x00113dd5 Ffuncall + 1237
> 32  org.gnu.Emacs                 	0x0014d7bd exec_byte_code + 1693
> 33  org.gnu.Emacs                 	0x001166f6 funcall_lambda + 870
> 34  org.gnu.Emacs                 	0x00113dd5 Ffuncall + 1237
> 35  org.gnu.Emacs                 	0x0014d7bd exec_byte_code + 1693
> 36  org.gnu.Emacs                 	0x0014d111 Fbyte_code + 65
> 37  org.gnu.Emacs                 	0x00115a1b eval_sub + 1547
> 38  org.gnu.Emacs                 	0x001134f2 Feval + 98
> 39  org.gnu.Emacs                 	0x0010ed95 Fcall_interactively + 677
> 40  org.gnu.Emacs                 	0x00113bee Ffuncall + 750
> 41  org.gnu.Emacs                 	0x00116b21 call3 + 49
> 42  org.gnu.Emacs                 	0x0009eaa0 Fcommand_execute + 560
> 43  org.gnu.Emacs                 	0x000afe7f command_loop_1 + 2079
> 44  org.gnu.Emacs                 	0x00117256 internal_condition_case + 230
> 45  org.gnu.Emacs                 	0x000af645 command_loop_2 + 69
> 46  org.gnu.Emacs                 	0x0011731f internal_catch + 175
> 47  org.gnu.Emacs                 	0x000b132c recursive_edit_1 + 284
> 48  org.gnu.Emacs                 	0x000a1456 Frecursive_edit + 214
> 49  org.gnu.Emacs                 	0x0009de72 main + 6802
> 50  org.gnu.Emacs                 	0x00002a15 start + 53
> 
> Thread 1:: Dispatch queue: com.apple.libdispatch-manager
> 0   libsystem_kernel.dylib        	0x94fa690a kevent + 10
> 1   libdispatch.dylib             	0x90471c58 _dispatch_mgr_invoke + 969
> 2   libdispatch.dylib             	0x904706a7 _dispatch_mgr_thread + 53
> 
> Thread 2:
> 0   libsystem_kernel.dylib        	0x94fa602e __workq_kernreturn + 10
> 1   libsystem_c.dylib             	0x9ad70ccf _pthread_wqthread + 773
> 2   libsystem_c.dylib             	0x9ad726fe start_wqthread + 30
> 
> Thread 0 crashed with X86 Thread State (32-bit):
>  eax: 0x00000000  ebx: 0x00000006  ecx: 0xbfffdcfc  edx: 0x94fa5332
>  edi: 0x003e2b70  esi: 0x00000006  ebp: 0xbfffdd18  esp: 0xbfffdcfc
>   ss: 0x0000001f  efl: 0x00000286  eip: 0x94fa5332   cs: 0x00000007
>   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
>  cr2: 0xacd9d738
> Logical CPU: 0
> 
> External Modification Summary:
>  Calls made by other processes targeting this process:
>    task_for_pid: 8
>    thread_create: 0
>    thread_set_state: 0
>  Calls made by this process:
>    task_for_pid: 0
>    thread_create: 0
>    thread_set_state: 0
>  Calls made by all processes on this machine:
>    task_for_pid: 1188
>    thread_create: 0
>    thread_set_state: 0
> 
> VM Region Summary:
> ReadOnly portion of Libraries: Total=128.3M resident=41.3M(32%)
> swapped_out_or_unallocated=87.0M(68%)
> Writable regions: Total=94.5M written=1384K(1%) resident=13.1M(14%)
> swapped_out=0K(0%) unallocated=81.4M(86%)
> 
> REGION TYPE                      VIRTUAL
> ===========                      =======
> ATS (font support)                 31.8M
> ATS (font support) (reserved)         4K reserved VM address space (unallocated)
> CG backing stores                  2456K
> CG image                             12K
> CG raster data                       64K
> CG shared images                   3408K
> CoreGraphics                          8K
> CoreServices                       2040K
> MALLOC                             21.6M
> MALLOC guard page                    48K
> Memory tag=240                        4K
> Memory tag=242                       12K
> Stack                              65.0M
> VM_ALLOCATE                        16.1M
> __CI_BITMAP                          80K
> __DATA                             26.7M
> __DATA/__OBJC                        80K
> __IMAGE                            1256K
> __IMPORT                              4K
> __LINKEDIT                         42.3M
> __OBJC                             1412K
> __PAGEZERO                            4K
> __TEXT                             86.0M
> __UNICODE                           544K
> mapped file                       152.2M
> shared memory                       312K
> shared pmap                        10.7M
> ===========                      =======
> TOTAL                             463.7M
> TOTAL, minus reserved VM space    463.7M

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Wed, Dec 14, 2011 at 9:50 PM, Jan Djärv wrote:
> Hello.
>
> I can't reproduce this either.  Can you reproduce this?  Does it happen with -Q?
> Can you compile Emacs with debugging enabled and run Emacs in gdb?

Quick instructions or link to instructions?
Some undocumented ./configure option?

When I search for it, I only seem to find docs about using
debuggers in emacs, not debugging emacs.

Was the info from the OSX crash handler not useful at all?

Re: C-g crash in C-x C-f (OSX Lion)

[Eli Zaretskii]

> Date: Wed, 14 Dec 2011 22:45:13 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> On Wed, Dec 14, 2011 at 9:50 PM, Jan Djärv wrote:
> > Hello.
> >
> > I can't reproduce this either.  Can you reproduce this?  Does it happen with -Q?
> > Can you compile Emacs with debugging enabled and run Emacs in gdb?
> 
> Quick instructions or link to instructions?
> Some undocumented ./configure option?

Configure with

  CFLAGS='-O0 -ggdb -g3' ./configure --enable-asserts

> When I search for it, I only seem to find docs about using
> debuggers in emacs, not debugging emacs.

See etc/DEBUG.  But I'm not sure this is what you are looking for.
Please elaborate what instructions you need.

> Was the info from the OSX crash handler not useful at all?

It is very hard to relate with the sources, since there's no source
line information there.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Thu, Dec 15, 2011 at 7:08 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 14 Dec 2011 22:45:13 +0100
>> From: Carsten Mattner <carstenmattner@googlemail.com>
>> Cc: Emacs developers <emacs-devel@gnu.org>
>>
>> On Wed, Dec 14, 2011 at 9:50 PM, Jan Djärv wrote:
>> > Hello.
>> >
>> > I can't reproduce this either.  Can you reproduce this?  Does it happen with -Q?
>> > Can you compile Emacs with debugging enabled and run Emacs in gdb?
>>
>> Quick instructions or link to instructions?
>> Some undocumented ./configure option?
>
> Configure with
>
>  CFLAGS='-O0 -ggdb -g3' ./configure --enable-asserts

Thanks, will try to reproduce.

What gdb commands are you interested in me running and
saving the output of for posting to the list?
Any specific Emacs threads I should look at.

>> When I search for it, I only seem to find docs about using
>> debuggers in emacs, not debugging emacs.
>
> See etc/DEBUG.  But I'm not sure this is what you are looking for.
> Please elaborate what instructions you need.

Yeah, something like that with info on how to "decode"/"interpret"
pointers if required.

>> Was the info from the OSX crash handler not useful at all?
>
> It is very hard to relate with the sources, since there's no source
> line information there.

Makes sense.

Re: C-g crash in C-x C-f (OSX Lion)

[Eli Zaretskii]

> Date: Thu, 15 Dec 2011 21:42:05 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: jan.h.d@swipnet.se, emacs-devel@gnu.org
> 
> What gdb commands are you interested in me running and
> saving the output of for posting to the list?

"bt full", for starters.

Also, it sounds like you were in recursive edit when Emacs crashed,
can you describe how you entered the recursive edit?  Your description
of the circumstances under which the crash happens doesn't seem to
account for recursive edit.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Thu, Dec 15, 2011 at 9:47 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 15 Dec 2011 21:42:05 +0100
>> From: Carsten Mattner <carstenmattner@googlemail.com>
>> Cc: jan.h.d@swipnet.se, emacs-devel@gnu.org
>>
>> What gdb commands are you interested in me running and
>> saving the output of for posting to the list?
>
> "bt full", for starters.

Yeah, was thinking to get the call stack.
Let's see if I can reproduce it.

> Also, it sounds like you were in recursive edit when Emacs crashed,
> can you describe how you entered the recursive edit?  Your description
> of the circumstances under which the crash happens doesn't seem to
> account for recursive edit.

I had the mini buffer for C-x C-f open, switched to another application,
did maybe some dir browse with tab completion (no Ido).
Then at some point I decided to cancel with C-g and it seemed to get into
a loop until it crashed. It displayed OSX's multi-colored animated swirl
icon or however it's called these days.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Thu, Dec 15, 2011 at 7:08 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 14 Dec 2011 22:45:13 +0100
>> From: Carsten Mattner <carstenmattner@googlemail.com>
>> Cc: Emacs developers <emacs-devel@gnu.org>
>>
>> On Wed, Dec 14, 2011 at 9:50 PM, Jan Djärv wrote:
>> > Hello.
>> >
>> > I can't reproduce this either.  Can you reproduce this?  Does it happen with -Q?
>> > Can you compile Emacs with debugging enabled and run Emacs in gdb?
>>
>> Quick instructions or link to instructions?
>> Some undocumented ./configure option?
>
> Configure with
>
>  CFLAGS='-O0 -ggdb -g3' ./configure --enable-asserts

Using this line
CFLAGS='-O0 -ggdb -g3' CC='gcc -arch i386' ./configure --with-ns
--without-gnutls --enable-asserts

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Thu, Dec 15, 2011 at 10:24 PM, Carsten Mattner
<carstenmattner@googlemail.com> wrote:
> On Thu, Dec 15, 2011 at 7:08 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> Date: Wed, 14 Dec 2011 22:45:13 +0100
>>> From: Carsten Mattner <carstenmattner@googlemail.com>
>>> Cc: Emacs developers <emacs-devel@gnu.org>
>>>
>>> On Wed, Dec 14, 2011 at 9:50 PM, Jan Djärv wrote:
>>> > Hello.
>>> >
>>> > I can't reproduce this either.  Can you reproduce this?  Does it happen with -Q?
>>> > Can you compile Emacs with debugging enabled and run Emacs in gdb?
>>>
>>> Quick instructions or link to instructions?
>>> Some undocumented ./configure option?
>>
>> Configure with
>>
>>  CFLAGS='-O0 -ggdb -g3' ./configure --enable-asserts
>
> Using this line
> CFLAGS='-O0 -ggdb -g3' CC='gcc -arch i386' ./configure --with-ns
> --without-gnutls --enable-asserts

Haven't been able to reproduce the crash yesterday.
Gonna use Emacs via gdb for the rest of the day.
I hope the crash didn't vanish just due to differences in the generated code.

Re: C-g crash in C-x C-f (OSX Lion)

[Jan D.]

Hello.

Carsten Mattner skrev 2011-12-16 13:46:
> On Thu, Dec 15, 2011 at 10:24 PM, Carsten Mattner
> <carstenmattner@googlemail.com>  wrote:
>>
>> Using this line
>> CFLAGS='-O0 -ggdb -g3' CC='gcc -arch i386' ./configure --with-ns
>> --without-gnutls --enable-asserts
>
> Haven't been able to reproduce the crash yesterday.
> Gonna use Emacs via gdb for the rest of the day.
> I hope the crash didn't vanish just due to differences in the generated code.

This may be the case.  It may be an optimization issue.

Thanks for testing,

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Fri, Dec 16, 2011 at 2:33 PM, Jan D. <jan.h.d@swipnet.se> wrote:
> Hello.
>
> Carsten Mattner skrev 2011-12-16 13:46:
>>
>> On Thu, Dec 15, 2011 at 10:24 PM, Carsten Mattner
>> <carstenmattner@googlemail.com>  wrote:
>>>
>>>
>>> Using this line
>>> CFLAGS='-O0 -ggdb -g3' CC='gcc -arch i386' ./configure --with-ns
>>> --without-gnutls --enable-asserts
>>
>>
>> Haven't been able to reproduce the crash yesterday.
>> Gonna use Emacs via gdb for the rest of the day.
>> I hope the crash didn't vanish just due to differences in the generated
>> code.
>
>
> This may be the case.  It may be an optimization issue.

I hope it's not and I can reproduce it for pinpointing the faulty piece of code.

Re: C-g crash in C-x C-f (OSX Lion)

[Eli Zaretskii]

> Date: Fri, 16 Dec 2011 15:21:54 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> >> I hope the crash didn't vanish just due to differences in the generated
> >> code.
> >
> >
> > This may be the case.  It may be an optimization issue.
> 
> I hope it's not and I can reproduce it for pinpointing the faulty piece of code.

I hope so, too.  But if it turns out you do need an optimized build to
reproduce the problem, reconfigure using

 CFLAGS='-O2 -ggdb -g3' CC='gcc -arch i386' ./configure --with-ns \
     --without-gnutls --enable-asserts

and rebuild.  It will be harder to make sense out of backtrace and
variable values that way, but we may have no choice.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Fri, Dec 16, 2011 at 3:32 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 16 Dec 2011 15:21:54 +0100
>> From: Carsten Mattner <carstenmattner@googlemail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>>
>> >> I hope the crash didn't vanish just due to differences in the generated
>> >> code.
>> >
>> >
>> > This may be the case.  It may be an optimization issue.
>>
>> I hope it's not and I can reproduce it for pinpointing the faulty piece of code.
>
> I hope so, too.  But if it turns out you do need an optimized build to
> reproduce the problem, reconfigure using
>
>  CFLAGS='-O2 -ggdb -g3' CC='gcc -arch i386' ./configure --with-ns \
>     --without-gnutls --enable-asserts
>
> and rebuild.  It will be harder to make sense out of backtrace and
> variable values that way, but we may have no choice.

OK, I made it crash.
I'm not sure what it was exactly but I was about to discard the changes
to a file and pressed kill-buffer (C-x k) and probably C-g to cancel.

Btw, I do use evil-mode because I haven't found the same set of
quick editing bindings with emacs chained bindings. I use a mix
of evil and emacs key bindings.

On a second run I was able to make it crash by just wanting to visually
mark a block to delete in a buffer and press 'd' for delete (evil) or
something else (not sure what I pressed).

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x9adc5d50 in strlen ()
(gdb) bt full#0  0x9adc5d50 in strlen ()
No symbol table info available.
#1  0x001e7601 in intern (str=0x0) at lread.c:3707
        tem = 1178832048
        len = 4363
        obarray = 0
#2  0x00283efb in ns_string_to_symbol (t=0x0) at nsselect.m:86
No locals.
#3  0x002847ab in ns_handle_selection_request (event=0xbfffef88) at
nsselect.m:247
        pb = (id) 0x0
        type = (NSString *) 0xacc4eb98
        selection_name = 48164934
        data = -1701734496
        rest = 2638150
        selection_data = 1811051
        target_symbol = 1585835
        successful_p = 0
#4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
selection_value=39954401) at nsselect.m:425
        ev = {
  kind = SELECTION_REQUEST_EVENT,
  code = 0,
  part = 1771886,
  modifiers = 0,
  x = 0,
  y = -1396380776,
  timestamp = 1,
  padding = {0x4, 0x1a6ba22},
  frame_or_window = 27783754,
  arg = 27703842
}
        pb = (id) 0x0
                                                   [94/960]
        old_value = 27703842
        new_value = 48164926
#5  0x001b025b in Ffuncall (nargs=3, args=0xbffff090) at eval.c:2989
        fun = 4746981
        numargs = 2
        lisp_numargs = 1007840
        val = 27703866
        internal_args = (Lisp_Object *) 0xbffff094
        i = 27703842
        original_fun = 27840882
        funcar = -1073745816
        backtrace = {
  next = 0xbffff3d8,
  function = 0xbffff090,
  args = 0xbffff094,
  nargs = 2,
  debug_on_exit = 0
}
#6  0x0020e3b1 in exec_byte_code (bytestr=3581977, vector=3581997,
maxdepth=20, args_template=27703842, nargs=0, args=0x0) at byte
code.c:785
        count = 4
        vectorp = (Lisp_Object *) 0x36a830
        top = (Lisp_Object *) 0xbffff090
        op = 2
        stack = {
  pc = 0x41bdbf "??T",
  byte_string = 3581977,
  byte_string_start = 0x41bd73 "\b;?\t",
  constants = 3581997,
  next = 0x0
}
        result = 0
#7  0x001b0e01 in funcall_lambda (fun=3581941, nargs=2,
arg_vector=0xbffff440) at eval.c:3217
        val = 2
        lexenv = 27703842
        count = 2
        i = 2
        optional = 0
        rest = 0
        syms_left = 27703842
        next = 27783754
#8  0x001b04a0 in Ffuncall (nargs=3, args=0xbffff43c) at eval.c:3035
        fun = 3581941
        numargs = 2
        lisp_numargs = 39954401
        val = 0
        internal_args = (Lisp_Object *) 0x19c19e
        i = 27784514
        original_fun = 27744138
        funcar = 0
        backtrace = {
  next = 0x0,
  function = 0xbffff43c,
  args = 0xbffff440,
  nargs = 2,
  debug_on_exit = 0
}
#9  0x001af8e4 in call2 (fn=27744138, arg1=27744162, arg2=39954401) at
eval.c:2770
        ret_ungc_val = -1073744792
        gcpro1 = {
  next = 0x2034,
  var = 0x261a7e1,
  nvars = 3
}
        args = {27744138, 27744162, 39954401}
#10 0x000f7a89 in command_loop_1 () at keyboard.c:1659
        beg = 8246
        end = 8244
        keybuf = {28112218, 24, 27785018, 27703842, 0, 0, -1880911564,
-1660254974, 27703842, 28242954, 39515774, 3182981, 1773724
, 39515774, 27703842, 27918518, 39515774, 39515774, 39515774, 2,
-1073744520, 1761123, 2, 39515774, -1073744424, 1760955, 2, 27703
842, 39515774, 39515774}
        i = 1
        prev_modiff = 2127
        cmd = 46658450
        prev_buffer = (struct buffer *) 0x850500
        already_adjusted = 0
#11 0x001ac5d6 in internal_condition_case (bfun=0xf6b70
<command_loop_1>, handlers=27748746, hfun=0xf6180 <cmd_error>) at
eval.c:1
499
        val = 39515774
        c = {
  tag = 27703842,
  val = 27703842,
  next = 0xbffff698,
  gcpro = 0x0,
  jmp = {-1880947841, -1881125920, 8098, 1009472, -1073744360,
-1881125836, 1009296, 1010544, -1073744296, -1073744480, -171897889
6, 21, 1754471, -1697071940, -1073744216, 27746770, -1073744248, -1718978484},
  backlist = 0x0,
  handlerlist = 0x0,
  lisp_eval_depth = 0,
  pdlcount = 2,
  poll_suppress_count = 0,
  interrupt_input_blocked = 0,
  byte_stack = 0x0
}
        h = {
  handler = 27748746,
  var = 27703842,
  chosen_clause = 5126149,
  tag = 0xbffff5c8,
  next = 0x0
}
#12 0x000f66cd in command_loop_2 (ignore=27703842) at keyboard.c:1159
        val = 1009484
#13 0x001abebf in internal_catch (tag=27746770, func=0xf6690
<command_loop_2>, arg=27703842) at eval.c:1256
        c = {
  tag = 27746770,
  val = 27703842,
  next = 0x0,
  gcpro = 0x0,
  jmp = {-1073806465, 1623346, 8098, 1009472, 27739144, 1619675,
1009296, -1073744216, -1073744088, -1073744240, 1622285, 27703842
, 1752752, 4755872, 27739144, 4755872, -1073744104, 27832952},
  backlist = 0x0,
  handlerlist = 0x0,
  lisp_eval_depth = 0,
  pdlcount = 2,
  poll_suppress_count = 0,
  interrupt_input_blocked = 0,
  byte_stack = 0x0
}
#14 0x000f664b in command_loop () at keyboard.c:1138
No locals.
#15 0x000f5b95 in recursive_edit_1 () at keyboard.c:758
        count = 1
        val = 2815621
#16 0x000f5d86 in Frecursive_edit () at keyboard.c:822
        count = 0
        buffer = 27703842
#17 0x000f3b6a in main (argc=1, argv=0xbffff9cc) at emacs.c:1709
        stack_bottom_variable = 0 '\0'
        do_initial_setlocale = 1
        no_loadup = 0
        dummy = 0
        junk = 0x0
        skip_args = 0
        rlim = {
  rlim_cur = 8388608,
  rlim_max = 67104768
}
        dname_arg = 0x0
        dname_arg2 = '\0' <repeats 36 times>,
"-⏬???d???H???w?-?\000\000\000\000U?`???\000\000\000"
        ch_to_dir = 0x0

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Fri, Dec 16, 2011 at 8:00 PM, Carsten Mattner
<carstenmattner@googlemail.com> wrote:
> OK, I made it crash.
> I'm not sure what it was exactly but I was about to discard the changes
> to a file and pressed kill-buffer (C-x k) and probably C-g to cancel.

Should I try without evil-mode loaded?

Maybe I should kept it in gdb for more commands to run on the live
image. Sorry, I will keep the next crash open if you think it's useful.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Fri, Dec 16, 2011 at 8:02 PM, Carsten Mattner
<carstenmattner@googlemail.com> wrote:
> On Fri, Dec 16, 2011 at 8:00 PM, Carsten Mattner
> <carstenmattner@googlemail.com> wrote:
>> OK, I made it crash.
>> I'm not sure what it was exactly but I was about to discard the changes
>> to a file and pressed kill-buffer (C-x k) and probably C-g to cancel.
>
> Should I try without evil-mode loaded?
>
> Maybe I should kept it in gdb for more commands to run on the live
> image. Sorry, I will keep the next crash open if you think it's useful.

Happened again and this time also when I did a visual selection of
text in a buffer.

Eli, any further inspection you want me to do for revealing more info about
the crash?

I was also able to make it crash when started with -nw.
Looks like the same fault:
#0  0x94fa5b42 in select$DARWIN_EXTSN ()
#1  0x002639c2 in ns_select (nfds=5, readfds=0xbfffeda0,
writefds=0xbfffed20, exceptfds=0x0, timeout=0xbfffed00) at
nsterm.m:3493
#2  0x0021b97d in wait_reading_process_output (time_limit=30,
microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=27703842,
wait_proc=0x0, just_wait_proc=0) at process.c:4610
#3  0x000100a5 in sit_for (timeout=120, reading=1, do_display=1) at
dispnew.c:6060
#4  0x000fa2b8 in read_char (commandflag=1, nmaps=12, maps=0xbffff170,
prev_event=27703842, used_mouse_menu=0xbffff33c, end_time=0x0) at
keyboard.c:2688
#5  0x00108b7d in read_key_sequence (keybuf=0xbffff4e8, bufsize=30,
prompt=27703842, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:9300
#6  0x000f707f in command_loop_1 () at keyboard.c:1448
#7  0x001ac5d6 in internal_condition_case (bfun=0xf6b70
<command_loop_1>, handlers=27748746, hfun=0xf6180 <cmd_error>) at
eval.c:1499
#8  0x000f66cd in command_loop_2 (ignore=27703842) at keyboard.c:1159
#9  0x001abebf in internal_catch (tag=27746770, func=0xf6690
<command_loop_2>, arg=27703842) at eval.c:1256
#10 0x000f664b in command_loop () at keyboard.c:1138
#11 0x000f5b95 in recursive_edit_1 () at keyboard.c:758
#12 0x000f5d86 in Frecursive_edit () at keyboard.c:822
#13 0x000f3b6a in main (argc=2, argv=0xbffff9c4) at emacs.c:1709

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Fri, Dec 16, 2011 at 9:11 PM, Carsten Mattner
<carstenmattner@googlemail.com> wrote:
> On Fri, Dec 16, 2011 at 8:02 PM, Carsten Mattner
> <carstenmattner@googlemail.com> wrote:
>> On Fri, Dec 16, 2011 at 8:00 PM, Carsten Mattner
>> <carstenmattner@googlemail.com> wrote:
>>> OK, I made it crash.
>>> I'm not sure what it was exactly but I was about to discard the changes
>>> to a file and pressed kill-buffer (C-x k) and probably C-g to cancel.
>>
>> Should I try without evil-mode loaded?
>>
>> Maybe I should kept it in gdb for more commands to run on the live
>> image. Sorry, I will keep the next crash open if you think it's useful.
>
> Happened again and this time also when I did a visual selection of
> text in a buffer.
>
> Eli, any further inspection you want me to do for revealing more info about
> the crash?
>
> I was also able to make it crash when started with -nw.
> Looks like the same fault:

Sorry, it's not the same backtrace. My fault.
This is the one with the Cocoa frontend:
#0  0x9adc5d50 in strlen ()
#1  0x001e7601 in intern (str=0x0) at lread.c:3707
#2  0x00283efb in ns_string_to_symbol (t=0x0) at nsselect.m:86
#3  0x002847ab in ns_handle_selection_request (event=0xbfffef88) at
nsselect.m:247

vs the below with with the terminal frontend.

Next I will not load evil-mode and see what happens.

> #0  0x94fa5b42 in select$DARWIN_EXTSN ()
> #1  0x002639c2 in ns_select (nfds=5, readfds=0xbfffeda0,
> writefds=0xbfffed20, exceptfds=0x0, timeout=0xbfffed00) at
> nsterm.m:3493
> #2  0x0021b97d in wait_reading_process_output (time_limit=30,
> microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=27703842,
> wait_proc=0x0, just_wait_proc=0) at process.c:4610
> #3  0x000100a5 in sit_for (timeout=120, reading=1, do_display=1) at
> dispnew.c:6060
> #4  0x000fa2b8 in read_char (commandflag=1, nmaps=12, maps=0xbffff170,
> prev_event=27703842, used_mouse_menu=0xbffff33c, end_time=0x0) at
> keyboard.c:2688
> #5  0x00108b7d in read_key_sequence (keybuf=0xbffff4e8, bufsize=30,
> prompt=27703842, dont_downcase_last=0, can_return_switch_frame=1,
> fix_current_buffer=1) at keyboard.c:9300
> #6  0x000f707f in command_loop_1 () at keyboard.c:1448
> #7  0x001ac5d6 in internal_condition_case (bfun=0xf6b70
> <command_loop_1>, handlers=27748746, hfun=0xf6180 <cmd_error>) at
> eval.c:1499
> #8  0x000f66cd in command_loop_2 (ignore=27703842) at keyboard.c:1159
> #9  0x001abebf in internal_catch (tag=27746770, func=0xf6690
> <command_loop_2>, arg=27703842) at eval.c:1256
> #10 0x000f664b in command_loop () at keyboard.c:1138
> #11 0x000f5b95 in recursive_edit_1 () at keyboard.c:758
> #12 0x000f5d86 in Frecursive_edit () at keyboard.c:822
> #13 0x000f3b6a in main (argc=2, argv=0xbffff9c4) at emacs.c:1709

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Fri, Dec 16, 2011 at 9:14 PM, Carsten Mattner
<carstenmattner@googlemail.com> wrote:
> On Fri, Dec 16, 2011 at 9:11 PM, Carsten Mattner
> <carstenmattner@googlemail.com> wrote:
>> On Fri, Dec 16, 2011 at 8:02 PM, Carsten Mattner
>> <carstenmattner@googlemail.com> wrote:
>>> On Fri, Dec 16, 2011 at 8:00 PM, Carsten Mattner
>>> <carstenmattner@googlemail.com> wrote:
>>>> OK, I made it crash.
>>>> I'm not sure what it was exactly but I was about to discard the changes
>>>> to a file and pressed kill-buffer (C-x k) and probably C-g to cancel.
>>>
>>> Should I try without evil-mode loaded?
>>>
>>> Maybe I should kept it in gdb for more commands to run on the live
>>> image. Sorry, I will keep the next crash open if you think it's useful.
>>
>> Happened again and this time also when I did a visual selection of
>> text in a buffer.
>>
>> Eli, any further inspection you want me to do for revealing more info about
>> the crash?
>>
>> I was also able to make it crash when started with -nw.
>> Looks like the same fault:
>
> Sorry, it's not the same backtrace. My fault.
> This is the one with the Cocoa frontend:
> #0  0x9adc5d50 in strlen ()
> #1  0x001e7601 in intern (str=0x0) at lread.c:3707
> #2  0x00283efb in ns_string_to_symbol (t=0x0) at nsselect.m:86
> #3  0x002847ab in ns_handle_selection_request (event=0xbfffef88) at
> nsselect.m:247
>
> vs the below with with the terminal frontend.
>
> Next I will not load evil-mode and see what happens.

Can these crashes happen due to enabled assertions?
Doesn't look like that to me, but with evil-mode not loaded I
was able to make it crash by pressing
C-S-> and then C-S-b (was trying to remember the Emacs editing
binding equivalent of { in evil-mode.

#0  0x9adc5d50 in strlen ()
#1  0x001e7601 in intern (str=0x0) at lread.c:3707
#2  0x00283efb in ns_string_to_symbol (t=0x0) at nsselect.m:86
#3  0x002847ab in ns_handle_selection_request (event=0xbfffef88) at
nsselect.m:247
#4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
selection_value=47468977) at nsselect.m:425
#5  0x001b025b in Ffuncall (nargs=3, args=0xbffff090) at eval.c:2989
#6  0x0020e3b1 in exec_byte_code (bytestr=3581977, vector=3581997,
maxdepth=20, args_template=27703842, nargs=0, args=0x0) at
bytecode.c:785
#7  0x001b0e01 in funcall_lambda (fun=3581941, nargs=2,
arg_vector=0xbffff440) at eval.c:3217
#8  0x001b04a0 in Ffuncall (nargs=3, args=0xbffff43c) at eval.c:3035
#9  0x001af8e4 in call2 (fn=27744138, arg1=27744162, arg2=47468977) at
eval.c:2770
#10 0x000f7a89 in command_loop_1 () at keyboard.c:1659
#11 0x001ac5d6 in internal_condition_case (bfun=0xf6b70
<command_loop_1>, handlers=27748746, hfun=0xf6180 <cmd_error>) at
eval.c:1499
#12 0x000f66cd in command_loop_2 (ignore=27703842) at keyboard.c:1159
#13 0x001abebf in internal_catch (tag=27746770, func=0xf6690
<command_loop_2>, arg=27703842) at eval.c:1256
#14 0x000f664b in command_loop () at keyboard.c:1138
#15 0x000f5b95 in recursive_edit_1 () at keyboard.c:758
#16 0x000f5d86 in Frecursive_edit () at keyboard.c:822
#17 0x000f3b6a in main (argc=1, argv=0xbffff9cc) at emacs.c:1709

....

(gdb) bt full#0  0x9adc5d50 in strlen ()
No symbol table info available.
#1  0x001e7601 in intern (str=0x0) at lread.c:3707
        tem = 1178832048
        len = 4363
        obarray = 0
#2  0x00283efb in ns_string_to_symbol (t=0x0) at nsselect.m:86
No locals.
#3  0x002847ab in ns_handle_selection_request (event=0xbfffef88) at
nsselect.m:247
        pb = (id) 0x0
        type = (NSString *) 0xacc4eb98
        selection_name = 47582326

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Fri, Dec 16, 2011 at 9:19 PM, Carsten Mattner
<carstenmattner@googlemail.com> wrote:
> Can these crashes happen due to enabled assertions?
> Doesn't look like that to me, but with evil-mode not loaded I
> was able to make it crash by pressing
> C-S-> and then C-S-b (was trying to remember the Emacs editing

Actually it was M-S-> and M-S-b

Re: C-g crash in C-x C-f (OSX Lion)

[Eli Zaretskii]

> Date: Fri, 16 Dec 2011 21:21:30 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: emacs-devel@gnu.org
> 
> On Fri, Dec 16, 2011 at 9:19 PM, Carsten Mattner
> <carstenmattner@googlemail.com> wrote:
> > Can these crashes happen due to enabled assertions?
> > Doesn't look like that to me, but with evil-mode not loaded I
> > was able to make it crash by pressing
> > C-S-> and then C-S-b (was trying to remember the Emacs editing
> 
> Actually it was M-S-> and M-S-b

What is M-S-b? what command does it run?

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Fri, Dec 16, 2011 at 10:12 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 16 Dec 2011 21:21:30 +0100
>> From: Carsten Mattner <carstenmattner@googlemail.com>
>> Cc: emacs-devel@gnu.org
>>
>> On Fri, Dec 16, 2011 at 9:19 PM, Carsten Mattner
>> <carstenmattner@googlemail.com> wrote:
>> > Can these crashes happen due to enabled assertions?
>> > Doesn't look like that to me, but with evil-mode not loaded I
>> > was able to make it crash by pressing
>> > C-S-> and then C-S-b (was trying to remember the Emacs editing
>>
>> Actually it was M-S-> and M-S-b
>
> What is M-S-b? what command does it run?

I guess it's unbound. After disabling evil-mode I was guessing what
default Emacs binding is the equivalent of evil-mode's command mode {
to navigate back (up) to next blank line. Please ignore that.

Re: C-g crash in C-x C-f (OSX Lion)

[Eli Zaretskii]

> Date: Fri, 16 Dec 2011 21:19:19 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: emacs-devel@gnu.org
> 
> > #0  0x9adc5d50 in strlen ()
> > #1  0x001e7601 in intern (str=0x0) at lread.c:3707
> > #2  0x00283efb in ns_string_to_symbol (t=0x0) at nsselect.m:86
> > #3  0x002847ab in ns_handle_selection_request (event=0xbfffef88) at
> > nsselect.m:247
> >
> > vs the below with with the terminal frontend.
> >
> > Next I will not load evil-mode and see what happens.
> 
> Can these crashes happen due to enabled assertions?

No.  Emacs crashes because it tries to compute the length of a string
specified by a NULL pointer.  It looks like this happens due to a
selection request, but when that request is handled, Emacs tries to
intern a name that is a NULL string.

I don't know enough about the NS build and the code in nsselect.m to
reason why this could happen.  In particular, I don't understand this
portion of the code:

  static void
  ns_handle_selection_request (struct input_event *event)
  {
    // FIXME: BIG UGLY HACK!!!
    id pb = (id)*(EMACS_INT*)&(event->x);
    ...
    selection_name = ns_string_to_symbol ([(NSPasteboard *)pb name]);

How come the x coordinate of an event could be passed to
ns_string_to_symbol as a string, no matter how it is type-cast??

This certainly isn't related to enabled assertions.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Fri, Dec 16, 2011 at 10:11 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 16 Dec 2011 21:19:19 +0100
>> From: Carsten Mattner <carstenmattner@googlemail.com>
>> Cc: emacs-devel@gnu.org
>>
>> > #0  0x9adc5d50 in strlen ()
>> > #1  0x001e7601 in intern (str=0x0) at lread.c:3707
>> > #2  0x00283efb in ns_string_to_symbol (t=0x0) at nsselect.m:86
>> > #3  0x002847ab in ns_handle_selection_request (event=0xbfffef88) at
>> > nsselect.m:247
>> >
>> > vs the below with with the terminal frontend.
>> >
>> > Next I will not load evil-mode and see what happens.
>>
>> Can these crashes happen due to enabled assertions?
>
> No.  Emacs crashes because it tries to compute the length of a string
> specified by a NULL pointer.  It looks like this happens due to a
> selection request, but when that request is handled, Emacs tries to
> intern a name that is a NULL string.

What about the other crash which happened when I ran it as
emacs -nw?

> I don't know enough about the NS build and the code in nsselect.m to
> reason why this could happen.  In particular, I don't understand this
> portion of the code:
>
>  static void
>  ns_handle_selection_request (struct input_event *event)
>  {
>    // FIXME: BIG UGLY HACK!!!
>    id pb = (id)*(EMACS_INT*)&(event->x);
>    ...
>    selection_name = ns_string_to_symbol ([(NSPasteboard *)pb name]);
>
> How come the x coordinate of an event could be passed to
> ns_string_to_symbol as a string, no matter how it is type-cast??
>
> This certainly isn't related to enabled assertions.

I also didn't think so, but it's a foreign codebase and it's C, so
better ask than assume.

Re: C-g crash in C-x C-f (OSX Lion)

[Eli Zaretskii]

> Date: Fri, 16 Dec 2011 22:22:54 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: emacs-devel@gnu.org
> 
> > No.  Emacs crashes because it tries to compute the length of a string
> > specified by a NULL pointer.  It looks like this happens due to a
> > selection request, but when that request is handled, Emacs tries to
> > intern a name that is a NULL string.
> 
> What about the other crash which happened when I ran it as
> emacs -nw?

Let's take it one crash at a time.

Re: C-g crash in C-x C-f (OSX Lion)

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> How come the x coordinate of an event could be passed to
> ns_string_to_symbol as a string, no matter how it is type-cast??

Because Fx_own_selection_internal put it there.

(Get your barf bag ready!)

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: C-g crash in C-x C-f (OSX Lion)

[Stephen J. Turnbull]

Andreas Schwab writes:
 > Eli Zaretskii <eliz@gnu.org> writes:
 > 
 > > How come the x coordinate of an event could be passed to
 > > ns_string_to_symbol as a string, no matter how it is type-cast??
 > 
 > Because Fx_own_selection_internal put it there.
 > 
 > (Get your barf bag ready!)

Wow, at last a *whole two lines* from Andreas!

(It was worth the wait for that comment though!  ROTFL!)

Re: C-g crash in C-x C-f (OSX Lion)

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Andreas Schwab writes:
>  > Because Fx_own_selection_internal put it there.
>  > 
>  > (Get your barf bag ready!)
>
> Wow, at last a *whole two lines* from Andreas!

Nah... the two lines put together are less than 80 characters.

Re: C-g crash in C-x C-f (OSX Lion)

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Carsten Mattner <carstenmattner@googlemail.com>,  emacs-devel@gnu.org
> Date: Fri, 16 Dec 2011 22:24:26 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How come the x coordinate of an event could be passed to
> > ns_string_to_symbol as a string, no matter how it is type-cast??
> 
> Because Fx_own_selection_internal put it there.
> 
> (Get your barf bag ready!)

Thanks for the heads-up, I needed that bag.

So the question now is why that string comes out as NULL.  This
happens in this code in x-own-selection-internal:

  pb =[NSPasteboard pasteboardWithName: symbol_to_nsstring (selection_name)];

and the value of pb gets later put into the event's x member:

  /* XXX An evil hack, but a necessary one I fear XXX */
  {
    struct input_event ev;
    ev.kind = SELECTION_REQUEST_EVENT;
    ev.modifiers = 0;
    ev.code = 0;
    *(EMACS_INT*)(&(ev.x)) = (EMACS_INT)pb; // FIXME: BIG UGLY HACK!!
    *(EMACS_INT*)(&(ev.y)) = (EMACS_INT)NSStringPboardType;
    ns_handle_selection_request (&ev);
  }

Now, this part of the backtrace:

  #4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
  selection_value=39954401) at nsselect.m:425
	  ev = {
	    kind = SELECTION_REQUEST_EVENT,
	    code = 0,
	    part = 1771886,
	    modifiers = 0,
	    x = 0,
	    y = -1396380776,
	    timestamp = 1,
	    padding = {0x4, 0x1a6ba22},
	    frame_or_window = 27783754,
	    arg = 27703842
	  }
	  pb = (id) 0x0

indicates that pb comes out as NULL and gets put into ev.x as zero.
So the question is: what is selection_name, whose value is 27744162,
and which caused symbol_to_nsstring to return NULL?

Carsten, if you still have the crashed session, please go to the stack
frame showing the call to Fx_own_selection_internal (in the above
case, this is frame #4), by typing "frame N" at the GDB prompt (where
N is the number of the frame), and then type these commands:

  (gdb) p selection_name
  (gdb) xtype

I expect the last command to say "Lisp_Symbol", in which case please
type

  (gdb) xsymbol

to show what symbol is that.

If the crashed session is no longer available, make it crash as soon
as possible and then do the above.

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

17 dec 2011 kl. 09:32 skrev Eli Zaretskii:

> Now, this part of the backtrace:
> 
>  #4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
>  selection_value=39954401) at nsselect.m:425
> 	  ev = {
> 	    kind = SELECTION_REQUEST_EVENT,
> 	    code = 0,
> 	    part = 1771886,
> 	    modifiers = 0,
> 	    x = 0,
> 	    y = -1396380776,
> 	    timestamp = 1,
> 	    padding = {0x4, 0x1a6ba22},
> 	    frame_or_window = 27783754,
> 	    arg = 27703842
> 	  }
> 	  pb = (id) 0x0
> 
> indicates that pb comes out as NULL and gets put into ev.x as zero.
> So the question is: what is selection_name, whose value is 27744162,
> and which caused symbol_to_nsstring to return NULL?

My guess is that symbol_to_nsstring does not return NULL, but 
NSPasteboard pasteboardWithName: does.

NSPasteboard knows only of a few specific pasteboards ("General", "Selection", "Secondary", etc.) so if isn't one of those, it returns NULL.
I think selection_name is a symbol, but not the ones the NS-port map to pasteboard names, i.e. not one of PRIMARY, SECONDARY or CLIPBOARD.

It would be great to find out what it is though.

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sat, 17 Dec 2011 10:46:31 +0100
> Cc: Andreas Schwab <schwab@linux-m68k.org>,
>  carstenmattner@googlemail.com,
>  emacs-devel@gnu.org
> 
> 
> 17 dec 2011 kl. 09:32 skrev Eli Zaretskii:
> 
> > Now, this part of the backtrace:
> > 
> >  #4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
> >  selection_value=39954401) at nsselect.m:425
> > 	  ev = {
> > 	    kind = SELECTION_REQUEST_EVENT,
> > 	    code = 0,
> > 	    part = 1771886,
> > 	    modifiers = 0,
> > 	    x = 0,
> > 	    y = -1396380776,
> > 	    timestamp = 1,
> > 	    padding = {0x4, 0x1a6ba22},
> > 	    frame_or_window = 27783754,
> > 	    arg = 27703842
> > 	  }
> > 	  pb = (id) 0x0
> > 
> > indicates that pb comes out as NULL and gets put into ev.x as zero.
> > So the question is: what is selection_name, whose value is 27744162,
> > and which caused symbol_to_nsstring to return NULL?
> 
> My guess is that symbol_to_nsstring does not return NULL, but 
> NSPasteboard pasteboardWithName: does.
> 
> NSPasteboard knows only of a few specific pasteboards ("General", "Selection", "Secondary", etc.) so if isn't one of those, it returns NULL.

I'm way out of my league here, since I don't really know Objective C,
but isn't this code in symbol_to_nsstring:

  if (EQ (sym, QCLIPBOARD))     return NSGeneralPboard;
  if (EQ (sym, QPRIMARY))     return NXPrimaryPboard;
  if (EQ (sym, QSECONDARY))   return NXSecondaryPboard;
  if (EQ (sym, QTEXT))        return NSStringPboardType;
  return [NSString stringWithUTF8String: SDATA (XSYMBOL (sym)->xname)];

return _something_ that is not NULL even if the symbol is not one of
the 4 explicitly mentioned?

> I think selection_name is a symbol, but not the ones the NS-port map to pasteboard names, i.e. not one of PRIMARY, SECONDARY or CLIPBOARD.
> 
> It would be great to find out what it is though.

Agreed.

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

17 dec 2011 kl. 13:03 skrev Eli Zaretskii:

>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Sat, 17 Dec 2011 10:46:31 +0100
>> Cc: Andreas Schwab <schwab@linux-m68k.org>,
>> carstenmattner@googlemail.com,
>> emacs-devel@gnu.org
>> 
>> 
>> 17 dec 2011 kl. 09:32 skrev Eli Zaretskii:
>> 
>>> Now, this part of the backtrace:
>>> 
>>> #4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
>>> selection_value=39954401) at nsselect.m:425
>>> 	  ev = {
>>> 	    kind = SELECTION_REQUEST_EVENT,
>>> 	    code = 0,
>>> 	    part = 1771886,
>>> 	    modifiers = 0,
>>> 	    x = 0,
>>> 	    y = -1396380776,
>>> 	    timestamp = 1,
>>> 	    padding = {0x4, 0x1a6ba22},
>>> 	    frame_or_window = 27783754,
>>> 	    arg = 27703842
>>> 	  }
>>> 	  pb = (id) 0x0
>>> 
>>> indicates that pb comes out as NULL and gets put into ev.x as zero.
>>> So the question is: what is selection_name, whose value is 27744162,
>>> and which caused symbol_to_nsstring to return NULL?
>> 
>> My guess is that symbol_to_nsstring does not return NULL, but 
>> NSPasteboard pasteboardWithName: does.
>> 
>> NSPasteboard knows only of a few specific pasteboards ("General", "Selection", "Secondary", etc.) so if isn't one of those, it returns NULL.
> 
> I'm way out of my league here, since I don't really know Objective C,
> but isn't this code in symbol_to_nsstring:
> 
>  if (EQ (sym, QCLIPBOARD))     return NSGeneralPboard;
>  if (EQ (sym, QPRIMARY))     return NXPrimaryPboard;
>  if (EQ (sym, QSECONDARY))   return NXSecondaryPboard;
>  if (EQ (sym, QTEXT))        return NSStringPboardType;
>  return [NSString stringWithUTF8String: SDATA (XSYMBOL (sym)->xname)];
> 
> return _something_ that is not NULL even if the symbol is not one of
> the 4 explicitly mentioned?

Yes, but that something is then passed to NSPasteboard pasteboardWithName.  It is that function that returns NULL.
I.e. if symbol_to_nsstring returns NSStringPboardType or whatever the last line returns.

But the point is that for selection purposes only the first three should be possible. Also, the NS-code should not crash, but just ignore the bad selection type.

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Sat, Dec 17, 2011 at 9:32 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: Carsten Mattner <carstenmattner@googlemail.com>,  emacs-devel@gnu.org
>> Date: Fri, 16 Dec 2011 22:24:26 +0100
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > How come the x coordinate of an event could be passed to
>> > ns_string_to_symbol as a string, no matter how it is type-cast??
>>
>> Because Fx_own_selection_internal put it there.
>>
>> (Get your barf bag ready!)
>
> Thanks for the heads-up, I needed that bag.
>
> So the question now is why that string comes out as NULL.  This
> happens in this code in x-own-selection-internal:
>
>  pb =[NSPasteboard pasteboardWithName: symbol_to_nsstring (selection_name)];
>
> and the value of pb gets later put into the event's x member:
>
>  /* XXX An evil hack, but a necessary one I fear XXX */
>  {
>    struct input_event ev;
>    ev.kind = SELECTION_REQUEST_EVENT;
>    ev.modifiers = 0;
>    ev.code = 0;
>    *(EMACS_INT*)(&(ev.x)) = (EMACS_INT)pb; // FIXME: BIG UGLY HACK!!
>    *(EMACS_INT*)(&(ev.y)) = (EMACS_INT)NSStringPboardType;
>    ns_handle_selection_request (&ev);
>  }
>
> Now, this part of the backtrace:
>
>  #4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
>  selection_value=39954401) at nsselect.m:425
>          ev = {
>            kind = SELECTION_REQUEST_EVENT,
>            code = 0,
>            part = 1771886,
>            modifiers = 0,
>            x = 0,
>            y = -1396380776,
>            timestamp = 1,
>            padding = {0x4, 0x1a6ba22},
>            frame_or_window = 27783754,
>            arg = 27703842
>          }
>          pb = (id) 0x0
>
> indicates that pb comes out as NULL and gets put into ev.x as zero.
> So the question is: what is selection_name, whose value is 27744162,
> and which caused symbol_to_nsstring to return NULL?
>
> Carsten, if you still have the crashed session, please go to the stack
> frame showing the call to Fx_own_selection_internal (in the above
> case, this is frame #4), by typing "frame N" at the GDB prompt (where
> N is the number of the frame), and then type these commands:
>
>  (gdb) p selection_name
>  (gdb) xtype
>
> I expect the last command to say "Lisp_Symbol", in which case please
> type
>
>  (gdb) xsymbol
>
> to show what symbol is that.
>
> If the crashed session is no longer available, make it crash as soon
> as possible and then do the above.

New session same #4 for that call
(gdb) frame 4
#4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
selection_value=78814449) at nsselect.m:425
425         ns_handle_selection_request (&ev);
Current language:  auto; currently objective-c
(gdb) p selection_name
$1 = 27744162
(gdb) xtype
Undefined command: "xtype".  Try "help".
(gdb) xsymbol
Undefined command: "xsymbol".  Try "help".
(gdb)

Could gdb be too old for xsymbol/xtype commands? Are those aliases?
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Mon Aug  8 20:32:45 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.

Apple prefers lldb and I have that ready and also could build
lldb from svn trunk if there's a reason to do so.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Sat, Dec 17, 2011 at 4:39 PM, Carsten Mattner
<carstenmattner@googlemail.com> wrote:
> On Sat, Dec 17, 2011 at 9:32 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Andreas Schwab <schwab@linux-m68k.org>
>>> Cc: Carsten Mattner <carstenmattner@googlemail.com>,  emacs-devel@gnu.org
>>> Date: Fri, 16 Dec 2011 22:24:26 +0100
>>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>> > How come the x coordinate of an event could be passed to
>>> > ns_string_to_symbol as a string, no matter how it is type-cast??
>>>
>>> Because Fx_own_selection_internal put it there.
>>>
>>> (Get your barf bag ready!)
>>
>> Thanks for the heads-up, I needed that bag.
>>
>> So the question now is why that string comes out as NULL.  This
>> happens in this code in x-own-selection-internal:
>>
>>  pb =[NSPasteboard pasteboardWithName: symbol_to_nsstring (selection_name)];
>>
>> and the value of pb gets later put into the event's x member:
>>
>>  /* XXX An evil hack, but a necessary one I fear XXX */
>>  {
>>    struct input_event ev;
>>    ev.kind = SELECTION_REQUEST_EVENT;
>>    ev.modifiers = 0;
>>    ev.code = 0;
>>    *(EMACS_INT*)(&(ev.x)) = (EMACS_INT)pb; // FIXME: BIG UGLY HACK!!
>>    *(EMACS_INT*)(&(ev.y)) = (EMACS_INT)NSStringPboardType;
>>    ns_handle_selection_request (&ev);
>>  }
>>
>> Now, this part of the backtrace:
>>
>>  #4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
>>  selection_value=39954401) at nsselect.m:425
>>          ev = {
>>            kind = SELECTION_REQUEST_EVENT,
>>            code = 0,
>>            part = 1771886,
>>            modifiers = 0,
>>            x = 0,
>>            y = -1396380776,
>>            timestamp = 1,
>>            padding = {0x4, 0x1a6ba22},
>>            frame_or_window = 27783754,
>>            arg = 27703842
>>          }
>>          pb = (id) 0x0
>>
>> indicates that pb comes out as NULL and gets put into ev.x as zero.
>> So the question is: what is selection_name, whose value is 27744162,
>> and which caused symbol_to_nsstring to return NULL?
>>
>> Carsten, if you still have the crashed session, please go to the stack
>> frame showing the call to Fx_own_selection_internal (in the above
>> case, this is frame #4), by typing "frame N" at the GDB prompt (where
>> N is the number of the frame), and then type these commands:
>>
>>  (gdb) p selection_name
>>  (gdb) xtype
>>
>> I expect the last command to say "Lisp_Symbol", in which case please
>> type
>>
>>  (gdb) xsymbol
>>
>> to show what symbol is that.
>>
>> If the crashed session is no longer available, make it crash as soon
>> as possible and then do the above.
>
> New session same #4 for that call
> (gdb) frame 4
> #4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
> selection_value=78814449) at nsselect.m:425
> 425         ns_handle_selection_request (&ev);
> Current language:  auto; currently objective-c
> (gdb) p selection_name
> $1 = 27744162
> (gdb) xtype
> Undefined command: "xtype".  Try "help".
> (gdb) xsymbol
> Undefined command: "xsymbol".  Try "help".
> (gdb)
>
> Could gdb be too old for xsymbol/xtype commands? Are those aliases?
> GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Mon Aug  8 20:32:45 UTC 2011)
> Copyright 2004 Free Software Foundation, Inc.
>
> Apple prefers lldb and I have that ready and also could build
> lldb from svn trunk if there's a reason to do so.

This is with Xcode's lldb:
Process 486 stopped
* thread #1: tid = 0x1f07, 0x9adc5d50 libsystem_c.dylib`strlen + 16,
stop reason = EXC_BAD_ACCESS (code=2, address=0x0)
    frame #0: 0x9adc5d50 libsystem_c.dylib`strlen + 16
(lldb) bt
* thread #1: tid = 0x1f07, 0x9adc5d50 libsystem_c.dylib`strlen + 16,
stop reason = EXC_BAD_ACCESS (code=2, address=0x0)
    frame #0: 0x9adc5d50 libsystem_c.dylib`strlen + 16
    frame #1: 0x001e7601 Emacs`intern + 33 at lread.c:3707
    frame #2: 0x00283efb Emacs`ns_string_to_symbol + 459 at nsselect.m:86
    frame #3: 0x002847ab Emacs`ns_handle_selection_request + 75 at
nsselect.m:247
    frame #4: 0x00285202 Emacs`Fx_own_selection_internal + 370 at nsselect.m:425
    frame #5: 0x001b025b Emacs`Ffuncall + 1147 at eval.c:2989
    frame #6: 0x0020e3b1 Emacs`exec_byte_code + 3329 at bytecode.c:785
    frame #7: 0x001b0e01 Emacs`funcall_lambda + 1185 at eval.c:3217
    frame #8: 0x001b04a0 Emacs`Ffuncall + 1728 at eval.c:3035
    frame #9: 0x001af8e4 Emacs`call2 + 68 at eval.c:2770
    frame #10: 0x000f7a33 Emacs`command_loop_1 + 3779 at keyboard.c:1656
    frame #11: 0x001ac5d6 Emacs`internal_condition_case + 294 at eval.c:1499
    frame #12: 0x000f66cd Emacs`command_loop_2 + 61 at keyboard.c:1159
    frame #13: 0x001abebf Emacs`internal_catch + 223 at eval.c:1256
    frame #14: 0x000f664b Emacs`command_loop + 203 at keyboard.c:1138
    frame #15: 0x000f5b95 Emacs`recursive_edit_1 + 181 at keyboard.c:758
    frame #16: 0x000f5d86 Emacs`Frecursive_edit + 326 at keyboard.c:822
    frame #17: 0x000f3b6a Emacs`main + 6442 at emacs.c:1709
(lldb) frame 4
invalid command 'frame 4'
(lldb) frame
Available completions:
        info
        select
        variable
(lldb) frame select 4
frame #4: 0x00285202 Emacs`Fx_own_selection_internal + 370 at nsselect.m:425
   422      ev.code = 0;
   423      *(EMACS_INT*)(&(ev.x)) = (EMACS_INT)pb; // FIXME: BIG UGLY HACK!!
   424      *(EMACS_INT*)(&(ev.y)) = (EMACS_INT)NSStringPboardType;
-> 425      ns_handle_selection_request (&ev);
   426    }
   427    return selection_value;
   428  }
(lldb) p selection_name
(Lisp_Object) $0 = 27744162
(lldb)

Re: C-g crash in C-x C-f (OSX Lion)

[Eli Zaretskii]

> Date: Sat, 17 Dec 2011 16:39:24 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> (gdb) frame 4
> #4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
> selection_value=78814449) at nsselect.m:425
> 425         ns_handle_selection_request (&ev);
> Current language:  auto; currently objective-c
> (gdb) p selection_name
> $1 = 27744162
> (gdb) xtype
> Undefined command: "xtype".  Try "help".

You didn't start GDB from the src/ directory.  Type this to remedy:

  (gdb) source /path/to/src/.gdbinit

Then retry the above.

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

Hello.

17 dec 2011 kl. 16:39 skrev Carsten Mattner:

> 
> New session same #4 for that call
> (gdb) frame 4
> #4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
> selection_value=78814449) at nsselect.m:425
> 425         ns_handle_selection_request (&ev);
> Current language:  auto; currently objective-c
> (gdb) p selection_name
> $1 = 27744162
> (gdb) xtype
> Undefined command: "xtype".  Try "help".
> (gdb) xsymbol
> Undefined command: "xsymbol".  Try "help".
> (gdb)
> 
> Could gdb be too old for xsymbol/xtype commands? Are those aliases?

They are commands from .gdbinit in Emacs src directory.  You should start gdb when standing in that directory, or source that file into gdb.  That is, when gdb is started:

(gdb) source <path to emacs sources>/src/.gdbinit


> GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Mon Aug  8 20:32:45 UTC 2011)
> Copyright 2004 Free Software Foundation, Inc.
> 
> Apple prefers lldb and I have that ready and also could build
> lldb from svn trunk if there's a reason to do so.

I don't think lldb understands Emacs .gdbinit, so there is no reason to use it.  I think it yses Python as a scripting language (yech ...).

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Sat, Dec 17, 2011 at 5:09 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello.
>
> 17 dec 2011 kl. 16:39 skrev Carsten Mattner:
>
>>
>> New session same #4 for that call
>> (gdb) frame 4
>> #4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
>> selection_value=78814449) at nsselect.m:425
>> 425         ns_handle_selection_request (&ev);
>> Current language:  auto; currently objective-c
>> (gdb) p selection_name
>> $1 = 27744162
>> (gdb) xtype
>> Undefined command: "xtype".  Try "help".
>> (gdb) xsymbol
>> Undefined command: "xsymbol".  Try "help".
>> (gdb)
>>
>> Could gdb be too old for xsymbol/xtype commands? Are those aliases?
>
> They are commands from .gdbinit in Emacs src directory.  You should start gdb when standing in that directory, or source that file into gdb.  That is, when gdb is started:
>
> (gdb) source <path to emacs sources>/src/.gdbinit

Oops, sorry, forgot to follow etc/DEBUG

(gdb) bt
#0  0x9adc5d50 in strlen ()
#1  0x001e7601 in intern (str=0x0) at lread.c:3707
#2  0x00283efb in ns_string_to_symbol (t=0x0) at nsselect.m:86
#3  0x002847ab in ns_handle_selection_request (event=0xbfffef78) at
nsselect.m:247
#4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
selection_value=39064129) at nsselect.m:425
#5  0x001b025b in Ffuncall (nargs=3, args=0xbffff080) at eval.c:2989
#6  0x0020e3b1 in exec_byte_code (bytestr=3581977, vector=3581997,
maxdepth=20, args_template=27703842, nargs=0, args=0x0) at
bytecode.c:785
#7  0x001b0e01 in funcall_lambda (fun=3581941, nargs=2,
arg_vector=0xbffff430) at eval.c:3217
#8  0x001b04a0 in Ffuncall (nargs=3, args=0xbffff42c) at eval.c:3035
#9  0x001af8e4 in call2 (fn=27744138, arg1=27744162, arg2=39064129) at
eval.c:2770
#10 0x000f7a33 in command_loop_1 () at keyboard.c:1656
#11 0x001ac5d6 in internal_condition_case (bfun=0xf6b70
<command_loop_1>, handlers=27748746, hfun=0xf6180 <cmd_error>) at
eval.c:1499
#12 0x000f66cd in command_loop_2 (ignore=27703842) at keyboard.c:1159
#13 0x001abebf in internal_catch (tag=27746770, func=0xf6690
<command_loop_2>, arg=27703842) at eval.c:1256
#14 0x000f664b in command_loop () at keyboard.c:1138
#15 0x000f5b95 in recursive_edit_1 () at keyboard.c:758
#16 0x000f5d86 in Frecursive_edit () at keyboard.c:822
#17 0x000f3b6a in main (argc=1, argv=0xbffff9c0) at emacs.c:1709

Lisp Backtrace:
"x-own-selection-internal" (0xbffff084)
"x-set-selection" (0xbffff430)
(gdb) frame 4
#4  0x00285202 in Fx_own_selection_internal (selection_name=27744162,
selection_value=39064129) at nsselect.m:425
425         ns_handle_selection_request (&ev);
Current language:  auto; currently objective-c
(gdb) p selection_name
$1 = 27744162
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$2 = (struct Lisp_Symbol *) 0x1a757a0
"PRIMARY"
(gdb)

I didn't run src/emacs but the application bundle for the Cocoa app to
properly load and display an interactive window and not just one which
doesn't accept input events from keyboard/mouse.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

The gdb session is still open if there's anything else you want me
to inspect/run.

I can keep it open for 2-3 hours before I need to leave and stop
the machine.

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

Hello.

17 dec 2011 kl. 17:47 skrev Carsten Mattner:

> The gdb session is still open if there's anything else you want me
> to inspect/run.
> 
> I can keep it open for 2-3 hours before I need to leave and stop
> the machine.

What does this say:

(gdb) p QPRIMARY
(gdb) xtype
(gdb) xsymbol

?

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Sat, Dec 17, 2011 at 6:15 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello.
>
> 17 dec 2011 kl. 17:47 skrev Carsten Mattner:
>
>> The gdb session is still open if there's anything else you want me
>> to inspect/run.
>>
>> I can keep it open for 2-3 hours before I need to leave and stop
>> the machine.
>
> What does this say:
>
> (gdb) p QPRIMARY
> (gdb) xtype
> (gdb) xsymbol
>
> ?

(gdb) p QPRIMARY
$3 = 27744162
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$4 = (struct Lisp_Symbol *) 0x1a757a0
"PRIMARY"
(gdb)

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

17 dec 2011 kl. 18:19 skrev Carsten Mattner:

> On Sat, Dec 17, 2011 at 6:15 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> Hello.
>> 
>> 17 dec 2011 kl. 17:47 skrev Carsten Mattner:
>> 
>>> The gdb session is still open if there's anything else you want me
>>> to inspect/run.
>>> 
>>> I can keep it open for 2-3 hours before I need to leave and stop
>>> the machine.
>> 
>> What does this say:
>> 
>> (gdb) p QPRIMARY
>> (gdb) xtype
>> (gdb) xsymbol
>> 
>> ?
> 
> (gdb) p QPRIMARY
> $3 = 27744162
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $4 = (struct Lisp_Symbol *) 0x1a757a0
> "PRIMARY"
> (gdb)

This is really wierd.  

Try

(gdb) p NXPrimaryPboard

and if it doesn't print 0:

(gdb) po NXPrimaryPboard

I don't quite understand what is going on here, but I'm inclined to fix the code as it should be and check it in.  I think Eli was correct, the pb = 0 is the error.

I have read up on pasteboardWithName and it should not return NULL on an unknown string.  It may return NULL if the string argument is NULL.  That kind of assumes symbol_to_nsstring returns NULL as Eli suggested.  Under -nw, I guess x-open-connection is not called so NXPrimaryPboard never gets initialized.  But you said this was a graphical session or did I misunderstand that?

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Sat, Dec 17, 2011 at 6:46 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
> 17 dec 2011 kl. 18:19 skrev Carsten Mattner:
>
>> On Sat, Dec 17, 2011 at 6:15 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>> Hello.
>>>
>>> 17 dec 2011 kl. 17:47 skrev Carsten Mattner:
>>>
>>>> The gdb session is still open if there's anything else you want me
>>>> to inspect/run.
>>>>
>>>> I can keep it open for 2-3 hours before I need to leave and stop
>>>> the machine.
>>>
>>> What does this say:
>>>
>>> (gdb) p QPRIMARY
>>> (gdb) xtype
>>> (gdb) xsymbol
>>>
>>> ?
>>
>> (gdb) p QPRIMARY
>> $3 = 27744162
>> (gdb) xtype
>> Lisp_Symbol
>> (gdb) xsymbol
>> $4 = (struct Lisp_Symbol *) 0x1a757a0
>> "PRIMARY"
>> (gdb)
>
> This is really wierd.
>
> Try
>
> (gdb) p NXPrimaryPboard
>
> and if it doesn't print 0:
>
> (gdb) po NXPrimaryPboard

(gdb) p NXPrimaryPboard
$5 = (NSString *) 0x488cb0
(gdb) po NXPrimaryPboard
Selection
(gdb)

> I don't quite understand what is going on here, but I'm inclined
> to fix the code as it should be and check it in.  I think Eli was correct,
> the pb = 0 is the error.

Thanks for looking into it.

> I have read up on pasteboardWithName and it should not return
> NULL on an unknown string.  It may return NULL if the string argument
> is NULL.  That kind of assumes symbol_to_nsstring returns NULL as
> Eli suggested.  Under -nw, I guess x-open-connection is not called so
> NXPrimaryPboard never gets initialized.  But you said this was a
> graphical session or did I misunderstand that?

Yes, the --with-ns Cocoa graphical session.
There's another thread I was able to trigger when run in a terminal
via -nw.

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

Hello.

17 dec 2011 kl. 19:06 skrev Carsten Mattner:

> (gdb) p NXPrimaryPboard
> $5 = (NSString *) 0x488cb0
> (gdb) po NXPrimaryPboard
> Selection
> (gdb)
> 

So much for that theory.  I do not understand what is happening, unless there is some stack smashing going on, which seems unlikely.  I will look this over, thanks for debugging.

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Sat, Dec 17, 2011 at 7:18 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello.
>
> 17 dec 2011 kl. 19:06 skrev Carsten Mattner:
>
>> (gdb) p NXPrimaryPboard
>> $5 = (NSString *) 0x488cb0
>> (gdb) po NXPrimaryPboard
>> Selection
>> (gdb)
>>
>
> So much for that theory.  I do not understand what is happening,
> unless there is some stack smashing going on, which seems unlikely.
> I will look this over, thanks for debugging.

Thanks!

Keep in mind that if you load and enable evil-mode this is easily
triggered, but seems harder to trigger when selecting without.

Re: C-g crash in C-x C-f (OSX Lion)

[Stephen J. Turnbull]

Jan Djärv writes:

 > I think [llbd] yses Python as a scripting language (yech ...).

Tastes differ, but I think you are nuts if you prefer gdb command
language scripting to Python!

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Mon, Dec 19, 2011 at 9:40 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Jan Djärv writes:
>
>  > I think [llbd] yses Python as a scripting language (yech ...).
>
> Tastes differ, but I think you are nuts if you prefer gdb command
> language scripting to Python!

Yes, but from a simplicity and size perspective Lua (even though I
don't like it and wouldn't recommend it) would be better choice.
From a use-case point of view I'm sure that Guile or another LISP
variant would be a more ideal fit.

Re: C-g crash in C-x C-f (OSX Lion)

[Eli Zaretskii]

> Date: Mon, 19 Dec 2011 11:59:40 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: Jan Djärv <jan.h.d@swipnet.se>,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> > Tastes differ, but I think you are nuts if you prefer gdb command
> > language scripting to Python!
> 
> Yes, but from a simplicity and size perspective Lua (even though I
> don't like it and wouldn't recommend it) would be better choice.

Funny you should mention this.  See the discussion that started here:

   http://sourceware.org/ml/gdb/2007-02/msg00065.html

I surely hope you were part of that discussion!

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Mon, Dec 19, 2011 at 12:20 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 19 Dec 2011 11:59:40 +0100
>> From: Carsten Mattner <carstenmattner@googlemail.com>
>> Cc: Jan Djärv <jan.h.d@swipnet.se>,
>>       Emacs developers <emacs-devel@gnu.org>
>>
>> > Tastes differ, but I think you are nuts if you prefer gdb command
>> > language scripting to Python!
>>
>> Yes, but from a simplicity and size perspective Lua (even though I
>> don't like it and wouldn't recommend it) would be better choice.
>
> Funny you should mention this.  See the discussion that started here:
>
>   http://sourceware.org/ml/gdb/2007-02/msg00065.html
>
> I surely hope you were part of that discussion!

I wasn't but haven't the Cygnus guys added Python support
in recent versions? At least I believe to have seen something
from Red Hat. My reason for suggesting Guile or LISPs in general
is that working with source code and "trees" may be an ideal fit.
If you take Python, yes going with Lua is a simpler and lighter
choice.

Anyway, today's Guile as blogged about by one of its developers
seems to be designed as Gnu's Lua as an extension language
lika JS is in web browsers.

if python then take_instead(lua)
else take_instead(guile)

Oh and it seems both major Lua implementations are
pretty battle-tested in major games which translates to
being run on millions machines every day to considerable
extent. In that sense Lua may be more production-ready.

Re: C-g crash in C-x C-f (OSX Lion)

[Eli Zaretskii]

> Date: Mon, 19 Dec 2011 12:51:02 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: emacs-devel@gnu.org
> 
> I wasn't but haven't the Cygnus guys added Python support
> in recent versions?

Yes, GDB comes with Python scripting in the last few releases.  That's
what that discussion was about to begin with.

Re: C-g crash in C-x C-f (OSX Lion)

[Stephen J. Turnbull]

Carsten Mattner writes:
 > On Mon, Dec 19, 2011 at 9:40 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
 > > Jan Djärv writes:
 > >
 > >  > I think [llbd] yses Python as a scripting language (yech ...).
 > >
 > > Tastes differ, but I think you are nuts if you prefer gdb command
 > > language scripting to Python!
 > 
 > Yes, but from a simplicity and size perspective Lua (even though I
 > don't like it and wouldn't recommend it) would be better choice.
 > >From a use-case point of view I'm sure that Guile or another LISP
 > variant would be a more ideal fit.

Eh?  You really think people who program only in C/C++/Java/FORTRAN
would really prefer a Lispy scripting language?  People who use Emacs
don't really count, as they (mostly) shouldn't need to care, they
should just use gdb (or gud) mode.

Anyway, my question is not "which idealized scripting language do you
think should be used for an imaginary debugger's command language?"
It's "which real debugger's actual scripting language do you prefer?"

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

Hello.

16 dec 2011 kl. 22:24 skrev Andreas Schwab:

> Eli Zaretskii <eliz@gnu.org> writes:
> 
>> How come the x coordinate of an event could be passed to
>> ns_string_to_symbol as a string, no matter how it is type-cast??
> 
> Because Fx_own_selection_internal put it there.
> 
> (Get your barf bag ready!)
> 

It only puts it there so the static function ns_handle_selection_request can extract it.  But ns_handle_selection_request is only called from Fx_own_selection_internal, so why this hack?  It is not needed.  There is also dead code in nsselect.m.  We need to clean this up.

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Fri, Dec 16, 2011 at 10:11 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 16 Dec 2011 21:19:19 +0100
>> From: Carsten Mattner <carstenmattner@googlemail.com>
>> Cc: emacs-devel@gnu.org
>>
>> > #0  0x9adc5d50 in strlen ()
>> > #1  0x001e7601 in intern (str=0x0) at lread.c:3707
>> > #2  0x00283efb in ns_string_to_symbol (t=0x0) at nsselect.m:86
>> > #3  0x002847ab in ns_handle_selection_request (event=0xbfffef88) at
>> > nsselect.m:247
>> >
>> > vs the below with with the terminal frontend.
>> >
>> > Next I will not load evil-mode and see what happens.
>>
>> Can these crashes happen due to enabled assertions?
>
> No.  Emacs crashes because it tries to compute the length of a string
> specified by a NULL pointer.  It looks like this happens due to a
> selection request, but when that request is handled, Emacs tries to
> intern a name that is a NULL string.

For the record, I'm not sure this is the original crash I reported
that happened in the mini-buffer.

If I enable evil-mode I can reliably make it crash by pressing
v and then navigating with say } and making a selection.

Re: C-g crash in C-x C-f (OSX Lion)

[Eli Zaretskii]

> Date: Fri, 16 Dec 2011 22:49:49 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: emacs-devel@gnu.org
> 
> On Fri, Dec 16, 2011 at 10:11 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Fri, 16 Dec 2011 21:19:19 +0100
> >> From: Carsten Mattner <carstenmattner@googlemail.com>
> >> Cc: emacs-devel@gnu.org
> >>
> >> > #0  0x9adc5d50 in strlen ()
> >> > #1  0x001e7601 in intern (str=0x0) at lread.c:3707
> >> > #2  0x00283efb in ns_string_to_symbol (t=0x0) at nsselect.m:86
> >> > #3  0x002847ab in ns_handle_selection_request (event=0xbfffef88) at
> >> > nsselect.m:247
> >> >
> >> > vs the below with with the terminal frontend.
> >> >
> >> > Next I will not load evil-mode and see what happens.
> >>
> >> Can these crashes happen due to enabled assertions?
> >
> > No.  Emacs crashes because it tries to compute the length of a string
> > specified by a NULL pointer.  It looks like this happens due to a
> > selection request, but when that request is handled, Emacs tries to
> > intern a name that is a NULL string.
> 
> For the record, I'm not sure this is the original crash I reported
> that happened in the mini-buffer.
> 
> If I enable evil-mode I can reliably make it crash by pressing
> v and then navigating with say } and making a selection.

Since the crash seems to be related to a selection request coming from
outside Emacs, it can happen in any circumstances where you make a
selection or do something that causes Emacs to put text into primary
selection.

So I think these crashes _are_ manifestation of the same problem.

Re: C-g crash in C-x C-f (OSX Lion)

[Paul Eggert]

On 12/16/11 13:11, Eli Zaretskii wrote:
> I don't know enough about the NS build and the code in nsselect.m to
> reason why this could happen.

A few weeks ago I looked into doing static checking for the
NS build and found so many errors that I ran away.  Some of
the errors may have been false alarms, but the first couple that
I looked at seemed real.  The NS build needs a lot of work
(by someone who knows what they're doing) before it'd be
anything I'd want my daughter to use, if I had a daughter.

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

Hello.

17 dec 2011 kl. 01:22 skrev Paul Eggert:

> On 12/16/11 13:11, Eli Zaretskii wrote:
>> I don't know enough about the NS build and the code in nsselect.m to
>> reason why this could happen.
> 
> A few weeks ago I looked into doing static checking for the
> NS build and found so many errors that I ran away.  Some of
> the errors may have been false alarms, but the first couple that
> I looked at seemed real.  The NS build needs a lot of work
> (by someone who knows what they're doing) before it'd be
> anything I'd want my daughter to use, if I had a daughter.

It is a mess.  It seems some code was done by someone not familiar with objective-C.  Global variables are used instead of putting them in a class for instance.

Did you use gcc for the static checking?  Which options?

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Adrian Robert]

Jan Djärv <jan.h.d <at> swipnet.se> writes:

>  The NS build needs a lot of work
> > (by someone who knows what they're doing) before it'd be
> > anything I'd want my daughter to use, if I had a daughter.
> 
> It is a mess.  It seems some code was done by someone not
> familiar with objective-C.
> Global variables are used
> instead of putting them in a class for instance.


This kind of thing is the result of walking a line between
keeping code similar to other terms that don't interface to OO
GUIs, and doing what's natural from OO perspective.  And a long
accretive development thrown on top of that.  Improvements can
surely be made, though I'm not sure if they relate to the more
stringent checking of inputs from the rest of emacs code that
would fix the current issue.

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

17 dec 2011 kl. 18:30 skrev Adrian Robert:

> Jan Djärv <jan.h.d <at> swipnet.se> writes:
> 
>> The NS build needs a lot of work
>>> (by someone who knows what they're doing) before it'd be
>>> anything I'd want my daughter to use, if I had a daughter.
>> 
>> It is a mess.  It seems some code was done by someone not
>> familiar with objective-C.
>> Global variables are used
>> instead of putting them in a class for instance.
> 
> 
> This kind of thing is the result of walking a line between
> keeping code similar to other terms that don't interface to OO
> GUIs, and doing what's natural from OO perspective.  And a long
> accretive development thrown on top of that.

The long development time is the main cause I think.
It is hard to not have these kinds of problems after a while.

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Paul Eggert]

On 12/17/11 01:14, Jan Djärv wrote:
> Did you use gcc for the static checking?  Which options?

Yes, I used gcc.  Here are the options I typically use
for Emacs on Fedora 15.  I also use -isystem
rather than -I for system include directories.
I have a modified configure.in that enables all this
with --enable-gcc-warnings (this is the typical 'configure' option
for other GNU packages).  I'm planning to add this 'configure'
option to Emacs at some point, so that others can do this sort
of checking if they want to.

-std=gnu99
-Wall
-W
-Wformat-y2k
-Wformat-security
-Winit-self
-Wmissing-include-dirs
-Wunused
-Wunknown-pragmas
-Wstrict-aliasing
-Wdeclaration-after-statement
-Wunsafe-loop-optimizations
-Wpointer-arith
-Wbad-function-cast
-Wcast-align
-Wwrite-strings
-Wlogical-op
-Wstrict-prototypes
-Wold-style-definition
-Wmissing-prototypes
-Wmissing-declarations
-Wmissing-noreturn
-Wmissing-format-attribute
-Wpacked
-Wunreachable-code
-Winvalid-pch
-Wvolatile-register-var
-Wdisabled-optimization
-Wstack-protector
-Wbuiltin-macro-redefined
-Wmudflap
-Wpacked-bitfield-compat
-Wsync-nand
-Wattributes
-Wcoverage-mismatch
-Wmultichar
-Wunused-macros
-Wno-missing-field-initializers
-Wno-missing-field-initializers
-Wno-sign-compare
-Wno-type-limits
-Wno-switch
-Wno-unused-parameter
-Werror

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

Hello.

I get a lot of "will never be executed" for the macro SELECTED_FRAME:

#define SELECTED_FRAME()				\
     ((FRAMEP (selected_frame)				\
       && FRAME_LIVE_P (XFRAME (selected_frame)))	\
      ? XFRAME (selected_frame)				\
      : (abort (), (struct frame *) 0))

I guess it is the (struct frame *)0 that never will be executed?
How do you deal with these warnings?

	Jan D.

17 dec 2011 kl. 19:19 skrev Paul Eggert:

> On 12/17/11 01:14, Jan Djärv wrote:
>> Did you use gcc for the static checking?  Which options?
> 
> Yes, I used gcc.  Here are the options I typically use
> for Emacs on Fedora 15.  I also use -isystem
> rather than -I for system include directories.
> I have a modified configure.in that enables all this
> with --enable-gcc-warnings (this is the typical 'configure' option
> for other GNU packages).  I'm planning to add this 'configure'
> option to Emacs at some point, so that others can do this sort
> of checking if they want to.
> 
> -std=gnu99
> -Wall
> -W
> -Wformat-y2k
> -Wformat-security
> -Winit-self
> -Wmissing-include-dirs
> -Wunused
> -Wunknown-pragmas
> -Wstrict-aliasing
> -Wdeclaration-after-statement
> -Wunsafe-loop-optimizations
> -Wpointer-arith
> -Wbad-function-cast
> -Wcast-align
> -Wwrite-strings
> -Wlogical-op
> -Wstrict-prototypes
> -Wold-style-definition
> -Wmissing-prototypes
> -Wmissing-declarations
> -Wmissing-noreturn
> -Wmissing-format-attribute
> -Wpacked
> -Wunreachable-code
> -Winvalid-pch
> -Wvolatile-register-var
> -Wdisabled-optimization
> -Wstack-protector
> -Wbuiltin-macro-redefined
> -Wmudflap
> -Wpacked-bitfield-compat
> -Wsync-nand
> -Wattributes
> -Wcoverage-mismatch
> -Wmultichar
> -Wunused-macros
> -Wno-missing-field-initializers
> -Wno-missing-field-initializers
> -Wno-sign-compare
> -Wno-type-limits
> -Wno-switch
> -Wno-unused-parameter
> -Werror

Re: C-g crash in C-x C-f (OSX Lion)

[Paul Eggert]

On 12/19/11 10:18, Jan Djärv wrote:
> I get a lot of "will never be executed" for the macro SELECTED_FRAME:

I don't observe this problem on Fedora 15 with GCC 4.6.2,
when Emacs (trunk bzr 106703) is configured with "configure --with-ns".

It could be Fedora, but possibly it's because you're using
an older version of GCC.  The flags I gave you are for GCC 4.6.2
or later; older GCCs will sometimes screw up and issue bogus warnings.
I suggest trying again with GCC 4.6.2 (or even GCC 4.7) if you
aren't already doing that.

Another possibility is to tune the flags for an older GCC,
but typically older GCCs don't do as good a job of static
checking even when the compiler flags are tuned for them.

Re: C-g crash in C-x C-f (OSX Lion)

[René Kyllingstad]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

On Sat, Dec 17, 2011 at 01:22, Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 12/16/11 13:11, Eli Zaretskii wrote:
> > I don't know enough about the NS build and the code in nsselect.m to
> > reason why this could happen.
>
> A few weeks ago I looked into doing static checking for the
> NS build and found so many errors that I ran away.  Some of
> the errors may have been false alarms, but the first couple that
> I looked at seemed real.  The NS build needs a lot of work
> (by someone who knows what they're doing) before it'd be
> anything I'd want my daughter to use, if I had a daughter.
>

You could of course check in the Mac port, and just forget the NS port ever
happened :)


-- René

[-- Attachment #2: Type: text/html, Size: 1046 bytes --]

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

2011/12/19 René Kyllingstad <Rene@kyllingstad.com>:
> On Sat, Dec 17, 2011 at 01:22, Paul Eggert <eggert@cs.ucla.edu> wrote:
>>
>> On 12/16/11 13:11, Eli Zaretskii wrote:
>> > I don't know enough about the NS build and the code in nsselect.m to
>> > reason why this could happen.
>>
>> A few weeks ago I looked into doing static checking for the
>> NS build and found so many errors that I ran away.  Some of
>> the errors may have been false alarms, but the first couple that
>> I looked at seemed real.  The NS build needs a lot of work
>> (by someone who knows what they're doing) before it'd be
>> anything I'd want my daughter to use, if I had a daughter.
>
>
> You could of course check in the Mac port, and just forget the NS port ever
> happened :)

Care to explain? I have no idea what the difference is.
Is it a Cocoa only and therefore no-Gnustep frontend?

What's holding up adding it at least as an additional frontend if
it's that much better and presumably tested?

Re: C-g crash in C-x C-f (OSX Lion)

[Jan D.]

Carsten Mattner skrev 2011-12-19 12:00:
> 2011/12/19 René Kyllingstad<Rene@kyllingstad.com>:
>> On Sat, Dec 17, 2011 at 01:22, Paul Eggert<eggert@cs.ucla.edu>  wrote:
>>>
>>> On 12/16/11 13:11, Eli Zaretskii wrote:
>>>> I don't know enough about the NS build and the code in nsselect.m to
>>>> reason why this could happen.
>>>
>>> A few weeks ago I looked into doing static checking for the
>>> NS build and found so many errors that I ran away.  Some of
>>> the errors may have been false alarms, but the first couple that
>>> I looked at seemed real.  The NS build needs a lot of work
>>> (by someone who knows what they're doing) before it'd be
>>> anything I'd want my daughter to use, if I had a daughter.
>>
>>
>> You could of course check in the Mac port, and just forget the NS port ever
>> happened :)
>
> Care to explain? I have no idea what the difference is.
> Is it a Cocoa only and therefore no-Gnustep frontend?
>
> What's holding up adding it at least as an additional frontend if
> it's that much better and presumably tested?

AFAIK, the Mac port uses Carbon, and is based om Emacs 23, i.e. no Emacs 
24 features (like multitty).

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Mon, Dec 19, 2011 at 4:53 PM, Jan D. <jan.h.d@swipnet.se> wrote:
> Carsten Mattner skrev 2011-12-19 12:00:
>
>> 2011/12/19 René Kyllingstad<Rene@kyllingstad.com>:
>>>
>>> On Sat, Dec 17, 2011 at 01:22, Paul Eggert<eggert@cs.ucla.edu>  wrote:
>>>>
>>>>
>>>> On 12/16/11 13:11, Eli Zaretskii wrote:
>>>>>
>>>>> I don't know enough about the NS build and the code in nsselect.m to
>>>>> reason why this could happen.
>>>>
>>>>
>>>> A few weeks ago I looked into doing static checking for the
>>>> NS build and found so many errors that I ran away.  Some of
>>>> the errors may have been false alarms, but the first couple that
>>>> I looked at seemed real.  The NS build needs a lot of work
>>>> (by someone who knows what they're doing) before it'd be
>>>> anything I'd want my daughter to use, if I had a daughter.
>>>
>>>
>>>
>>> You could of course check in the Mac port, and just forget the NS port
>>> ever
>>> happened :)
>>
>>
>> Care to explain? I have no idea what the difference is.
>> Is it a Cocoa only and therefore no-Gnustep frontend?
>>
>> What's holding up adding it at least as an additional frontend if
>> it's that much better and presumably tested?
>
>
> AFAIK, the Mac port uses Carbon, and is based om Emacs 23, i.e. no Emacs 24
> features (like multitty).

Sounds like the Mac port should be obsolete and deprecated as
Carbon is deprecated and I'm not even sure it's in Lion anymore.

Re: C-g crash in C-x C-f (OSX Lion)

[chad]

On Dec 19, 2011, at 8:52 AM, Carsten Mattner wrote:

> Sounds like the Mac port should be obsolete and deprecated as
> Carbon is deprecated and I'm not even sure it's in Lion anymore.

Carbon support is included in Lion as a legacy thing; you can't build or create Carbon apps in Lion using the currently supported tools.  You can work around that by coercing the old development tools into the current OS, but the resulting binaries don't meet Apple's guidelines (which are relevant because it spells out clearly the intentions for Carbon).

Hope that helps,
*Chad

Re: C-g crash in C-x C-f (OSX Lion)

[René Kyllingstad]

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

On Mon, Dec 19, 2011 at 17:52, Carsten Mattner <
carstenmattner@googlemail.com> wrote:

> On Mon, Dec 19, 2011 at 4:53 PM, Jan D. <jan.h.d@swipnet.se> wrote:
> > AFAIK, the Mac port uses Carbon, and is based om Emacs 23, i.e. no Emacs
> 24
> > features (like multitty).
>
> Sounds like the Mac port should be obsolete and deprecated as
> Carbon is deprecated and I'm not even sure it's in Lion anymore.
>

This is alas a common misunderstanding about the Mac port.

http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg00424.html
http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg00499.html

The Mac port hasn't been integrated because none of the maintainers are
particularly interested nor knowledgeable about the mac platform, and the
author of the port has not pushed for it.

So instead of a rock solid port where the author knows _exactly_ why every
line of code is the way it is, we have a crashy mess nobody wants to spend
any time on. Yay.


-- René, happy user of the Mac port on Lion (though I spend most of my
Emacs time on GNU/Linux)

[-- Attachment #2: Type: text/html, Size: 1741 bytes --]

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

2011/12/19 René Kyllingstad <Rene@kyllingstad.com>:
> On Mon, Dec 19, 2011 at 17:52, Carsten Mattner
> <carstenmattner@googlemail.com> wrote:
>>
>> On Mon, Dec 19, 2011 at 4:53 PM, Jan D. <jan.h.d@swipnet.se> wrote:
>> > AFAIK, the Mac port uses Carbon, and is based om Emacs 23, i.e. no Emacs
>> > 24
>> > features (like multitty).
>>
>> Sounds like the Mac port should be obsolete and deprecated as
>> Carbon is deprecated and I'm not even sure it's in Lion anymore.
>
>
> This is alas a common misunderstanding about the Mac port.
>
> http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg00424.html
> http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg00499.html

Hmm, what about M-x ns-popup-font-panel and friends?
It's not like this cannot be made to work.

--with-ns priority should be OSX and Gnustep as 2nd tier I believe so that
OSX has a good graphical frontend.

> The Mac port hasn't been integrated because none of the maintainers are
> particularly interested nor knowledgeable about the mac platform, and the
> author of the port has not pushed for it.
>
> So instead of a rock solid port where the author knows _exactly_ why every
> line of code is the way it is, we have a crashy mess nobody wants to spend
> any time on. Yay.

Not sure. No matter how you look at it, Carbon is deprecated and a
bad choice for inclusion.

--with-ns seems to use Cocoa and is therefore the better choice
down the road from what I can gather.

Having said that, if I was able to make all key bindings work in the terminal,
I would most probably ignore graphical frontends and use -nw only.
I use bitmap fonts because they look clean and sharp, but that may be
matter of personal preference. Any remedy so that I can ditch gui frontends
and therefore save even more memory as a side effect?

Re: C-g crash in C-x C-f (OSX Lion)

[Dan Nicolaescu]

René Kyllingstad <Rene@Kyllingstad.com> writes:

> On Mon, Dec 19, 2011 at 17:52, Carsten Mattner <carstenmattner@googlemail.com>
> wrote:
>
>     On Mon, Dec 19, 2011 at 4:53 PM, Jan D. <jan.h.d@swipnet.se> wrote:
>     > AFAIK, the Mac port uses Carbon, and is based om Emacs 23, i.e. no Emacs
>     24
>     > features (like multitty).
>
>     Sounds like the Mac port should be obsolete and deprecated as
>     Carbon is deprecated and I'm not even sure it's in Lion anymore.
>
>
> This is alas a common misunderstanding about the Mac port.
>
> http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg00424.html
> http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg00499.html
>
> The Mac port hasn't been integrated because none of the maintainers are
> particularly interested nor knowledgeable about the mac platform, and the
> author of the port has not pushed for it.
>
> So instead of a rock solid port where the author knows _exactly_ why every line
> of code is the way it is, we have a crashy mess nobody wants to spend any time
> on. Yay.

That's kind of far from reality.
See: http://lists.gnu.org/archive/html/emacs-devel/2009-09/msg00199.html
and similar things has been stated by the maintainers a few times on
this list.  

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

2011/12/19 Dan Nicolaescu <dann@gnu.org>:
> René Kyllingstad <Rene@Kyllingstad.com> writes:
>
>> On Mon, Dec 19, 2011 at 17:52, Carsten Mattner <carstenmattner@googlemail.com>
>> wrote:
>>
>>     On Mon, Dec 19, 2011 at 4:53 PM, Jan D. <jan.h.d@swipnet.se> wrote:
>>     > AFAIK, the Mac port uses Carbon, and is based om Emacs 23, i.e. no Emacs
>>     24
>>     > features (like multitty).
>>
>>     Sounds like the Mac port should be obsolete and deprecated as
>>     Carbon is deprecated and I'm not even sure it's in Lion anymore.
>>
>>
>> This is alas a common misunderstanding about the Mac port.
>>
>> http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg00424.html
>> http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg00499.html
>>
>> The Mac port hasn't been integrated because none of the maintainers are
>> particularly interested nor knowledgeable about the mac platform, and the
>> author of the port has not pushed for it.
>>
>> So instead of a rock solid port where the author knows _exactly_ why every line
>> of code is the way it is, we have a crashy mess nobody wants to spend any time
>> on. Yay.
>
> That's kind of far from reality.
> See: http://lists.gnu.org/archive/html/emacs-devel/2009-09/msg00199.html
> and similar things has been stated by the maintainers a few times on
> this list.

For the record, how does Aquamacs compare?
Is it a fork not trying to re-integrate with way more changes than is
healty and acceptable while keeping emacs emacs and not mutating
it into TextEdit.app with elisp support?

Re: C-g crash in C-x C-f (OSX Lion)

[chad]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]


On Dec 19, 2011, at 2:29 PM, Carsten Mattner wrote:
> 
> For the record, how does Aquamacs compare?
> Is it a fork not trying to re-integrate with way more changes than is
> healty and acceptable while keeping emacs emacs and not mutating
> it into TextEdit.app with elisp support?

Aquamacs is a customization port of GNU Emacs. There is a decent back-and-forth dialog between the two, largely because the main aquamacs developer is a frequent contributor to this list.

I personally have some hope that once themes and packages are more solidly implemented in GNU emacs, Aquamacs can stop maintaining its own emacs code-base in favor of distributing GNU emacs with aquamacs packages pre-installed and configured.

Aquamacs is pretty strongly focused on the gui experience in macosx, so I don't know if it would be very useful to you and your minimalist desires, but it's certainly worth checking out if you have some free time.

*Chad

[-- Attachment #2: Type: text/html, Size: 1290 bytes --]

Re: C-g crash in C-x C-f (OSX Lion)

[chad]

[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]


On Dec 19, 2011, at 9:25 AM, René Kyllingstad wrote:

> 
> This is alas a common misunderstanding about the Mac port.
> 
> http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg00424.html

As Dan mentioned, these messages from 4 years ago don't paint a very accurate current picture.  Adding to the discussion he linked, I'll say that the current situation is even worse than the 2007 messages imply; in Lion (aka macosx 10.7), the current development tools won't build a gui Carbon app, and the situation is only getting worse.  The low-level functionality continues to work in a sort of zombie legacy model, but it seems clear that the situation will only deteriorate over time.

Meanwhile, the Mac port is missing multi-tty, bidi editing, gnutls, and lexbind.  It doesn't have integrated themes, packages, Org, or CEDET (to name just a few).  It doesn't help GNUstep users at all. If xembed catches on, it's unlikely that it'll ever reach the Mac port.  

I think it's great that you have a version of Emacs that you like and that works for you.  Everyone jumps off the development train at some point, and just uses tools that work for them -- I'll hazard that this is even more common among Emacs-on-macosx users (speaking for myself, emacs is more or less the only train that I'm still `on').  I tried out the Mac port for a little while, and it seemed great as a usable emacs.

What it's not, though, is a developing, growing emacs. While my emacs needs are pretty modest lately, I find the Mac port is missing too many things that I've come to expect from the leading edge.  That doesn't make it a bad emacs, but it does mean that it is (clearly, IMHO) not the emacs for everyone.  This periodic assertion by happy Mac port users that some one/group is being silly/stupid/stubborn by not simply adopting the Mac port as the One True emacs ignores the desires of those of us who use the development head of GNU emacs directly in an effort to improve emacs itself (a group that I'll assert is a majority of the people reading emacs-devel).  

The Mac port is great, but it's only great if you don't mind this (IMO colossal) caveat:

On Nov 28, 2011, at 2:45 AM, YAMAMOTO Mitsuharu wrote:

> * A few users asked me about the status/plans of the Mac port based
>    on Emacs 24.  Currently I don't have any development branches for
>    that.

Hope that helps,
*Chad




[-- Attachment #2: Type: text/html, Size: 4223 bytes --]

Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 19 Dec 2011 16:03:52 -0800, chad <yandros@gmail.com> said:

>> This is alas a common misunderstanding about the Mac port.
>> 
>> http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg00424.html

> As Dan mentioned, these messages from 4 years ago don't paint a very
> accurate current picture.  Adding to the discussion he linked, I'll
> say that the current situation is even worse than the 2007 messages
> imply; in Lion (aka macosx 10.7), the current development tools
> won't build a gui Carbon app, and the situation is only getting
> worse.  The low-level functionality continues to work in a sort of
> zombie legacy model, but it seems clear that the situation will only
> deteriorate over time.

The Mac port doesn't use Carbon for GUI.  On the contrary, it uses
Cocoa AppKit for GUI implementation (otherwise it doesn't work as a
64-bit executable).

I'd like to ask the same question as in

  http://lists.gnu.org/archive/html/emacs-devel/2010-11/msg00552.html

Which is in your mind when you speak "low-level functionality in
Carbon", C APIs in general or the Carbon framework (i.e.,
/System/Library/Frameworks/Carbon.framework/)?  The latter does not
include Core Foundation, Core Graphics, Core Text, or Image I/O, all
of which are C APIs supported and legitimate even in iOS.

> Meanwhile, the Mac port is missing multi-tty, bidi editing, gnutls,
> and lexbind.  It doesn't have integrated themes, packages, Org, or
> CEDET (to name just a few).  It doesn't help GNUstep users at
> all. If xembed catches on, it's unlikely that it'll ever reach the
> Mac port.

If you need Emacs 24-specific features on Mac OS X at the moment, then
you can use not only the NS port, but also the other X11 builds.  And
as I'm saying at the very beginning of the README-mac file in the Mac
port, if the NS port is good enough for you, then you don't need to
try the Mac port.  I guess whether the NS port is sufficient or not
would depend on the personal usage pattern.  Especially, those who
heavily use flyspell-mode would find the NS port insufficient.

Also, I think I've been making rather active and valuable feedbacks in
both bug reporting and bug fixing especially on the platform-specific
part of Emacs, for the bugs I found through the development of the Mac
port.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 20 Dec 2011 10:12:56 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> Also, I think I've been making rather active and valuable feedbacks
> in both bug reporting and bug fixing especially on the
> platform-specific part of Emacs, for the bugs I found through the
> development of the Mac port.

Sorry, I meant "platform-independent part of Emacs".

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: C-g crash in C-x C-f (OSX Lion)

[chad]

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]


On Dec 19, 2011, at 5:12 PM, YAMAMOTO Mitsuharu wrote:
> 
> Which is in your mind when you speak "low-level functionality in
> Carbon", C APIs in general or the Carbon framework (i.e.,
> /System/Library/Frameworks/Carbon.framework/)?  The latter does not
> include Core Foundation, Core Graphics, Core Text, or Image I/O, all
> of which are C APIs supported and legitimate even in iOS.

I'll admit that my mac development experience ended about ten years ago, but my reading of the notes from then and now both suggest that Carbon is a Toolbox replacement/bridge tool, and that it is being phased out over time. I believe that your information is more up-to-date than mine, but my reading of the notes on Carbon seems to state clearly that the entire thing is deprecated and will eventually go away.  I trust you when you say that this is not a practical concern for the Mac port today. Do you believe that it is also not a practical concern for main-line Emacs over the next few years?

> […] I guess whether the NS port is sufficient or not
> would depend on the personal usage pattern.  Especially, those who
> heavily use flyspell-mode would find the NS port insufficient.

Several years ago I moved from being primarily a programmer to primarily writing (structured) english text.  I use flyspell-mode and org-mode more or less constantly (a quick look suggest that I've written at least 150k words using this combination this year). 

What problems do you see with flyspell-mode that I don't see?  Maybe I don't know what I'm missing. :-)

> Also, I think I've been making rather active and valuable feedbacks in
> both bug reporting and bug fixing especially on the platform-specific
> part of Emacs, for the bugs I found through the development of the Mac
> port.

Absolutely!  I did not intend anything I said to imply otherwise, or to impugn your valuable contributions to Emacs. I simply meant to point out that the Mac port is intentionally and, it seems, permanently `behind' the leading edge of Emacs development.  Since it does not appear that that situation will ever change, it is (at least somewhat) counter-productive to recommend to emacs developers on the emacs-devel mailing list that developers switch to an older (but stable) fork, rather than work on improving the mainline.

> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp

*Chad

[-- Attachment #2: Type: text/html, Size: 3560 bytes --]

Re: C-g crash in C-x C-f (OSX Lion)

[Glenn Morris]

chad wrote:

> What problems do you see with flyspell-mode that I don't see?

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5133

and its various duplicates.

Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 19 Dec 2011 17:40:07 -0800, chad <yandros@gmail.com> said:

>> Which is in your mind when you speak "low-level functionality in
>> Carbon", C APIs in general or the Carbon framework (i.e.,
>> /System/Library/Frameworks/Carbon.framework/)?  The latter does not
>> include Core Foundation, Core Graphics, Core Text, or Image I/O,
>> all of which are C APIs supported and legitimate even in iOS.

> I'll admit that my mac development experience ended about ten years
> ago, but my reading of the notes from then and now both suggest that
> Carbon is a Toolbox replacement/bridge tool, and that it is being
> phased out over time. I believe that your information is more
> up-to-date than mine, but my reading of the notes on Carbon seems to
> state clearly that the entire thing is deprecated and will
> eventually go away.  I trust you when you say that this is not a
> practical concern for the Mac port today. Do you believe that it is
> also not a practical concern for main-line Emacs over the next few
> years?

I don't think the above C APIs that are supported and legitimate even
in iOS will go away in the near future.  For the Carbon framework
(again, its non-GUI part), you can find about half of the bundled
applications in Mac OS X 10.7 Lion are using it.  You can list them
with:

  $ for f in /Applications/*.app /Applications/Utilities/*.app; do otool -L "$f"/Contents/MacOS/* | grep -q Carbon && echo "$f"; done 

Safari.app is not listed, but actually it uses the Carbon framework,
too.

  $ otool -L /System/Library/PrivateFrameworks/Safari.framework/Safari | grep Carbon

So, it wouldn't go away too soon, either.  (Of course, I can't speak
for Apple, as I said in the post I referred to in the previous
message.)

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 20 Dec 2011 11:32:19 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>> I'll admit that my mac development experience ended about ten years
>> ago, but my reading of the notes from then and now both suggest that
>> Carbon is a Toolbox replacement/bridge tool, and that it is being
>> phased out over time. I believe that your information is more
>> up-to-date than mine, but my reading of the notes on Carbon seems to
>> state clearly that the entire thing is deprecated and will
>> eventually go away.  I trust you when you say that this is not a
>> practical concern for the Mac port today. Do you believe that it is
>> also not a practical concern for main-line Emacs over the next few
>> years?

> I don't think the above C APIs that are supported and legitimate even
> in iOS will go away in the near future.  For the Carbon framework
> (again, its non-GUI part), you can find about half of the bundled
> applications in Mac OS X 10.7 Lion are using it.  You can list them
> with:

>   $ for f in /Applications/*.app /Applications/Utilities/*.app; do otool -L "$f"/Contents/MacOS/* | grep -q Carbon && echo "$f"; done 

> Safari.app is not listed, but actually it uses the Carbon framework,
> too.

>   $ otool -L /System/Library/PrivateFrameworks/Safari.framework/Safari | grep Carbon

> So, it wouldn't go away too soon, either.  (Of course, I can't speak
> for Apple, as I said in the post I referred to in the previous
> message.)

Most of the uses of the Carbon framework in the Mac port are for Apple
Events and Carbon Events.  If the former is removed from the framework
in the near future, then Apple will provide some replacements in the
Cocoa framework beforehand or at least at the same time.  For the
latter, I don't think its removal would happen in the near future,
because Apple has added new types of Carbon Events even at the release
of the most recent version of Mac OS X (See
/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/CarbonEvents.h
and search for 10.7).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

All of this prompted me to try harder to make the terminal emacs session
as usable (key bindings and other non flashy things) as the graphical one.
I don't really use graphical features anyway and have to --disable-FOO on Xorg.
Hey, nyan-mode works in text-mode too :).

Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 20 Dec 2011 19:33:03 +0100, Carsten Mattner <carstenmattner@googlemail.com> said:

> All of this prompted me to try harder to make the terminal emacs
> session as usable (key bindings and other non flashy things) as the
> graphical one.  I don't really use graphical features anyway and
> have to --disable-FOO on Xorg.  Hey, nyan-mode works in text-mode
> too :).

I'd recommend that for your important tasks.  But it would be
appreciated if you could try the NS port for the tasks where crash is
not so critical and send bug reports.

BTW, Terminal.app bundled with Lion is also linked with the Carbon
framework, so if you really want to avoid Carbon as much as possible,
then it would be better to use another terminal emulator.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Wed, Dec 21, 2011 at 1:38 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>> On Tue, 20 Dec 2011 19:33:03 +0100, Carsten Mattner <carstenmattner@googlemail.com> said:
>
>> All of this prompted me to try harder to make the terminal emacs
>> session as usable (key bindings and other non flashy things) as the
>> graphical one.  I don't really use graphical features anyway and
>> have to --disable-FOO on Xorg.  Hey, nyan-mode works in text-mode
>> too :).
>
> I'd recommend that for your important tasks.  But it would be
> appreciated if you could try the NS port for the tasks where crash is
> not so critical and send bug reports.

Sure. I'm surprised you endorse the NS port instead of the Mac or Aqua
ports :-).

> BTW, Terminal.app bundled with Lion is also linked with the Carbon
> framework, so if you really want to avoid Carbon as much as possible,
> then it would be better to use another terminal emulator.

I use iTerm2.app and xterm.
The comparison doesn't hold as the OSX gui frontend of GNU Emacs
is not as well maintained and tested as the X frontend.
Therefore it makes a difference which future path is selected and
limited resources are used for. If Carbon is deprecated and we already
have a Cocoa frontend, enhancing that seems like a better plan to me.

Would you consider porting over missing bits into the --with-ns frontend?

Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 21 Dec 2011 11:42:57 +0100, Carsten Mattner <carstenmattner@googlemail.com> said:

> On Wed, Dec 21, 2011 at 1:38 AM, YAMAMOTO Mitsuharu
> <mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>>> On Tue, 20 Dec 2011 19:33:03 +0100, Carsten Mattner
>>>>>>> <carstenmattner@googlemail.com> said:
>> 
>>> All of this prompted me to try harder to make the terminal emacs
>>> session as usable (key bindings and other non flashy things) as
>>> the graphical one.  I don't really use graphical features anyway
>>> and have to --disable-FOO on Xorg.  Hey, nyan-mode works in
>>> text-mode too :).
>> 
>> I'd recommend that for your important tasks.  But it would be
>> appreciated if you could try the NS port for the tasks where crash
>> is not so critical and send bug reports.

> Sure. I'm surprised you endorse the NS port instead of the Mac or
> Aqua ports :-).

I didn't make the subject of the sentence explicit.  At least bug
reports for the NS port will be appreciated by someone.  I
occasionally test whether the reported bugs can also be reproduced
with the Mac port.

>> BTW, Terminal.app bundled with Lion is also linked with the Carbon
>> framework, so if you really want to avoid Carbon as much as
>> possible, then it would be better to use another terminal emulator.

> I use iTerm2.app and xterm.

FWIW, both iTerm2 and X11.app are linked with the Carbon framework, in
case it still really matters for you.

> The comparison doesn't hold as the OSX gui frontend of GNU Emacs is
> not as well maintained and tested as the X frontend.  Therefore it
> makes a difference which future path is selected and limited
> resources are used for. If Carbon is deprecated and we already have
> a Cocoa frontend, enhancing that seems like a better plan to me.

Did you read through the thread?  The Mac port uses Cocoa AppKit for
GUI.

> Would you consider porting over missing bits into the --with-ns
> frontend?

No.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Thu, Dec 22, 2011 at 1:34 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>> On Wed, 21 Dec 2011 11:42:57 +0100, Carsten Mattner <carstenmattner@googlemail.com> said:
>
>> On Wed, Dec 21, 2011 at 1:38 AM, YAMAMOTO Mitsuharu
>> <mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>>>> On Tue, 20 Dec 2011 19:33:03 +0100, Carsten Mattner
>>>>>>>> <carstenmattner@googlemail.com> said:
>>>
>>>> All of this prompted me to try harder to make the terminal emacs
>>>> session as usable (key bindings and other non flashy things) as
>>>> the graphical one.  I don't really use graphical features anyway
>>>> and have to --disable-FOO on Xorg.  Hey, nyan-mode works in
>>>> text-mode too :).
>>>
>>> I'd recommend that for your important tasks.  But it would be
>>> appreciated if you could try the NS port for the tasks where crash
>>> is not so critical and send bug reports.
>
>> Sure. I'm surprised you endorse the NS port instead of the Mac or
>> Aqua ports :-).
>
> I didn't make the subject of the sentence explicit.  At least bug
> reports for the NS port will be appreciated by someone.  I
> occasionally test whether the reported bugs can also be reproduced
> with the Mac port.

Sure. Which I did yesterday with the crash report.

>>> BTW, Terminal.app bundled with Lion is also linked with the Carbon
>>> framework, so if you really want to avoid Carbon as much as
>>> possible, then it would be better to use another terminal emulator.
>
>> I use iTerm2.app and xterm.
>
> FWIW, both iTerm2 and X11.app are linked with the Carbon framework, in
> case it still really matters for you.

Doesn't matter in that case as there are maintainers for those.
Emacs' OSX frontends would be better served with more concentrated
efforts trying to make emacs mainline a better experience.
Actually if you ignore the memory leaks (which according to the last
two days were plenty in the NS port) and crashes I never missed anything
in the NS port. I don't use more than 7-bit ASCII, though.

>> The comparison doesn't hold as the OSX gui frontend of GNU Emacs is
>> not as well maintained and tested as the X frontend.  Therefore it
>> makes a difference which future path is selected and limited
>> resources are used for. If Carbon is deprecated and we already have
>> a Cocoa frontend, enhancing that seems like a better plan to me.
>
> Did you read through the thread?  The Mac port uses Cocoa AppKit for
> GUI.

I tried to read it but got lost and that's why I thought I should
just try to use the text frontend.

>> Would you consider porting over missing bits into the --with-ns
>> frontend?
>
> No.

Fair enough. Is it a lot of work to port the Mac frontend to
bzr trunk?

Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 20 Dec 2011 18:24:07 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> Most of the uses of the Carbon framework in the Mac port are for
> Apple Events and Carbon Events.

The main purpose of the use of them is to avoid Lisp evaluation inside
read_socket_hook.

I think keeping such a fundamental design principle of Emacs is more
important for avoiding unpredictable problems that cannot happen on
other platforms, rather than superficially suppressing the use of
64-bit (non-GUI) Carbon, which is widely misunderstood as deprecated.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Thu, Dec 22, 2011 at 1:42 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>> On Tue, 20 Dec 2011 18:24:07 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:
>
>> Most of the uses of the Carbon framework in the Mac port are for
>> Apple Events and Carbon Events.
>
> The main purpose of the use of them is to avoid Lisp evaluation inside
> read_socket_hook.

No way to make that work similarly without Carbon?

> I think keeping such a fundamental design principle of Emacs is more
> important for avoiding unpredictable problems that cannot happen on
> other platforms, rather than superficially suppressing the use of
> 64-bit (non-GUI) Carbon, which is widely misunderstood as deprecated.

I don't follow you here. What's the issue with 64-bit and Carbon?
Terminal.app looks like it's 64-bit.

Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 22 Dec 2011 12:28:31 +0100, Carsten Mattner <carstenmattner@googlemail.com> said:

> On Thu, Dec 22, 2011 at 1:42 AM, YAMAMOTO Mitsuharu
> <mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>>> On Tue, 20 Dec 2011 18:24:07 +0900, YAMAMOTO Mitsuharu
>>>>>>> <mituharu@math.s.chiba-u.ac.jp> said:
>> 
>>> Most of the uses of the Carbon framework in the Mac port are for
>>> Apple Events and Carbon Events.
>> 
>> The main purpose of the use of them is to avoid Lisp evaluation
>> inside read_socket_hook.

> No way to make that work similarly without Carbon?

As far as I know.  I actually tried that at the very early stage of
the development of the predecessor of the Mac port.

>> I think keeping such a fundamental design principle of Emacs is
>> more important for avoiding unpredictable problems that cannot
>> happen on other platforms, rather than superficially suppressing
>> the use of 64-bit (non-GUI) Carbon, which is widely misunderstood
>> as deprecated.

> I don't follow you here. What's the issue with 64-bit and Carbon?
> Terminal.app looks like it's 64-bit.

No issue at least in a technical sense.  The only issue would be those
who are not familiar with Mac OS X development tend to rant "Carbon is
deprecated!" without knowing the detail or its actual use in many
applications.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

23 dec 2011 kl. 02:28 skrev YAMAMOTO Mitsuharu:

>>>>>> On Thu, 22 Dec 2011 12:28:31 +0100, Carsten Mattner <carstenmattner@googlemail.com> said:
> 
>> On Thu, Dec 22, 2011 at 1:42 AM, YAMAMOTO Mitsuharu
>> <mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>>>> On Tue, 20 Dec 2011 18:24:07 +0900, YAMAMOTO Mitsuharu
>>>>>>>> <mituharu@math.s.chiba-u.ac.jp> said:
>>> 
>>>> Most of the uses of the Carbon framework in the Mac port are for
>>>> Apple Events and Carbon Events.
>>> 
>>> The main purpose of the use of them is to avoid Lisp evaluation
>>> inside read_socket_hook.

Are you saying the Cocoa port runs lisp inside read_socket_hook?  Can you show where that is done?


> 
>> No way to make that work similarly without Carbon?
> 
> As far as I know.  I actually tried that at the very early stage of
> the development of the predecessor of the Mac port.

I'm not sure what the problem is, but couldn't Core Foundation be used?

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 23 Dec 2011 09:09:56 +0100, Jan Djärv <jan.h.d@swipnet.se> said:

>>>>> Most of the uses of the Carbon framework in the Mac port are for
>>>>> Apple Events and Carbon Events.
>>>> 
>>>> The main purpose of the use of them is to avoid Lisp evaluation
>>>> inside read_socket_hook.

> Are you saying the Cocoa port runs lisp inside read_socket_hook?
> Can you show where that is done?

I wrote about that in
http://lists.gnu.org/archive/html/emacs-devel/2009-01/msg00952.html :

  In the platforms other than the Cocoa/GNUstep port, menu bar is
  uniformly activated by the x_activate_menubar call in
  kbd_buffer_get_event, which is called from read_char.  However, the
  Cocoa/GNUstep port activates the menu bar and starts mouse tracking
  in the context of read_socket_hook, which is supposed to be called
  from fairly random states of the Lisp interpreter.

The current NS port is trying to minimize the problem by disallowing
Lisp evaluations from QUIT and UNBLOCK_INPUT (grep `handling_signal'
in the NS specific code including those enclosed with #ifdef HAVE_NS).
I don't know if that could avoid all the problems, or some of unsolved
problems on the NS port are caused by this.  Anyway, I would choose
keeping the fundamental design principle and did so in the Mac port.

Allowing menu bar activation while disallowing Lisp evaluations in
read_socket_hook from QUIT/UNBLOCK_INPUT also causes a bogus menu bar
problem: one can start menu bar tracking even during the evaluation of
(while t), whereas the contents of the `Buffers' menu would possibly
be outdated.  (BTW, I found that the position of the `Buffers' menu is
strange on the NS port.)

>>> No way to make that work similarly without Carbon?
>> 
>> As far as I know.  I actually tried that at the very early stage of
>> the development of the predecessor of the Mac port.

> I'm not sure what the problem is, but couldn't Core Foundation be
> used?

I don't think so.  But maybe you have some (rough) idea?  It doesn't
make sense to avoid 64-bit Carbon for the Mac port, but it might be
useful for the NS port.  (I'm not sure whether Core Foundation is also
available on GNUstep.)

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

24 dec 2011 kl. 02:54 skrev YAMAMOTO Mitsuharu:

>>>>>> On Fri, 23 Dec 2011 09:09:56 +0100, Jan Djärv <jan.h.d@swipnet.se> said:
> 
>>>>>> Most of the uses of the Carbon framework in the Mac port are for
>>>>>> Apple Events and Carbon Events.
>>>>> 
>>>>> The main purpose of the use of them is to avoid Lisp evaluation
>>>>> inside read_socket_hook.
> 
>> Are you saying the Cocoa port runs lisp inside read_socket_hook?
>> Can you show where that is done?
> 
> I wrote about that in
> http://lists.gnu.org/archive/html/emacs-devel/2009-01/msg00952.html :
> 
>  In the platforms other than the Cocoa/GNUstep port, menu bar is
>  uniformly activated by the x_activate_menubar call in
>  kbd_buffer_get_event, which is called from read_char.  However, the
>  Cocoa/GNUstep port activates the menu bar and starts mouse tracking
>  in the context of read_socket_hook, which is supposed to be called
>  from fairly random states of the Lisp interpreter.
> 
> The current NS port is trying to minimize the problem by disallowing
> Lisp evaluations from QUIT and UNBLOCK_INPUT (grep `handling_signal'
> in the NS specific code including those enclosed with #ifdef HAVE_NS).
> I don't know if that could avoid all the problems, or some of unsolved
> problems on the NS port are caused by this.  Anyway, I would choose
> keeping the fundamental design principle and did so in the Mac port.
> 
> Allowing menu bar activation while disallowing Lisp evaluations in
> read_socket_hook from QUIT/UNBLOCK_INPUT also causes a bogus menu bar
> problem: one can start menu bar tracking even during the evaluation of
> (while t), whereas the contents of the `Buffers' menu would possibly
> be outdated.

This can be fixed in Cocoa, but OSX 10.5 or later is required (AFAIK anyway).

>  (BTW, I found that the position of the `Buffers' menu is
> strange on the NS port.)
> 

This must be a bug.

>>>> No way to make that work similarly without Carbon?
>>> 
>>> As far as I know.  I actually tried that at the very early stage of
>>> the development of the predecessor of the Mac port.
> 
>> I'm not sure what the problem is, but couldn't Core Foundation be
>> used?
> 
> I don't think so.  But maybe you have some (rough) idea?  It doesn't
> make sense to avoid 64-bit Carbon for the Mac port, but it might be
> useful for the NS port.  (I'm not sure whether Core Foundation is also
> available on GNUstep.)

There are some nice things (like CFFileDescriptor) in CoreFoundation that isn't available at the Cocoa level.  It just occured to me that something useful could be found here.  CoreFoundation is not available for GnuStep.

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[David Reitter]

On Dec 26, 2011, at 4:31 PM, Jan Djärv wrote:
> 
> This can be fixed in Cocoa, but OSX 10.5 or later is required (AFAIK anyway).

Even a year ago, when I checked my statistics, the number of 10.4 (and older) users was tiny.  The number of more up-to-date Aquamacs versions used on 10.4 and 10.5 was very low (<1%).  Mac users who like Emacs, presumably, upgrade their operating system regularly, and those who like new versions of application software certainly do so.  I can update the statistics and report exact numbers if anyone here would like to see them.

A requirement for 10.5, or even 10.6 would be no problem and, in the contrary, may improve code quality.  (Based on the numbers, we're not providing universal binaries for much longer, and I will not invest much time in PPC binaries).

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Mon, Dec 26, 2011 at 4:31 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> There are some nice things (like CFFileDescriptor) in CoreFoundation
> that isn't available at the Cocoa level.  It just occured to me that something
> useful could be found here.  CoreFoundation is not available for GnuStep.

Does the NS port have to have 1:1 support of OSX and Gnustep?

I'd argue that OSX should be a priority of the NS port due to the
reportedly incomplete and unsatisfactory state of the Emacs.app
on OSX. That doesn't mean I'd like to see Gnustep be a lesser port.
If we want to keep and use the NS port for OSX, we should strive
to make it as best as possible while we keep the Mac and Aqua ports
out of the tree.

Anything wrong with that?

Re: C-g crash in C-x C-f (OSX Lion)

[Stephen J. Turnbull]

Jan Djärv writes:

 > This can be fixed in Cocoa, but OSX 10.5 or later is required
 > (AFAIK anyway).

This isn't a problem.  Everybody else drops support for all but the
current and previous versions of Mac OS X.  I don't see a good reason
why Emacs should bend over backward to support very old versions of
Mac OS X in a port that isn't even part of Emacs yet.

Of course up to the volunteers who work on it -- if they want to
provide support, more power to them -- but those of us who continue to
use older versions of Mac OS X know where we stand.

Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 27 Dec 2011 01:41:08 +0900, "Stephen J. Turnbull" <stephen@xemacs.org> said:

>> This can be fixed in Cocoa, but OSX 10.5 or later is required
>> (AFAIK anyway).

> This isn't a problem.  Everybody else drops support for all but the
> current and previous versions of Mac OS X.  I don't see a good
> reason why Emacs should bend over backward to support very old
> versions of Mac OS X in a port that isn't even part of Emacs yet.

The main reason why I'm keeping the support for older versions is to
see whether the code has enough quality about tolerance of version
difference, not depending on some specific behavior of particular
implementation, in hope that this will also enhance compatibility with
future versions.  Of course, supporting too old versions can do harm
than good, and actually I dropped Mac OS X 10.1 support on the
transition from Emacs 22 Carbon+AppKit port to Emacs 23 Mac port.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 26 Dec 2011 16:31:12 +0100, Jan Djärv <jan.h.d@swipnet.se> said:

>>> Are you saying the Cocoa port runs lisp inside read_socket_hook?
>>> Can you show where that is done?
>> 
>> I wrote about that in
>> http://lists.gnu.org/archive/html/emacs-devel/2009-01/msg00952.html
>> :
>> 
>> In the platforms other than the Cocoa/GNUstep port, menu bar is
>> uniformly activated by the x_activate_menubar call in
>> kbd_buffer_get_event, which is called from read_char.  However, the
>> Cocoa/GNUstep port activates the menu bar and starts mouse tracking
>> in the context of read_socket_hook, which is supposed to be called
>> from fairly random states of the Lisp interpreter.
>> 
>> The current NS port is trying to minimize the problem by
>> disallowing Lisp evaluations from QUIT and UNBLOCK_INPUT (grep
>> `handling_signal' in the NS specific code including those enclosed
>> with #ifdef HAVE_NS).  I don't know if that could avoid all the
>> problems, or some of unsolved problems on the NS port are caused by
>> this.  Anyway, I would choose keeping the fundamental design
>> principle and did so in the Mac port.
>> 
>> Allowing menu bar activation while disallowing Lisp evaluations in
>> read_socket_hook from QUIT/UNBLOCK_INPUT also causes a bogus menu
>> bar problem: one can start menu bar tracking even during the
>> evaluation of (while t), whereas the contents of the `Buffers' menu
>> would possibly be outdated.

> This can be fixed in Cocoa, but OSX 10.5 or later is required (AFAIK
> anyway).

That'll be good.  When I first tried porting the GUI part to Cocoa,
the newest version of Mac OS X was 10.4, so I couldn't use the way you
are talking about.  (It was a bit after the announcement that Carbon
GUI will not support 64-bit on coming Mac OS X 10.5.)  Even after the
10.5 release, I couldn't have dropped the support for the older
versions.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: C-g crash in C-x C-f (OSX Lion)

[Ted Zlatanov]

On Fri, 23 Dec 2011 10:28:00 +0900 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote: 

YM> The only issue would be those who are not familiar with Mac OS X
YM> development tend to rant "Carbon is deprecated!" without knowing the
YM> detail or its actual use in many applications.

In defense of the NS port, It is compatible with GNUstep and yours
isn't, and that IIRC was a major reason to bring the NS port into the
trunk.

Ted

Re: C-g crash in C-x C-f (OSX Lion)

[Stephen J. Turnbull]

Ted Zlatanov writes:
 > On Fri, 23 Dec 2011 10:28:00 +0900 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote: 
 > 
 > YM> The only issue would be those who are not familiar with Mac OS X
 > YM> development tend to rant "Carbon is deprecated!" without knowing the
 > YM> detail or its actual use in many applications.
 > 
 > In defense of the NS port, It is compatible with GNUstep and yours
 > isn't, and that IIRC was a major reason to bring the NS port into the
 > trunk.

I don't recall Yamamoto-san ever complaining that the NS port is in
and the Mac port is out.

He's just understandably exasperated that every time a third party
suggests including it, somebody who is not a Mac developer says that
it uses Carbon APIs, and since Apple has deprecated Carbon APIs, that
makes it a dead end anyway.  The first clause of that argument is a
whole truth, the second a half-truth, and the conclusion is bunk.

Re: C-g crash in C-x C-f (OSX Lion)

[Ted Zlatanov]

On Sat, 24 Dec 2011 00:05:11 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Zlatanov writes:
>> On Fri, 23 Dec 2011 10:28:00 +0900 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote: 
>> 
YM> The only issue would be those who are not familiar with Mac OS X
YM> development tend to rant "Carbon is deprecated!" without knowing the
YM> detail or its actual use in many applications.
>> 
>> In defense of the NS port, It is compatible with GNUstep and yours
>> isn't, and that IIRC was a major reason to bring the NS port into the
>> trunk.

SJT> He's just understandably exasperated that every time a third party
SJT> suggests including it, somebody who is not a Mac developer says that
SJT> it uses Carbon APIs, and since Apple has deprecated Carbon APIs, that
SJT> makes it a dead end anyway.  The first clause of that argument is a
SJT> whole truth, the second a half-truth, and the conclusion is bunk.

Apple's stance on Carbon has shifted over time, wihch adds to the
confusion (for users and developers alike).  I apologize for where I
have contributed to that confusion in the past.  I only wanted to voice
my support for the NS port, which fits well with the GNU project's goals.

Ted

Re: C-g crash in C-x C-f (OSX Lion)

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > Apple's stance on Carbon has shifted over time, wihch adds to the
 > confusion (for users and developers alike).

Sure, but so does every project.  Jamie Zawinski's CADT rant isn't
just about GNOME.  Manpower is limited, there's only so much that can
be supported indefinitely.

 > I only wanted to voice my support for the NS port, which fits well
 > with the GNU project's goals.

Here's to having goals, and working to accomplish them!

Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 27 Dec 2011 10:52:36 -0500, Ted Zlatanov <tzz@lifelogs.com> said:

> I only wanted to voice my support for the NS port, which fits well
> with the GNU project's goals.

Which version of GNUstep are you using?  I tried to check the fix I
created for Bug#10240 myself, but actually I couldn't do that with
Ubuntu 11.10 (Base 1.22.0, GUI 0.20.0, Make 2.6.0, and Backend
0.20.1).  It would be helpful if the actual users of the GNUstep port
could tell the versions/configurations they are using (or they would
recommend).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: C-g crash in C-x C-f (OSX Lion)

[Stefan Monnier]

>> I only wanted to voice my support for the NS port, which fits well
>> with the GNU project's goals.
> Which version of GNUstep are you using?  I tried to check the fix I
> created for Bug#10240 myself, but actually I couldn't do that with
> Ubuntu 11.10 (Base 1.22.0, GUI 0.20.0, Make 2.6.0, and Backend
> 0.20.1).  It would be helpful if the actual users of the GNUstep port
> could tell the versions/configurations they are using (or they would
> recommend).

I'd be surprised to hear there are actual users of the GNUstep port of
Emacs because it was hardly usable last time I checked.  IOW it needs
some love.


        Stefan

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

Hello.

It seems to be hard to setup a usable Gnustep environment in itself. I tried, but got a lot of font problems.

      Jan D.

28 dec 2011 kl. 11:42 skrev Stefan Monnier <monnier@IRO.UMontreal.CA>:

>>> I only wanted to voice my support for the NS port, which fits well
>>> with the GNU project's goals.
>> Which version of GNUstep are you using?  I tried to check the fix I
>> created for Bug#10240 myself, but actually I couldn't do that with
>> Ubuntu 11.10 (Base 1.22.0, GUI 0.20.0, Make 2.6.0, and Backend
>> 0.20.1).  It would be helpful if the actual users of the GNUstep port
>> could tell the versions/configurations they are using (or they would
>> recommend).
> 
> I'd be surprised to hear there are actual users of the GNUstep port of
> Emacs because it was hardly usable last time I checked.  IOW it needs
> some love.
> 
> 
>        Stefan

Re: C-g crash in C-x C-f (OSX Lion)

[Ted Zlatanov]

On Wed, 28 Dec 2011 16:36:01 +0900 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote: 

>>>>>> On Tue, 27 Dec 2011 10:52:36 -0500, Ted Zlatanov <tzz@lifelogs.com> said:
>> I only wanted to voice my support for the NS port, which fits well
>> with the GNU project's goals.

YM> Which version of GNUstep are you using?  I tried to check the fix I
YM> created for Bug#10240 myself, but actually I couldn't do that with
YM> Ubuntu 11.10 (Base 1.22.0, GUI 0.20.0, Make 2.6.0, and Backend
YM> 0.20.1).  It would be helpful if the actual users of the GNUstep port
YM> could tell the versions/configurations they are using (or they would
YM> recommend).

I am not a GNUstep user.  I hardly have the time to test Emacs on
GNU/Linux these days!

Ted

Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 28 Dec 2011 19:18:51 -0500, Ted Zlatanov <tzz@lifelogs.com> said:

> On Wed, 28 Dec 2011 16:36:01 +0900 YAMAMOTO Mitsuharu
> <mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>>> On Tue, 27 Dec 2011 10:52:36 -0500, Ted Zlatanov
>>>>>>> <tzz@lifelogs.com> said:
>>> I only wanted to voice my support for the NS port, which fits well
>>> with the GNU project's goals.

YM> Which version of GNUstep are you using?  I tried to check the fix
YM> I created for Bug#10240 myself, but actually I couldn't do that
YM> with Ubuntu 11.10 (Base 1.22.0, GUI 0.20.0, Make 2.6.0, and
YM> Backend 0.20.1).  It would be helpful if the actual users of the
YM> GNUstep port could tell the versions/configurations they are using
YM> (or they would recommend).

> I am not a GNUstep user.  I hardly have the time to test Emacs on
> GNU/Linux these days!

So, what was your impression on the GNUstep port when you tried it
some time ago?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: C-g crash in C-x C-f (OSX Lion)

[Ted Zlatanov]

On Thu, 29 Dec 2011 09:57:25 +0900 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote: 

>>>>>> On Wed, 28 Dec 2011 19:18:51 -0500, Ted Zlatanov <tzz@lifelogs.com> said:

>> I am not a GNUstep user.  I hardly have the time to test Emacs on
>> GNU/Linux these days!

YM> So, what was your impression on the GNUstep port when you tried it
YM> some time ago?

I was not able to set up the basic GNUstep at the time and gave up.

Ted

Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 29 Dec 2011 10:15:15 -0500, Ted Zlatanov <tzz@lifelogs.com> said:

>>> I am not a GNUstep user.  I hardly have the time to test Emacs on
>>> GNU/Linux these days!

YM> So, what was your impression on the GNUstep port when you tried it
YM> some time ago?

> I was not able to set up the basic GNUstep at the time and gave up.

So, your declaration of preference for the NS port to the Mac port
with respect to GNUstep was nothing based on your actual experience.
That's rather surprising to me.

When others say the similar thing next time, maybe I should ask their
experience of the GNUstep port before taking their words seriously.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: C-g crash in C-x C-f (OSX Lion)

[Ted Zlatanov]

On Fri, 30 Dec 2011 09:34:49 +0900 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote: 

>>>>>> On Thu, 29 Dec 2011 10:15:15 -0500, Ted Zlatanov <tzz@lifelogs.com> said:
>>>> I am not a GNUstep user.  I hardly have the time to test Emacs on
>>>> GNU/Linux these days!

YM> So, what was your impression on the GNUstep port when you tried it
YM> some time ago?

>> I was not able to set up the basic GNUstep at the time and gave up.

YM> So, your declaration of preference for the NS port to the Mac port
YM> with respect to GNUstep was nothing based on your actual experience.
YM> That's rather surprising to me.

There is a lot of software in the GNU project I don't use, for lack of
time or because it doesn't fit my needs.  Does that preclude me from
supporting it?  I had assumed it was not so.

YM> When others say the similar thing next time, maybe I should ask their
YM> experience of the GNUstep port before taking their words seriously.

I'm pretty sure this is the position of the Emacs maintainers as well.
But your choice to take my words seriously is, of course, your own.  

I did not mean to start an argument and my original statement was
clearly based on the GNU project's goals and not on how much I have used
GNUstep.  If that wasn't clear enough then, I hope it is now.

Ted

Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

On 2011/12/30, at 23:52, Ted Zlatanov wrote:

> On Fri, 30 Dec 2011 09:34:49 +0900 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote: 
> 
>>>>>>> On Thu, 29 Dec 2011 10:15:15 -0500, Ted Zlatanov <tzz@lifelogs.com> said:
>>>>> I am not a GNUstep user.  I hardly have the time to test Emacs on
>>>>> GNU/Linux these days!
> 
> YM> So, what was your impression on the GNUstep port when you tried it
> YM> some time ago?
> 
>>> I was not able to set up the basic GNUstep at the time and gave up.
> 
> YM> So, your declaration of preference for the NS port to the Mac port
> YM> with respect to GNUstep was nothing based on your actual experience.
> YM> That's rather surprising to me.
> 
> There is a lot of software in the GNU project I don't use, for lack of
> time or because it doesn't fit my needs.  Does that preclude me from
> supporting it?  I had assumed it was not so.
> 
> YM> When others say the similar thing next time, maybe I should ask their
> YM> experience of the GNUstep port before taking their words seriously.
> 
> I'm pretty sure this is the position of the Emacs maintainers as well.
> But your choice to take my words seriously is, of course, your own.  
> 
> I did not mean to start an argument and my original statement was
> clearly based on the GNU project's goals and not on how much I have used
> GNUstep.  If that wasn't clear enough then, I hope it is now.

When I tried the GNUstep port some time ago, it was quite
unsatisfactory.  I thought it might be only for me and the
problem of the GNUstep version I tried or because of my
configuration.  So I asked your GNUstep version/configuration
because I took it for granted that those who are backing the
GNUstep port at least have experience of its use, otherwise it
looked so irresponsible to me.

I even think that pushing software that is far from usable only
because it is for GNUstep might result in lowering the
image/evaluation of GNUstep itself and do harm for the GNU
project's goal, because those who actually tried the GNUstep port
will feel disappointed.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Mac OS-compatible ports (was: C-g crash in C-x C-f (OSX Lion))

[Ted Zlatanov]

(changing the thread subject, we've drifted off-topic long enough)

On Sat, 31 Dec 2011 07:12:58 +0900 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote: 

YM> When I tried the GNUstep port some time ago, it was quite
YM> unsatisfactory.  I thought it might be only for me and the problem
YM> of the GNUstep version I tried or because of my configuration.  So I
YM> asked your GNUstep version/configuration because I took it for
YM> granted that those who are backing the GNUstep port at least have
YM> experience of its use, otherwise it looked so irresponsible to me.

I understand and apologize I was not clearer.

YM> I even think that pushing software that is far from usable only
YM> because it is for GNUstep might result in lowering the
YM> image/evaluation of GNUstep itself and do harm for the GNU project's
YM> goal, because those who actually tried the GNUstep port will feel
YM> disappointed.

I agree with your statement, but we're not "pushing" the NS port only
because it's for GNUstep.  It's quite usable on Mac OS X.  I said that
"in its defense" it is compatible with GNUstep by using the Cocoa API,
which your port isn't.  So, to make the current situation clear, the
Mac OS port choice is between:

1) NS port: Cocoa API, works on Mac OS X with some issues, compatible
with GNUstep and can work there (it needs lots of work though).  Apple
has repeatedly stated Cocoa is the preferred API for Mac OS X
developers, especially for new software.

2) your Carbon-based port: works on Mac OS X well, can't be compatible
with GNUstep.  Apple has not been clear about Carbon's future, even
though Carbon seems to be well entrenched at this point.

3) Aquamacs: I don't know if it uses Cocoa, how its author feels about
inclusion, or whether it's fundamentally different from (1) or (2)

4) Other ports?  I don't know of any.

5) A brand new port.

Given those choices, the NS port seems like the best choice for
inclusion in GNU Emacs, which is the status quo.  Are any of the facts
I've presented inaccurate?

I have great respect for the work you've done with your Mac port, and I
hope you don't see this discussion as an attempt to diminish it.

Ted

Re: Mac OS-compatible ports

[Jan D.]

Ted Zlatanov skrev 2011-12-31 14:22:
> (changing the thread subject, we've drifted off-topic long enough)
>
> On Sat, 31 Dec 2011 07:12:58 +0900 YAMAMOTO Mitsuharu<mituharu@math.s.chiba-u.ac.jp>  wrote:
>
> YM>  When I tried the GNUstep port some time ago, it was quite
> YM>  unsatisfactory.  I thought it might be only for me and the problem
> YM>  of the GNUstep version I tried or because of my configuration.  So I
> YM>  asked your GNUstep version/configuration because I took it for
> YM>  granted that those who are backing the GNUstep port at least have
> YM>  experience of its use, otherwise it looked so irresponsible to me.
>
> I understand and apologize I was not clearer.
>
> YM>  I even think that pushing software that is far from usable only
> YM>  because it is for GNUstep might result in lowering the
> YM>  image/evaluation of GNUstep itself and do harm for the GNU project's
> YM>  goal, because those who actually tried the GNUstep port will feel
> YM>  disappointed.
>
> I agree with your statement, but we're not "pushing" the NS port only
> because it's for GNUstep.  It's quite usable on Mac OS X.  I said that
> "in its defense" it is compatible with GNUstep by using the Cocoa API,
> which your port isn't.  So, to make the current situation clear, the
> Mac OS port choice is between:
>
> 1) NS port: Cocoa API, works on Mac OS X with some issues, compatible
> with GNUstep and can work there (it needs lots of work though).  Apple
> has repeatedly stated Cocoa is the preferred API for Mac OS X
> developers, especially for new software.

I don't think GNUStep needs "lots" of work, just work :-).  AFAIK, it is 
mainly fonts that are problematic, but then again, fonts in GNUStep 
(i.e. without Emacs) seems to be a problem.  The NS font backend needs 
work, as it is quite slow and uses old API:s.

	Jan D.

Re: Mac OS-compatible ports

[YAMAMOTO Mitsuharu]

On 2011/12/31, at 23:27, Jan D. wrote:

>> 1) NS port: Cocoa API, works on Mac OS X with some issues, compatible
>> with GNUstep and can work there (it needs lots of work though).  Apple
>> has repeatedly stated Cocoa is the preferred API for Mac OS X
>> developers, especially for new software.
> 
> I don't think GNUStep needs "lots" of work, just work :-).  AFAIK, it is mainly fonts that are problematic, but then again, fonts in GNUStep (i.e. without Emacs) seems to be a problem.  The NS font backend needs work, as it is quite slow and uses old API:s.

What about the "Lisp evaluation inside read_socket_hook" problem
on the GNUstep port?  Is your idea for Cocoa (Mac OS X 10.5 or
later) applicable to GNUstep, or do you have another idea?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Mac OS-compatible ports

[Jan Djärv]

Hello.


1 jan 2012 kl. 02:54 skrev YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:
> 
> What about the "Lisp evaluation inside read_socket_hook" problem
> on the GNUstep port?  Is your idea for Cocoa (Mac OS X 10.5 or
> later) applicable to GNUstep, or do you have another idea?

If GNUstep provides the same API, it is applicable, but I have to get GNUstep up and running first to check. Their documentation says no, but that might not be up to date.

But I'm sure some solution can be found. It does not need to be the same as for OSX. 

On another note, could your font backend be plugged in in Emacs 24?  Would it be worthwhile?

   Jan D. 

Re: Mac OS-compatible ports

[Adrian Robert]

Jan Djärv <jan.h.d <at> swipnet.se> writes:

> 1 jan 2012 kl. 02:54 skrev
>   YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>:
> > 
> > What about the "Lisp evaluation inside read_socket_hook" problem
> > on the GNUstep port?  Is your idea for Cocoa (Mac OS X 10.5 or
> > later) applicable to GNUstep, or do you have another idea?
> 
> If GNUstep provides the same API, it is applicable, but I have to get
 GNUstep up and running first to check.
> Their documentation says no, but that might not be up to date.
> 
> But I'm sure some solution can be found. It does not need to be the same
> as for OSX. 
> 
> On another note, could your font backend be plugged in in Emacs 24?  Would it
> be worthwhile?


In principle it should be possible to plug in pieces from some of
the font backend function implementations.  It would necessitate
ifdefs for GNUstep.  One way to make that cleaner would be simply
to split the backends for GNUstep and MacOS, using a superclass
for common functionality, similar to W32 and X.

As far as read_socket_hook, there has been a lot of discussion of
this in the past.  Yamamoto-san has always insisted there is an
irremediable design issue in the NS port, but I've never been
convinced of this, preferring to target and fix individual
problems.  Not sure if either of us can be 100% objective
though. ;-)

Still, when I last looked at this (years ago now), it seemed like
it would be possible to switch the event loop approach without
large-scale code changes.

One aspect which I don't remember the status of is multi-TTY.  I
remember at one point the Mac port wasn't working with it.  Is
that still the case?  If so is it a design issue relating to the
event loop approach or something that could be fixed?

-Adrian

Re: Mac OS-compatible ports

[YAMAMOTO Mitsuharu]

On 2012/01/02, at 0:31, Adrian Robert wrote:

> One aspect which I don't remember the status of is multi-TTY.  I
> remember at one point the Mac port wasn't working with it.  Is
> that still the case?  If so is it a design issue relating to the
> event loop approach or something that could be fixed?

The reason why the Mac port doesn't support multi-tty with
GUI (TTY-only multi-tty is supposed to work) is there's no way to
detach Emacs as a GUI application from Window Server or Dock
without terminating the GUI process, as far as I know.  IIRC the
W32 port doesn't support multi-tty with GUI.  Maybe for simlar
reason?

One way to solve this cleanly is to seperate GUI process from
Lisp process.  It might be a future direction, but I don't think
it's something I should do now for the port of Emacs 23.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Mac OS-compatible ports (was: C-g crash in C-x C-f (OSX Lion))

[YAMAMOTO Mitsuharu]

On 2011/12/31, at 22:22, Ted Zlatanov wrote:

> I agree with your statement, but we're not "pushing" the NS port only
> because it's for GNUstep.  It's quite usable on Mac OS X.  I said that
> "in its defense" it is compatible with GNUstep by using the Cocoa API,
> which your port isn't.  So, to make the current situation clear, the
> Mac OS port choice is between:
> 
> 1) NS port: Cocoa API, works on Mac OS X with some issues, compatible
> with GNUstep and can work there (it needs lots of work though).  Apple
> has repeatedly stated Cocoa is the preferred API for Mac OS X
> developers, especially for new software.
> 
> 2) your Carbon-based port: works on Mac OS X well, can't be compatible
> with GNUstep.  Apple has not been clear about Carbon's future, even
> though Carbon seems to be well entrenched at this point.

As I've been repeatedly saying, the Mac port uses Cocoa for its
GUI implementation.  If you call the Mac port Carbon-based, lots
of the applications including those bundled with Mac OS X such as
Safari.app should also be called Carbon-based.

(snip)

> Given those choices, the NS port seems like the best choice for
> inclusion in GNU Emacs, which is the status quo.  Are any of the facts
> I've presented inaccurate?

I'm not saying about the inclusion.  I'm just correcting negative
statements with respect to the Mac port, many of which are made
with wrong understanding about the actual situation of Mac OS X
development, or even not based on the actual use.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Mac OS-compatible ports (was: C-g crash in C-x C-f (OSX Lion))

[YAMAMOTO Mitsuharu]

On 2012/01/01, at 10:47, YAMAMOTO Mitsuharu wrote:

> 
> On 2011/12/31, at 22:22, Ted Zlatanov wrote:
> 
>> I agree with your statement, but we're not "pushing" the NS port only
>> because it's for GNUstep.  It's quite usable on Mac OS X.  I said that
>> "in its defense" it is compatible with GNUstep by using the Cocoa API,
>> which your port isn't.  So, to make the current situation clear, the
>> Mac OS port choice is between:
>> 
>> 1) NS port: Cocoa API, works on Mac OS X with some issues, compatible
>> with GNUstep and can work there (it needs lots of work though).  Apple
>> has repeatedly stated Cocoa is the preferred API for Mac OS X
>> developers, especially for new software.
>> 
>> 2) your Carbon-based port: works on Mac OS X well, can't be compatible
>> with GNUstep.  Apple has not been clear about Carbon's future, even
>> though Carbon seems to be well entrenched at this point.
> 
> As I've been repeatedly saying, the Mac port uses Cocoa for its
> GUI implementation.  If you call the Mac port Carbon-based, lots
> of the applications including those bundled with Mac OS X such as
> Safari.app should also be called Carbon-based.

Also, I would like to note that some of recent improvements to
Mac OS X and iOS are provided outside Cocoa, especially if they
are not directly related to GUI.  They are not classified as
Carbon, but they are also C APIs and not provided by GNUstep.
For example, Grand Central Dispatch (GCD) I mentioned in the
`select' emulation without periodic polling is a C API and
provided by both Mac OS X and iOS, but not by GNUstep.

  http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00694.html

The Core Text framework I'm using for the font backend driver in
the Mac port is also a C API.  Interestingly, in iOS Apple
provides an advanced low-level text layout API (Core Text) only
at C level, rather than copying such API (NSLayoutManager etc.)
from Mac OS X Cocoa AppKit to iOS UIKit.  I think this implies
Apple's preference of C API to Cocoa for advanced low-level tasks
that applications such as text editors want to use.

Because the Mac port already uses Cocoa AppKit for GUI, the
argument about Apple's preference of Cocoa to Carbon (with
respect to GUI) you made above is rather pointless.  I even have
an impression that the Mac port usually behaves more like other
Cocoa applications than the NS port does.

  http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-12/msg00735.html

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Mac OS-compatible ports

[David De La Harpe Golden]

On 01/01/12 07:02, YAMAMOTO Mitsuharu wrote:

> For example, Grand Central Dispatch (GCD) I mentioned in the
> `select' emulation without periodic polling is a C API and
> provided by both Mac OS X and iOS, but not by GNUstep.
>

libdispatch itself is, however, Apache 2.0 licensed,
and has been ported to gnu+linux and packaged for debian/unstable

http://packages.debian.org/sid/libdispatch0
http://chris.mowforth.com/installing-grand-central-dispatch-on-linux

I haven't tried it, but the in-development ObjC2 runtime for GNUstep
reportedly had its own "toylibdispatch" implementation it uses, and 
maybe can now use the "real" one above with some hacking, based on this 
ticket:

http://savannah.gnu.org/bugs/?34627

But it's all a bit bleeding edge, stable GNUstep doesn't support blocks 
and stuff yet.  Apart from that, note this stuff reportedly currently 
requires clang rather than gcc at present.

http://wiki.gnustep.org/index.php/ObjC2_FAQ#Which_Runtime_Should_I_use.3F

But anyway, still, I'd be wary of some "GNUstep doesn't support" claims, 
they may just be "Stable release of GNUstep doesn't support" or "GNUstep 
doesn't support yet".

I think it really would be a shame to break emacs GNUstep compat, 
especially as it's clear from the above the GNUstep project is making 
strong efforts to keep up with apple's modernisations (whatever your 
opinion of apple as a company, purely technically I think most people 
would agree objc2 blocks etc. are a really good thing for objc...). 
Though maybe there could be greater separation in the code paths in 
emacs, say separate 'gnustep and 'macosx window systems rather than a 
unified 'ns, despite the seemingly large overlap.

Re: Mac OS-compatible ports

[YAMAMOTO Mitsuharu]

On 2012/01/02, at 6:18, David De La Harpe Golden wrote:

> I think it really would be a shame to break emacs GNUstep compat, especially as it's clear from the above the GNUstep project is making strong efforts to keep up with apple's modernisations (whatever your opinion of apple as a company, purely technically I think most people would agree objc2 blocks etc. are a really good thing for objc...). Though maybe there could be greater separation in the code paths in emacs, say separate 'gnustep and 'macosx window systems rather than a unified 'ns, despite the seemingly large overlap.

If GNUstep is going to such a direction that it adopts C APIs
that are supported by both Mac OS X and iOS (e.g., Core
Foundation, Core Graphics, Core Text and Image I/O), then many
parts of the code of the Mac port will become usable also in
GNUstep.  As a result of transition to 64-bit and Cocoa GUI, many
uses of C APIs in the Mac port already fall into this category.

Of course, there will remain some Mac OS X-specific parts, and as
it is shown by the current NS port status, practice will not
always work as in theory.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Mac OS-compatible ports (was: C-g crash in C-x C-f (OSX Lion))

[Carsten Mattner]

On Sun, Jan 1, 2012 at 2:47 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>
> On 2011/12/31, at 22:22, Ted Zlatanov wrote:
>
>> I agree with your statement, but we're not "pushing" the NS port only
>> because it's for GNUstep.  It's quite usable on Mac OS X.  I said that
>> "in its defense" it is compatible with GNUstep by using the Cocoa API,
>> which your port isn't.  So, to make the current situation clear, the
>> Mac OS port choice is between:
>>
>> 1) NS port: Cocoa API, works on Mac OS X with some issues, compatible
>> with GNUstep and can work there (it needs lots of work though).  Apple
>> has repeatedly stated Cocoa is the preferred API for Mac OS X
>> developers, especially for new software.
>>
>> 2) your Carbon-based port: works on Mac OS X well, can't be compatible
>> with GNUstep.  Apple has not been clear about Carbon's future, even
>> though Carbon seems to be well entrenched at this point.
>
> As I've been repeatedly saying, the Mac port uses Cocoa for its
> GUI implementation.  If you call the Mac port Carbon-based, lots
> of the applications including those bundled with Mac OS X such as
> Safari.app should also be called Carbon-based.
>
> (snip)
>
>> Given those choices, the NS port seems like the best choice for
>> inclusion in GNU Emacs, which is the status quo.  Are any of the facts
>> I've presented inaccurate?
>
> I'm not saying about the inclusion.  I'm just correcting negative
> statements with respect to the Mac port, many of which are made
> with wrong understanding about the actual situation of Mac OS X
> development, or even not based on the actual use.
>
>                                     YAMAMOTO Mitsuharu
>                                mituharu@math.s.chiba-u.ac.jp

Can we please update the emacs wiki with a table for reference
comparing the different OS X ports?

Re: Mac OS-compatible ports

[Ted Zlatanov]

On Sun, 1 Jan 2012 10:47:38 +0900 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote: 

YM> On 2011/12/31, at 22:22, Ted Zlatanov wrote:

>> I agree with your statement, but we're not "pushing" the NS port only
>> because it's for GNUstep.  It's quite usable on Mac OS X.  I said that
>> "in its defense" it is compatible with GNUstep by using the Cocoa API,
>> which your port isn't.  So, to make the current situation clear, the
>> Mac OS port choice is between:
>> 
>> 1) NS port: Cocoa API, works on Mac OS X with some issues, compatible
>> with GNUstep and can work there (it needs lots of work though).  Apple
>> has repeatedly stated Cocoa is the preferred API for Mac OS X
>> developers, especially for new software.
>> 
>> 2) your Carbon-based port: works on Mac OS X well, can't be compatible
>> with GNUstep.  Apple has not been clear about Carbon's future, even
>> though Carbon seems to be well entrenched at this point.

YM> As I've been repeatedly saying, the Mac port uses Cocoa for its
YM> GUI implementation.  If you call the Mac port Carbon-based, lots
YM> of the applications including those bundled with Mac OS X such as
YM> Safari.app should also be called Carbon-based.

I'll avoid calling it "Carbon-based" in the future so there's no
misunderstanding.

YM> Also, I would like to note that some of recent improvements to
YM> Mac OS X and iOS are provided outside Cocoa, especially if they
YM> are not directly related to GUI.  They are not classified as
YM> Carbon, but they are also C APIs and not provided by GNUstep.
YM> For example, Grand Central Dispatch (GCD) I mentioned in the
YM> `select' emulation without periodic polling is a C API and
YM> provided by both Mac OS X and iOS, but not by GNUstep.

YM>   http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00694.html

I recall that API was brought into Mac OS X recently and is not
available in older versions of the same OS, at least for PowerPC
architecture.  I think it makes sense to use it opportunistically, but
if using it in the NS port makes the NS port incompatible with GNUstep,
then that's a harder decision.  I'm not qualified to make that decision,
in any case.

YM> The Core Text framework I'm using for the font backend driver in
YM> the Mac port is also a C API.  Interestingly, in iOS Apple
YM> provides an advanced low-level text layout API (Core Text) only
YM> at C level, rather than copying such API (NSLayoutManager etc.)
YM> from Mac OS X Cocoa AppKit to iOS UIKit.  I think this implies
YM> Apple's preference of C API to Cocoa for advanced low-level tasks
YM> that applications such as text editors want to use.

Interesting.  So Apple's direction seems to be towards plain C APIs now,
because of the emergence of iOS, and the profitability and popularity of
that platform makes a change in that direction unlikely.  That makes
compatibility with GNUstep much harder for the NS port.  It also means
that GNU Emacs has to keep up with Apple's business choices and custom
APIs to provide a great user experience on their proprietary platform.
That seems like a difficult choice for the GNU project, and I'm sure it
will come up again in other GNU software that aims to run on Mac OS X.

I think the NS port needs to make the decision whether it will keep
trying to be compatible with GNUstep, which will make the users'
experience worse on Mac OS X, or if it will use these C APIs and lose
the GNUstep advantage.

In the latter case it may be sensible and even advantageous to GNU Emacs
to merge the Mac port's improvements into the NS port, or vice versa,
and have just one Mac OS X compatible port.  That would leave GNUstep
without a viable GNU Emacs port, though, and it may not suit your plans
for the Mac port.

So this is up to the Emacs maintainers; the NS port maintainers (at
least Adrian Robert) and developers; and possibly you, if you want to
participate in such a discussion.  FWIW, as an Emacs user on Mac OS X, I
think such a merge would benefit the Emacs users, especially if there
was a way to provide some GNUstep compatibility.  I hope all of you find
a middle ground that satisfies everyone's goals and needs.

YM> Because the Mac port already uses Cocoa AppKit for GUI, the
YM> argument about Apple's preference of Cocoa to Carbon (with
YM> respect to GUI) you made above is rather pointless.  I even have
YM> an impression that the Mac port usually behaves more like other
YM> Cocoa applications than the NS port does.

OK, I'll keep that in mind, and thank you for explaining.

Ted

Re: Mac OS-compatible ports

[YAMAMOTO Mitsuharu]

On 2012/01/01, at 23:06, Ted Zlatanov wrote:

> YM> Also, I would like to note that some of recent improvements to
> YM> Mac OS X and iOS are provided outside Cocoa, especially if they
> YM> are not directly related to GUI.  They are not classified as
> YM> Carbon, but they are also C APIs and not provided by GNUstep.
> YM> For example, Grand Central Dispatch (GCD) I mentioned in the
> YM> `select' emulation without periodic polling is a C API and
> YM> provided by both Mac OS X and iOS, but not by GNUstep.
> 
> YM>   http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00694.html
> 
> I recall that API was brought into Mac OS X recently and is not
> available in older versions of the same OS, at least for PowerPC
> architecture.  I think it makes sense to use it opportunistically, but
> if using it in the NS port makes the NS port incompatible with GNUstep,
> then that's a harder decision.  I'm not qualified to make that decision,
> in any case.

The Mac port provides a fallback using CFRunLoopSource for older
versions of Mac OS X, but again it is a C API supported by both
Mac OS X and iOS but not provided by GNUstep.

Sometimes adopting new features inspires some idea of improvement
even in fallback codes.  GCD in the `select' emulation was such a
case.  The current fallback code made after the GCD version is
more efficient than what I implemented as a `select' emulation
without periodic polling in Emacs 22 Carbon port.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Mac OS-compatible ports

[Leo]

On 2011-12-31 21:22 +0800, Ted Zlatanov wrote:
> I agree with your statement, but we're not "pushing" the NS port only
> because it's for GNUstep.  It's quite usable on Mac OS X.

I wonder how you reach that conclusion. If you don't use Emacs heavily
on a Mac, then you don't know if it is quite usable. My experience is
that it is not. John Wiegley were also disappointed by the ns-port some
months ago and he has been happy using the Mac-Port. My impression is
that Mac-Port is a piece of solid well-engineered software. It is a pity
not more Mac users can make use of it and have to resort to nonfree
software such as TextMate etc.

Cheers.
Leo

Re: Mac OS-compatible ports

[Jan Djärv]

Hello.


1 jan 2012 kl. 07:26 skrev Leo <sdl.web@gmail.com>:

> On 2011-12-31 21:22 +0800, Ted Zlatanov wrote:
>> I agree with your statement, but we're not "pushing" the NS port only
>> because it's for GNUstep.  It's quite usable on Mac OS X.
> 
> I wonder how you reach that conclusion. If you don't use Emacs heavily
> on a Mac, then you don't know if it is quite usable. My experience is
> that it is not. 

YMMV. I use Emacs every day on OSX and it is no different from using Emacs on X in my experience. But I don't use Gnus or other packages that people seems to have problems with.

      Jan D. 

Re: Mac OS-compatible ports

[Carsten Mattner]

On Sun, Jan 1, 2012 at 11:36 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello.
>
>
> 1 jan 2012 kl. 07:26 skrev Leo <sdl.web@gmail.com>:
>
>> On 2011-12-31 21:22 +0800, Ted Zlatanov wrote:
>>> I agree with your statement, but we're not "pushing" the NS port only
>>> because it's for GNUstep.  It's quite usable on Mac OS X.
>>
>> I wonder how you reach that conclusion. If you don't use Emacs heavily
>> on a Mac, then you don't know if it is quite usable. My experience is
>> that it is not.
>
> YMMV. I use Emacs every day on OSX and it is no different from
> using Emacs on X in my experience. But I don't use Gnus or other
> packages that people seems to have problems with.

Same here, except I may not miss the intl font support the Mac port
is supposed to have as an advantage.

I do need features from bzr trunk, so there's no option for me to
try the Mac port.

There may be memory leaks, but there are enough potential leaks
common to emacs regardless of ports (also seen with X on Linux).
Emacs on Linux configured as
/configure --without-selinux --without-tiff \
    --without-sound --without-dbus --without-gconf \
    --without-gsettings --without-xft --without-gsettings \
    --with-x-toolkit=no --without-gnutls
Actually I might even disable GIF, JPEG, and PNG support
as nyan-mode works in text-represenation, too, and I don't
require more than 7-bit ASCII.

Re: Mac OS-compatible ports

[Christian Lynbech]

>>>>> "Jan" == Jan Djärv <jan.h.d@swipnet.se> writes:

Jan> YMMV. I use Emacs every day on OSX and it is no different from using
Jan> Emacs on X in my experience. But I don't use Gnus or other packages
Jan> that people seems to have problems with.

I use Emacs on OSX everyday too, and I use gnus as my one and only way
to read mail, and it works quite well for me (except I am experiencing
some issues with w3m after upgrading my laptop to Lion). This is emacs24
using the trunk version and upstream gnus.


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)

Re: Mac OS-compatible ports

[Dimitri Fontaine]

Christian Lynbech <christian@defun.dk> writes:
> I use Emacs on OSX everyday too, and I use gnus as my one and only way
> to read mail, and it works quite well for me (except I am experiencing
> some issues with w3m after upgrading my laptop to Lion). This is emacs24
> using the trunk version and upstream gnus.

With Emacs24 and gnus and flyspell, on macosx, Emacs gets slower and
slower to the point that if I want to edit medium to large size C files
(more than 6k lines, say) I need to restart Emacs.

I've been told flyspell usage is what makes emacs slower and slower on
this system but didn't have anytime to spend on that yet.  It would be
awesome to see the problem fixed though :)

That's the only problem I have here and basically “I live in Emacs”.

Regards,
-- 
dim

Re: Mac OS-compatible ports

[Dave Abrahams]

on Sat Jan 07 2012, Dimitri Fontaine <dim-AT-tapoueh.org> wrote:

> Christian Lynbech <christian@defun.dk> writes:
>> I use Emacs on OSX everyday too, and I use gnus as my one and only way
>> to read mail, and it works quite well for me (except I am experiencing
>> some issues with w3m after upgrading my laptop to Lion). This is emacs24
>> using the trunk version and upstream gnus.
>
> With Emacs24 and gnus and flyspell, on macosx, Emacs gets slower and
> slower to the point that if I want to edit medium to large size C files
> (more than 6k lines, say) I need to restart Emacs.

Yeah, that's one reason John Wiegley has been using Mitsuharu's Emacs23
port.  Subprocess handling seems to actually work there.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Mac OS-compatible ports

[Dave Abrahams]

on Sat Jan 07 2012, Dimitri Fontaine <dim-AT-tapoueh.org> wrote:

> Christian Lynbech <christian@defun.dk> writes:
>> I use Emacs on OSX everyday too, and I use gnus as my one and only way
>> to read mail, and it works quite well for me (except I am experiencing
>> some issues with w3m after upgrading my laptop to Lion). This is emacs24
>> using the trunk version and upstream gnus.
>
> With Emacs24 and gnus and flyspell, on macosx, Emacs gets slower and
> slower to the point that if I want to edit medium to large size C files
> (more than 6k lines, say) I need to restart Emacs.
>
> I've been told flyspell usage is what makes emacs slower and slower on
> this system but didn't have anytime to spend on that yet.  It would be
> awesome to see the problem fixed though :)
>
> That's the only problem I have here and basically “I live in Emacs”.

Oh, I should also point out that this problem affects the usability of
GDB in Emacs 24.  It is most likely a general problem with process
handling.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Mac OS-compatible ports

[chad]

On Jan 7, 2012, at 5:09 AM, Dimitri Fontaine wrote:
> 
> With Emacs24 and gnus and flyspell, on macosx, Emacs gets slower and
> slower to the point that if I want to edit medium to large size C files
> (more than 6k lines, say) I need to restart Emacs.
> 
> I've been told flyspell usage is what makes emacs slower and slower on
> this system but didn't have anytime to spend on that yet.  It would be
> awesome to see the problem fixed though :)
> 
> That's the only problem I have here and basically “I live in Emacs”.

I don't see this problem with flyspell (which I use constantly), but I don't use gnus, and I rarely edit C code anymore.  Would you be willing to test without one of those three (flyspell, gnus, CC-mode) for a short bit?

There are some known issues that make subprocesses slow (usually hits flyspell, although it's still usually fast enough in my experience), and there have been several discussions about slowness in CC-mode due to unusual cases lately.

Thanks,
*Chad

Re: Mac OS-compatible ports

[Dimitri Fontaine]

chad <yandros@gmail.com> writes:
> There are some known issues that make subprocesses slow (usually hits

Oh, I'm using subprocesses a lot. That's a list-processes edited paste
from my current Emacs session (still fast enough, emacs-uptime is just
about less than 24h).

  *nnimap*	open	--	     (network connection to 
  *nnimap*<1>	open	--	     (network connection to 
  *nnimap*<2>	open	--	     (network connection to 
  bitlbee	run	/dev/ttys001 /bin/bash -c /sw/sbin/bitlbee ...
  ispell	run	--	     ispell -a -m -d english -B
  localhost	open	--	     (network connection to 
  nntpd		open	--	     (network connection to 
  offlineimap	run	/dev/ttys000 /bin/bash -c offlineimap -u Machine.MachineUI
  pgsql..	open	--	     (network connection to 
  shell		run	/dev/ttys002 /bin/bash --noediting -i
  tapoueh.org	open	--	     (network connection to
  terminal	run	/dev/ttys003 /bin/sh -c stty -nl ... /bin/bash

Note that I often run commands that launch a transient subprocess (M-x
compile, M-x grep, M-x ack, M-x el-get-self-update, etc), and that I
have some local facilities using shell-command-to-string or the like
too.

Here's also the last line of M-x ibuffer:

      525 buffers         15732610                  480 files, 10 processes

I'm using desktop-save-mode so that I don't have to reopen every single
file at startup, too.

> flyspell, although it's still usually fast enough in my experience), and
> there have been several discussions about slowness in CC-mode due to unusual
> cases lately.

Thing is it's usually plenty fast enough. My feeling is that it gets
slower and slower with uptime growing, so that I sometime need to
restart Emacs just to get back normal usable behavior.

Regards,
-- 
dim

Re: Mac OS-compatible ports

[Ted Zlatanov]

On Sun, 01 Jan 2012 14:26:19 +0800 Leo <sdl.web@gmail.com> wrote: 

L> On 2011-12-31 21:22 +0800, Ted Zlatanov wrote:
>> I agree with your statement, but we're not "pushing" the NS port only
>> because it's for GNUstep.  It's quite usable on Mac OS X.

L> I wonder how you reach that conclusion. 

By using the NS port on Mac OS X.

L> My experience is that it is not [usable]. John Wiegley were also
L> disappointed by the ns-port some months ago and he has been happy
L> using the Mac-Port.

OK, we'll have to disagree on that point.

L> My impression is that Mac-Port is a piece of solid well-engineered
L> software. It is a pity not more Mac users can make use of it and have
L> to resort to nonfree software such as TextMate etc.

True.  But the same can be said of the NS port, in my opinion.

Ted

Re: Mac OS-compatible ports

[chad]

On Dec 31, 2011, at 10:26 PM, Leo wrote:

> On 2011-12-31 21:22 +0800, Ted Zlatanov wrote:
>> I agree with your statement, but we're not "pushing" the NS port only
>> because it's for GNUstep.  It's quite usable on Mac OS X.
> 
> I wonder how you reach that conclusion. If you don't use Emacs heavily
> on a Mac, then you don't know if it is quite usable. My experience is
> that it is not.

I use it every day, and wrote upwards of 100k words of (jargon-heavy) english text with it last year, using flyspell and org.  I think it might have crashed a few times during 2011, but I'm not certain.  I typically rebuild the tip of the repository every few days, sometimes waiting as long as a couple weeks, so I don't run months-old instances of emacs.

> My impression is that Mac-Port is a piece of solid well-engineered software. 

That was also my impression of the mac port, except that it is also out-of-date with respect to emacs, it is becoming more out of date over time, and it contributes to the continued future of emacs only tangentially (as changes are slowly migrated into the core emacs tree).

As I said before, I am very glad that the mac port exists and provides some users with a solid emacs implementation that doesn't lack features that they need, but it does not meet those criteria for me.  Even ignoring GNUstep, all indications suggest that that situation will only worsen over time (multi-tty, org, cedet, bidi, lexbind, xembed, etc).  Until someone comes up with an actual proposal to remedy these problems, the cries like ``we should be using the Mac port instead of the NS port'' seem very much like ``after you guys build us a new bike shed, you need to make sure that you paint it the right color.''

*Chad

Re: C-g crash in C-x C-f (OSX Lion)

[Leo]

On 2011-12-20 09:12 +0800, YAMAMOTO Mitsuharu wrote:
>> Meanwhile, the Mac port is missing multi-tty, bidi editing, gnutls,
>> and lexbind.  It doesn't have integrated themes, packages, Org, or
>> CEDET (to name just a few).  It doesn't help GNUstep users at
>> all. If xembed catches on, it's unlikely that it'll ever reach the
>> Mac port.

This is because Mac port is not yet emacs-24 ready but I'm sure it is
only a matter of time.

> If you need Emacs 24-specific features on Mac OS X at the moment, then
> you can use not only the NS port, but also the other X11 builds.  And
> as I'm saying at the very beginning of the README-mac file in the Mac
> port, if the NS port is good enough for you, then you don't need to
> try the Mac port.  I guess whether the NS port is sufficient or not
> would depend on the personal usage pattern.  Especially, those who
> heavily use flyspell-mode would find the NS port insufficient.

It is not just flyspell-mode but I suspect Pymacs too
https://github.com/pinard/Pymacs/issues/5. I have recently started using
Python again and Pymacs (a dependency of rope/ropemacs) is indispensable
in setting up a top-notch python development environment.

> Also, I think I've been making rather active and valuable feedbacks in
> both bug reporting and bug fixing especially on the platform-specific
> part of Emacs, for the bugs I found through the development of the Mac
> port.

Thank you for the work.

Leo

Re: C-g crash in C-x C-f (OSX Lion)

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 20 Dec 2011 10:12:56 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> And as I'm saying at the very beginning of the README-mac file in
> the Mac port, if the NS port is good enough for you, then you don't
> need to try the Mac port.  I guess whether the NS port is sufficient
> or not would depend on the personal usage pattern.  Especially,
> those who heavily use flyspell-mode would find the NS port
> insufficient.

Another case I've heard of is (left-to-right) Complex Text Layout,
which is an *Emacs 23* feature but missing in the NS port.  A Japanese
researcher told me that he was using the Mac port because he needed
Devanagari for his research.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: C-g crash in C-x C-f (OSX Lion)

[Harald Hanche-Olsen]

[Carsten Mattner <carstenmattner@googlemail.com> (2011-12-19 16:52:12 UTC)]

> Sounds like the Mac port should be obsolete and deprecated as
> Carbon is deprecated and I'm not even sure it's in Lion anymore.

Lion ships with a tty only GNU emacs version 22.1.1.

At least, that is what I find in /usr/bin on my machine.

- Harald

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Mon, Dec 19, 2011 at 7:15 PM, Harald Hanche-Olsen
<hanche@math.ntnu.no> wrote:
> [Carsten Mattner <carstenmattner@googlemail.com> (2011-12-19 16:52:12 UTC)]
>
>> Sounds like the Mac port should be obsolete and deprecated as
>> Carbon is deprecated and I'm not even sure it's in Lion anymore.
>
> Lion ships with a tty only GNU emacs version 22.1.1.
>
> At least, that is what I find in /usr/bin on my machine.

It does, but I don't use that. It doesn't have special patches to make
key bindings I have working in the gui frontend only magically work,
does it?

Re: C-g crash in C-x C-f (OSX Lion)

[Harald Hanche-Olsen]

[Carsten Mattner <carstenmattner@googlemail.com> (2011-12-19 18:50:44 UTC)]

> On Mon, Dec 19, 2011 at 7:15 PM, Harald Hanche-Olsen
> <hanche@math.ntnu.no> wrote:
> > Lion ships with a tty only GNU emacs version 22.1.1.
> >
> > At least, that is what I find in /usr/bin on my machine.
> 
> It does, but I don't use that. It doesn't have special patches to make
> key bindings I have working in the gui frontend only magically work,
> does it?

I don't know. I don't use it myself. I was just answering a trivia
question, on the off chance that the asker really wanted to know.

ObCrash: My emacs crashes too often too. Perhaps I should get into the
habit of always having a gdb attached to my running emacs, so I can
contribute backtraces of my own.

- Harald

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

19 dec 2011 kl. 20:40 skrev Harald Hanche-Olsen:

> [Carsten Mattner <carstenmattner@googlemail.com> (2011-12-19 18:50:44 UTC)]
> 
>> On Mon, Dec 19, 2011 at 7:15 PM, Harald Hanche-Olsen
>> <hanche@math.ntnu.no> wrote:
>>> Lion ships with a tty only GNU emacs version 22.1.1.
>>> 
>>> At least, that is what I find in /usr/bin on my machine.
>> 
>> It does, but I don't use that. It doesn't have special patches to make
>> key bindings I have working in the gui frontend only magically work,
>> does it?
> 
> I don't know. I don't use it myself. I was just answering a trivia
> question, on the off chance that the asker really wanted to know.
> 
> ObCrash: My emacs crashes too often too. Perhaps I should get into the
> habit of always having a gdb attached to my running emacs, so I can
> contribute backtraces of my own.

It can't hurt.

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Mon, Dec 19, 2011 at 9:16 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
> 19 dec 2011 kl. 20:40 skrev Harald Hanche-Olsen:
>
>> [Carsten Mattner <carstenmattner@googlemail.com> (2011-12-19 18:50:44 UTC)]
>>
>>> On Mon, Dec 19, 2011 at 7:15 PM, Harald Hanche-Olsen
>>> <hanche@math.ntnu.no> wrote:
>>>> Lion ships with a tty only GNU emacs version 22.1.1.
>>>>
>>>> At least, that is what I find in /usr/bin on my machine.
>>>
>>> It does, but I don't use that. It doesn't have special patches to make
>>> key bindings I have working in the gui frontend only magically work,
>>> does it?
>>
>> I don't know. I don't use it myself. I was just answering a trivia
>> question, on the off chance that the asker really wanted to know.
>>
>> ObCrash: My emacs crashes too often too. Perhaps I should get into the
>> habit of always having a gdb attached to my running emacs, so I can
>> contribute backtraces of my own.
>
> It can't hurt.

Shouldn't gdb or another selected debugger be invocable from
the system level crash handler? This is generally possible on
Windows. At least that was the case 3 years ago.
If that's possible gdb (minus emacs .gdbinit) could be invoked
on demand.

Re: C-g crash in C-x C-f (OSX Lion)

[Adrian Robert]

> Shouldn't gdb or another selected debugger be invocable from
> the system level crash handler? This is generally possible on
> Windows. At least that was the case 3 years ago.
> If that's possible gdb (minus emacs .gdbinit) could be invoked
> on demand.

This was possible in I think 10.4 through setting Crash Reporter prefs,
but seems not present in 10.6.  Forward progress!

Re: C-g crash in C-x C-f (OSX Lion)

[Richard Stallman]

    > Haven't been able to reproduce the crash yesterday.
    > Gonna use Emacs via gdb for the rest of the day.
    > I hope the crash didn't vanish just due to differences in the generated code.

    This may be the case.  It may be an optimization issue.

If so, it is very important to track it down.

Can you find out which function the problem is in?


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Sat, Dec 17, 2011 at 7:26 PM, Richard Stallman <rms@gnu.org> wrote:
>    > Haven't been able to reproduce the crash yesterday.
>    > Gonna use Emacs via gdb for the rest of the day.
>    > I hope the crash didn't vanish just due to differences in the generated code.
>
>    This may be the case.  It may be an optimization issue.
>
> If so, it is very important to track it down.
>
> Can you find out which function the problem is in?

It doesn't "seem" to be optimization related as I can
to reliably reproduce the crash with a -O0 binary.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

For the record, it doesn't crash that easily if I do not run Emacs.app
via gdb. Usually something starts to work when run in a debugger and
not the other way around :).

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

Hello.

18 dec 2011 kl. 11:22 skrev Carsten Mattner:

> For the record, it doesn't crash that easily if I do not run Emacs.app
> via gdb. Usually something starts to work when run in a debugger and
> not the other way around :).

I ran Emacs compiled as you did, with evil-mode enabled for three hours and did not get any errors.
However, I checked in some fixes, please try that variant.

A question, you configure with this:

CFLAGS='-O0 -ggdb -g3' CC='gcc -arch i386' ./configure --with-ns
  --without-gnutls --enable-asserts

If you are on Lion, you must have a 64-bit CPU, so why are you limiting yourself to 32 bits?

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Sun, Dec 18, 2011 at 2:52 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello.
>
> 18 dec 2011 kl. 11:22 skrev Carsten Mattner:
>
>> For the record, it doesn't crash that easily if I do not run Emacs.app
>> via gdb. Usually something starts to work when run in a debugger and
>> not the other way around :).
>
> I ran Emacs compiled as you did, with evil-mode enabled for three
> hours and did not get any errors. However, I checked in some fixes,
> please try that variant.

Same configure and gcc options?

Can you send me the fixes separately to try them out in a clone of the
existing source tree?

I'm also going to build a new tree from bzr trunk for comparison.

> A question, you configure with this:
>
> CFLAGS='-O0 -ggdb -g3' CC='gcc -arch i386' ./configure --with-ns
>  --without-gnutls --enable-asserts
>
> If you are on Lion, you must have a 64-bit CPU, so why are you
> limiting yourself to 32 bits?

To keep the memory footprint low.

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

Hello.

18 dec 2011 kl. 15:35 skrev Carsten Mattner:

> On Sun, Dec 18, 2011 at 2:52 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> Hello.
>> 
>> 18 dec 2011 kl. 11:22 skrev Carsten Mattner:
>> 
>>> For the record, it doesn't crash that easily if I do not run Emacs.app
>>> via gdb. Usually something starts to work when run in a debugger and
>>> not the other way around :).
>> 
>> I ran Emacs compiled as you did, with evil-mode enabled for three
>> hours and did not get any errors. However, I checked in some fixes,
>> please try that variant.
> 
> Same configure and gcc options?
> 

Yes.

> Can you send me the fixes separately to try them out in a clone of the
> existing source tree?
> 
> I'm also going to build a new tree from bzr trunk for comparison.

If you have a tree up to date, the differences are
% bzr diff -r106693..106694


> 
>> A question, you configure with this:
>> 
>> CFLAGS='-O0 -ggdb -g3' CC='gcc -arch i386' ./configure --with-ns
>> --without-gnutls --enable-asserts
>> 
>> If you are on Lion, you must have a 64-bit CPU, so why are you
>> limiting yourself to 32 bits?
> 
> To keep the memory footprint low.

Ok, never noticed a big difference myself.  I rather have the ability to open larger files.

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Sun, Dec 18, 2011 at 2:52 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello.
>
> 18 dec 2011 kl. 11:22 skrev Carsten Mattner:
>
>> For the record, it doesn't crash that easily if I do not run Emacs.app
>> via gdb. Usually something starts to work when run in a debugger and
>> not the other way around :).
>
> I ran Emacs compiled as you did, with evil-mode enabled for three
> hours and did not get any errors.
> However, I checked in some fixes, please try that variant.

Trunk doesn't crash as easily in gdb. I suppose you fixed the issue
with the graphical frontend. Thanks a lot!

Whether that issue was the one I used for this threads Subject I'm unsure of.

Jan, what about the other crash I had posted a full backtrace of when I tried
it in a terminal?
It crashes when I do the same, but use C-g to cancel the visual selection
iniated via evil-mode in progress.

gdb ...

(gdb) run -nw

press v, do some selection, press C-g

(gdb) bt
#0  0x94fa5b42 in select$DARWIN_EXTSN ()
#1  0x00263cc2 in ns_select (nfds=5, readfds=0xbfffeda0,
writefds=0xbfffed20, exceptfds=0x0, timeout=0xbfffed00) at
nsterm.m:3493
#2  0x0021bc7d in wait_reading_process_output (time_limit=30,
microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=25806370,
wait_proc=0x0, just_wait_proc=0) at process.c:4610
#3  0x000103a5 in sit_for (timeout=120, reading=1, do_display=1) at
dispnew.c:6060
#4  0x000fa5b8 in read_char (commandflag=1, nmaps=12, maps=0xbffff170,
prev_event=25806370, used_mouse_menu=0xbffff33c, end_time=0x0) at
keyboard.c:2688#5  0x00108e7d in read_key_sequence (keybuf=0xbffff4e8,
bufsize=30, prompt=25806370, dont_downcase_last=0,
can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9300
#6  0x000f737f in command_loop_1 () at keyboard.c:1448
#7  0x001ac8d6 in internal_condition_case (bfun=0xf6e70
<command_loop_1>, handlers=25851274, hfun=0xf6480 <cmd_error>) at
eval.c:1499
#8  0x000f69cd in command_loop_2 (ignore=25806370) at keyboard.c:1159
#9  0x001ac1bf in internal_catch (tag=25849298, func=0xf6990
<command_loop_2>, arg=25806370) at eval.c:1256
#10 0x000f694b in command_loop () at keyboard.c:1138
#11 0x000f5e95 in recursive_edit_1 () at keyboard.c:758
#12 0x000f6086 in Frecursive_edit () at keyboard.c:822
#13 0x000f3e6a in main (argc=2, argv=0xbffff9c4) at emacs.c:1709
(gdb) frame 1
#1  0x00263cc2 in ns_select (nfds=5, readfds=0xbfffeda0,
writefds=0xbfffed20, exceptfds=0x0, timeout=0xbfffed00) at
nsterm.m:3493
3493        return select (nfds, readfds, writefds, exceptfds, timeout);
Current language:  auto; currently objective-c
(gdb) frame 2
#2  0x0021bc7d in wait_reading_process_output (time_limit=30,
microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=25806370,
wait_proc=0x0, just_wait_proc=0) at process.c:4610
4610              nfds = ns_select
Current language:  auto; currently c(gdb) frame 3
#3  0x000103a5 in sit_for (timeout=120, reading=1, do_display=1) at
dispnew.c:60606060      wait_reading_process_output (sec, usec,
reading ? -1 : 1, do_display,
(gdb) frame 4
#4  0x000fa5b8 in read_char (commandflag=1, nmaps=12, maps=0xbffff170,
prev_event=25806370, used_mouse_menu=0xbffff33c, end_time=0x0) at
keyboard.c:2688
2688              tem0 = sit_for (make_number (timeout), 1, 1);
(gdb) frame 5#5  0x00108e7d in read_key_sequence (keybuf=0xbffff4e8,
bufsize=30, prompt=25806370, dont_downcase_last=0,
can_return_switch_frame=1, fix_current_buffer=1) at
keyboard.c:93009300                key = read_char (NILP (prompt),
nmaps,
(gdb) frame 6
#6  0x000f737f in command_loop_1 () at keyboard.c:14481448          i
= read_key_sequence (keybuf, sizeof keybuf / sizeof keybuf[0],
(gdb)

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

Hello.

18 dec 2011 kl. 18:58 skrev Carsten Mattner:

> On Sun, Dec 18, 2011 at 2:52 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> Hello.
>> 
>> 18 dec 2011 kl. 11:22 skrev Carsten Mattner:
>> 
>>> For the record, it doesn't crash that easily if I do not run Emacs.app
>>> via gdb. Usually something starts to work when run in a debugger and
>>> not the other way around :).
>> 
>> I ran Emacs compiled as you did, with evil-mode enabled for three
>> hours and did not get any errors.
>> However, I checked in some fixes, please try that variant.
> 
> Trunk doesn't crash as easily in gdb.

If you didn't run trunk, what did you run?

> 
> Jan, what about the other crash I had posted a full backtrace of when I tried
> it in a terminal?
> It crashes when I do the same, but use C-g to cancel the visual selection
> iniated via evil-mode in progress.

Is this with the latest trunk started with -Q?  I can't reproduce it.

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Mon, Dec 19, 2011 at 7:32 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello.
>
> 18 dec 2011 kl. 18:58 skrev Carsten Mattner:
>
>> On Sun, Dec 18, 2011 at 2:52 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>> Hello.
>>>
>>> 18 dec 2011 kl. 11:22 skrev Carsten Mattner:
>>>
>>>> For the record, it doesn't crash that easily if I do not run Emacs.app
>>>> via gdb. Usually something starts to work when run in a debugger and
>>>> not the other way around :).
>>>
>>> I ran Emacs compiled as you did, with evil-mode enabled for three
>>> hours and did not get any errors.
>>> However, I checked in some fixes, please try that variant.
>>
>> Trunk doesn't crash as easily in gdb.
>
> If you didn't run trunk, what did you run?

That was trunk from when I started to test the crash
and I didn't want to change the tree (bzr lingo branch)
for reproducability.

$ bzr revno 106680
vs
$ bzr revno 106694

>> Jan, what about the other crash I had posted a full backtrace of when I tried
>> it in a terminal?
>> It crashes when I do the same, but use C-g to cancel the visual selection
>> iniated via evil-mode in progress.
>
> Is this with the latest trunk started with -Q?  I can't reproduce it.

Latest trunk but without evil-mode it doesn't crash as described.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

Jan,

right now with rev 106700 I wasn't yet able to make it crash
in -nw mode as evidenced in the backtrace posted yesterday.

I'm running the graphical frontend in gdb today, but maybe should
do so with the -nw frontend instead.

Thanks for your help and fixes. Appreciated.

Re: C-g crash in C-x C-f (OSX Lion)

[Jan D.]

Carsten Mattner skrev 2011-12-19 12:04:
> On Mon, Dec 19, 2011 at 7:32 AM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>> Hello.
>>
>> 18 dec 2011 kl. 18:58 skrev Carsten Mattner:
>>
>>> On Sun, Dec 18, 2011 at 2:52 PM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>>> Hello.
>>>>
>>>> 18 dec 2011 kl. 11:22 skrev Carsten Mattner:
>>>>
>>>>> For the record, it doesn't crash that easily if I do not run Emacs.app
>>>>> via gdb. Usually something starts to work when run in a debugger and
>>>>> not the other way around :).
>>>>
>>>> I ran Emacs compiled as you did, with evil-mode enabled for three
>>>> hours and did not get any errors.
>>>> However, I checked in some fixes, please try that variant.
>>>
>>> Trunk doesn't crash as easily in gdb.
>>
>> If you didn't run trunk, what did you run?
>
> That was trunk from when I started to test the crash
> and I didn't want to change the tree (bzr lingo branch)
> for reproducability.
>
> $ bzr revno 106680
> vs
> $ bzr revno 106694

Ok, that makes sense.

>
>>> Jan, what about the other crash I had posted a full backtrace of when I tried
>>> it in a terminal?
>>> It crashes when I do the same, but use C-g to cancel the visual selection
>>> iniated via evil-mode in progress.
>>
>> Is this with the latest trunk started with -Q?  I can't reproduce it.
>
> Latest trunk but without evil-mode it doesn't crash as described.

I think there might be a memory corruption going on here.  Maybe the 
changes made moved it somewhere else.

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Mon, Dec 19, 2011 at 4:55 PM, Jan D. <jan.h.d@swipnet.se> wrote:
> Carsten Mattner skrev 2011-12-19 12:04:
>
>> On Mon, Dec 19, 2011 at 7:32 AM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>>
>>> Hello.
>>>
>>> 18 dec 2011 kl. 18:58 skrev Carsten Mattner:
>>>
>>>> On Sun, Dec 18, 2011 at 2:52 PM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>>>>
>>>>> Hello.
>>>>>
>>>>> 18 dec 2011 kl. 11:22 skrev Carsten Mattner:
>>>>>
>>>>>> For the record, it doesn't crash that easily if I do not run Emacs.app
>>>>>> via gdb. Usually something starts to work when run in a debugger and
>>>>>> not the other way around :).
>>>>>
>>>>>
>>>>> I ran Emacs compiled as you did, with evil-mode enabled for three
>>>>> hours and did not get any errors.
>>>>> However, I checked in some fixes, please try that variant.
>>>>
>>>>
>>>> Trunk doesn't crash as easily in gdb.
>>>
>>>
>>> If you didn't run trunk, what did you run?
>>
>>
>> That was trunk from when I started to test the crash
>> and I didn't want to change the tree (bzr lingo branch)
>> for reproducability.
>>
>> $ bzr revno 106680
>> vs
>> $ bzr revno 106694
>
>
> Ok, that makes sense.
>
>
>>
>>>> Jan, what about the other crash I had posted a full backtrace of when I
>>>> tried
>>>> it in a terminal?
>>>> It crashes when I do the same, but use C-g to cancel the visual
>>>> selection
>>>> iniated via evil-mode in progress.
>>>
>>>
>>> Is this with the latest trunk started with -Q?  I can't reproduce it.
>>
>>
>> Latest trunk but without evil-mode it doesn't crash as described.
>
>
> I think there might be a memory corruption going on here.  Maybe the changes
> made moved it somewhere else.

So I guess we should concentrate on the reproducable crash in
the old tree with the older revno.

Any stack frames you want me to inspect?
Maybe we can pinpoint another should-not-happen fault.

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

Hello.

19 dec 2011 kl. 17:53 skrev Carsten Mattner:

> So I guess we should concentrate on the reproducable crash in
> the old tree with the older revno.
> 
> Any stack frames you want me to inspect?
> Maybe we can pinpoint another should-not-happen fault.

I think we must approach this from another angle.  The stack traces available can't pinpoint the source of the memory problem (if indeed it exists).  I shall run Pauls static checking and see if valgrind gives anything.

Thanks for the offer.

	Jan D.
 

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Mon, Dec 19, 2011 at 6:48 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello.
>
> 19 dec 2011 kl. 17:53 skrev Carsten Mattner:
>
>> So I guess we should concentrate on the reproducable crash in
>> the old tree with the older revno.
>>
>> Any stack frames you want me to inspect?
>> Maybe we can pinpoint another should-not-happen fault.
>
> I think we must approach this from another angle.  The stack traces available can't pinpoint the source of the memory problem (if indeed it exists).  I shall run Pauls static checking and see if valgrind gives anything.
>
> Thanks for the offer.

That means I don't have to keep the old app bundle (crashing one)
around, do I?

Re: C-g crash in C-x C-f (OSX Lion)

[Jan Djärv]

Hello.

19 dec 2011 kl. 19:51 skrev Carsten Mattner:

> On Mon, Dec 19, 2011 at 6:48 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> Hello.
>> 
>> 19 dec 2011 kl. 17:53 skrev Carsten Mattner:
>> 
>>> So I guess we should concentrate on the reproducable crash in
>>> the old tree with the older revno.
>>> 
>>> Any stack frames you want me to inspect?
>>> Maybe we can pinpoint another should-not-happen fault.
>> 
>> I think we must approach this from another angle.  The stack traces available can't pinpoint the source of the memory problem (if indeed it exists).  I shall run Pauls static checking and see if valgrind gives anything.
>> 
>> Thanks for the offer.
> 
> That means I don't have to keep the old app bundle (crashing one)
> around, do I?

No, you can discard it.

	Jan D.

Re: C-g crash in C-x C-f (OSX Lion)

[Eli Zaretskii]

> Date: Sun, 18 Dec 2011 11:22:10 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> For the record, it doesn't crash that easily if I do not run Emacs.app
> via gdb. Usually something starts to work when run in a debugger and
> not the other way around :).

You should be grateful for this "reverse Heisenbug".

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Sun, Dec 18, 2011 at 5:54 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 18 Dec 2011 11:22:10 +0100
>> From: Carsten Mattner <carstenmattner@googlemail.com>
>> Cc: Emacs developers <emacs-devel@gnu.org>
>>
>> For the record, it doesn't crash that easily if I do not run Emacs.app
>> via gdb. Usually something starts to work when run in a debugger and
>> not the other way around :).
>
> You should be grateful for this "reverse Heisenbug".

The user in me is, the software developer isn't as any kind of
uncertainty is a source of sleepless nights and head scratching.

If Gene Roddenberry is reading this, can he please reveal the
functionality of the Heisenberg Compensator so that we
can replicate it in gcc so that it crashes reliably for everybody?

Re: C-g crash in C-x C-f (OSX Lion)

[Richard Stallman]

    It doesn't "seem" to be optimization related as I can
    to reliably reproduce the crash with a -O0 binary.

That is a relief.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: C-g crash in C-x C-f (OSX Lion)

[Carsten Mattner]

On Mon, Dec 19, 2011 at 3:51 AM, Richard Stallman <rms@gnu.org> wrote:
>    It doesn't "seem" to be optimization related as I can
>    to reliably reproduce the crash with a -O0 binary.
>
> That is a relief.

Another relief is that Jan has fixed this issue which was
only reproduceable if emacs nextstep frontend is run
on Mac OS X from within gdb. There are other crashes,
and I'm trying to help reproduce and provide enough info
for them to be corrected.