Segfault in objc_msgSend while closing lots of documents

[GoogleCodeExporter]

What steps will reproduce the problem?

Not 100% reproducible, but it's related to closing a large number of
documents.  I usually get this at the end of the day when I <Esc>:q<Enter>
lots of unmodified documents, while there are some dirty ones minimized
(but don't think it's related, just coincidental).

I've never had a problem with just one document open, if it lets me get
down to the last 3 windows or so then I know I'll be able to close them
just fine.  Almost all my documents are opened using mvim.

What is the expected output? What do you see instead?

I get a crash (attached).

What version of MacVim are you using (check the "MacVim->About MacVim" menu
item)? On which processor and version of OS X (check the "Apple Menu->About
This Mac" menu item)?

Snapshot 36, on OSX 10.5.5 X86 (MacBook 2.4GHz).

Please provide any additional information below.

I've gotten almost identical crashes about once a week since September. 
The only difference in the crashed thread is the offset within
ReceiveNextEventCommon.  I have a total of 18 crashes for SIGSEGV since 9/10.

Other apps usually open include Firefox 3, iTunes, Mail.app, Skype, Adium,
NeoOffice, and Acrobat Reader.  Some nonstandard menubar items including
TunnelBlick and MenuMeters.

Let me know any more information I can get you.  I'll be glad to compile
myself or run under gdb if it would be helpful.

Original issue reported on code.google.com by tsha...@gmail.com on 21 Oct 2008 at 8:13

Attachments:

• MacVim_2008-10-21-123036_Pilot.crash

[GoogleCodeExporter]

Unfortunately the crash log does not give any hints as to what is causing the 
crash.  Provided you have the 
time and the bug is "sufficiently reproducible" I'd firstly be interested to 
know when the bug was introduced.

Can you reproduce the crash with snapshot 35?  If so, does it happen with 
snapshot 34?  If so, does it finally 
happen with stable 1.2?  (Older snapshots can be downloaded from the 
"Downloads" tab but you have to 
search through "All downloads".)

Thanks,
Björn

Original comment by bjorn.winckler@gmail.com on 22 Oct 2008 at 1:47

[GoogleCodeExporter]

It happened again today while I was away from the machine, but running under 
gdb.cd 

With a little help from
http://www.sealiesoftware.com/blog/archive/2008/09/22/objc_explain_So_you_crashe
d_in_objc_msgSend.html

(gdb) bt
#0  0x9660a688 in objc_msgSend ()
#1  0x91b311ba in __NSFireTimer ()
#2  0x906b2b45 in CFRunLoopRunSpecific ()
#3  0x906b2cf8 in CFRunLoopRunInMode ()
#4  0x925cd480 in RunCurrentEventLoopInMode ()
#5  0x925cd1d2 in ReceiveNextEventCommon ()
#6  0x925cd10d in BlockUntilNextEventMatchingListInMode ()
#7  0x936a83ed in _DPSNextEvent ()
#8  0x936a7ca0 in -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#9  0x936a0cdb in -[NSApplication run] ()
#10 0x9366df14 in NSApplicationMain ()
#11 0x00002a3c in _start ()
#12 0x00002969 in start ()
(gdb) info frame
Stack level 0, frame at 0xbfffe4c0:
 eip = 0x9660a688 in objc_msgSend; saved eip 0x91b311ba
 called by frame at 0xbfffe560
 Arglist at 0xbfffe4b8, args:
 Locals at 0xbfffe4b8, Previous frame's sp is 0xbfffe4c0
 Saved registers:
  eip at 0xbfffe4bc

(gdb) p $rdi
$2 = void
(gdb) x $ecx
0x966bc514 <__FUNCTION__.12370+721332>:  "retain"

With a little help from http://developer.apple.com/technotes/tn2004/tn2124.html

(gdb) call (void) CFShow(*(int*)($ebp+8))
<CFRunLoopTimer 0x16131bb0 [0xa005c1a0]>{locked = No, valid = Yes, interval = 
0, next
fire date = 246404954, order = 0, callout = ??? (0x91b31150), context =
<CFRunLoopTimer context 0x14ad6fa0>}
(gdb) call (void) CFShow(0xa005c1a0)
<CFAllocator 0xa005c1a0 [0xa005c1a0]>{info = 0x68000}

Nothing of note was readily available at those memory addresses, but it does 
confirm
that the crash is something to the effect of [0 retain] being called from 
within a timer.

I'm now running Stable 1.2 and will report back whether it happens again.

Original comment by tsha...@gmail.com on 22 Oct 2008 at 10:32

[GoogleCodeExporter]

You said the crash happened when you were "away from the machine" which sounds 
like you weren't closing any 
windows when it crashed.  Did it just crash when it was doing nothing?

Thanks for the backtrace...unfortunately in this sort of situation it does not 
shed much light on what really 
caused the crash.  It is OK to send messages (such as "retain") to nil in Cocoa 
so that is not the problem.  Still, it 
is good that you provide as much info as possible since one innocent little 
thing may catch my eye.

Anyway, let me know if this is a new bug or not and I'll think what step to 
take next.

Original comment by bjorn.winckler@gmail.com on 23 Oct 2008 at 6:37

[GoogleCodeExporter]

Re-reading your last post I got a bit confused: did the last crash happen with 
stable 1.2 or did you just mean 
that you've now started running stable 1.2 and the above crash was in snap 36?  
I am guessing the latter, but I 
just want to make sure.

Original comment by bjorn.winckler@gmail.com on 23 Oct 2008 at 6:39

[GoogleCodeExporter]

Comment 2 was still using Snapshot 36.  To clarify "away from the machine", I
probably closed a window, walked away, and when I got back it had crashed.

I started using stable 1.2 after reporting comment 2, and haven't had any 
issues yet.

Original comment by tsha...@gmail.com on 23 Oct 2008 at 6:48

[GoogleCodeExporter]

Any news on whether this bug is present in stable 1.2 or not?

Original comment by bjorn.winckler@gmail.com on 2 Nov 2008 at 11:01

[GoogleCodeExporter]

It hasn't happened with stable 1.2 even though I've gone through the "closing 
lots of
documents" behavior expecting it to crash three times now.  Next up I suppose 
I'll
try snapshot 35.

Original comment by tsha...@gmail.com on 3 Nov 2008 at 3:09

[GoogleCodeExporter]

Most of November was spent on Stable 1.2 with no issues.  I upgraded to 
Snapshot 39
over the weekend, and hit the crash again.  I have more information though -- I 
had a
window in the background in which I know file on disk has changed, and another 
window
on top of it.  The crash occured as I was trying to click "Load" in the "file
changed" sheet, after closing the unmodified window on top.

Process:         MacVim [5314]
Path:            /Applications/MacVim.app/Contents/MacOS/MacVim
Identifier:      org.vim.MacVim
Version:         7.2 (39)
Code Type:       X86 (Native)
Parent Process:  Vim [5313]

Date/Time:       2008-12-01 14:09:37.880 -0800
OS Version:      Mac OS X 10.5.5 (9F33)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000c57f662b
Crashed Thread:  0

Thread 0 Crashed:
0   libobjc.A.dylib                 0x9660a688 objc_msgSend + 24
1   com.apple.CoreFoundation        0x906b2b45 CFRunLoopRunSpecific + 4469
2   com.apple.CoreFoundation        0x906b2cf8 CFRunLoopRunInMode + 88
3   com.apple.HIToolbox             0x925cd480 RunCurrentEventLoopInMode + 283
4   com.apple.HIToolbox             0x925cd299 ReceiveNextEventCommon + 374
5   com.apple.HIToolbox             0x925cd10d 
BlockUntilNextEventMatchingListInMode + 106
6   com.apple.AppKit                0x936a83ed _DPSNextEvent + 657
7   com.apple.AppKit                0x936a7ca0 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
8   com.apple.AppKit                0x936a0cdb -[NSApplication run] + 795
9   com.apple.AppKit                0x9366df14 NSApplicationMain + 574
10  org.vim.MacVim                  0x0000240b _start + 209
11  org.vim.MacVim                  0x00002339 start + 41

Original comment by tsha...@gmail.com on 1 Dec 2008 at 10:17

[GoogleCodeExporter]

Hi, I crashed with a similar repro.  Here's the scenario as best as I can 
remember.

- 2.4 GHz macbook pro with 2G RAM running Leopard 10.5.5
- I have an external monitor on the right of my laptop
- The external monitor is primary, i.e. the menu bar is on it
- I have 8 spaces (virtual windows) setup
- In one space I had a mvim window, potentially on the left screen (laptop)
- In another space I had two mvim windows side by side on the right screen; they
didn't appear to be overlapping, though their shadows may have been
- I renamed one of the open buffers in a terminal, then ran :e <new filename>
- When I closed both of the side-by-side windows and then mvim crashed.

Attached is the crash log.

Thanks!

Original comment by roberto....@gmail.com on 3 Dec 2008 at 12:53

Attachments:

• MacVim_2008-12-02-140103_bolt.crash

[GoogleCodeExporter]

tshatch: It seems we can assume the bug was introduced after snapshot 33 (which 
stable 1.2 is based on)...so 
that is good to know.  I'll think about what to test next and get back to you.

roberto: Thanks for the report.

Original comment by bjorn.winckler@gmail.com on 3 Dec 2008 at 12:20

[GoogleCodeExporter]

Just a thought: are you running with Quickstart enabled?  If so, please disable 
it and see if the problems persist 
(Quickstart is not present in the stable build).  (I haven't got high hopes for 
this one, but it is worth a try.)

Original comment by bjorn.winckler@gmail.com on 3 Dec 2008 at 5:14

[GoogleCodeExporter]

I just got Snapshot 35 to crash, with the same traceback (I'll turn off 
quickstart
and start using the latest snapshot now, unless you have other advice).  I 
closed out
lots of windows earlier, and had high hopes because it didn't repro the crash.  
Just
now I had two windows, both launched using the command line mvim script (which 
is the
usual way I open the first tab in a window):

[filea.py, fileb.py, filec.py], all of which were saved (each had been loaded 
using
:tabe)
[git-commit.tmp], which I edited and :wq.

As I hit :wq, the git-commit.tmp window went away, the swap file went away, and 
the
next time I tried to touch the other window, I got a beachball with a crash.

Original comment by tsha...@gmail.com on 7 Dec 2008 at 10:55

Attachments:

• MacVim_2008-12-07-144733_Pilot.crash

[GoogleCodeExporter]

Using snapshot 39, quick start still enabled, I got a slightly different crash. 
 I'm
assuming it's the same culprit.  If not I'll create a new issue.

Process:         MacVim [224]
Path:            /Applications/MacVim.app/Contents/MacOS/MacVim
Identifier:      org.vim.MacVim
Version:         7.2 (39)
Code Type:       X86 (Native)
Parent Process:  Vim [222]

Date/Time:       2008-12-08 12:03:31.904 -0800
OS Version:      Mac OS X 10.5.5 (9F33)
Report Version:  6

Exception Type:  EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Crashed Thread:  0

Application Specific Information:
objc[224]: FREED(id): message retain sent to freed object=0x585bb0

Thread 0 Crashed:
0   libobjc.A.dylib                 0x965fabfa _objc_error + 116
1   libobjc.A.dylib                 0x965fac30 __objc_error + 52
2   libobjc.A.dylib                 0x965f9637 _freedHandler + 58
3   com.apple.Foundation            0x91b311ba __NSFireTimer + 106
4   com.apple.CoreFoundation        0x906b2b45 CFRunLoopRunSpecific + 4469
5   com.apple.CoreFoundation        0x906b2cf8 CFRunLoopRunInMode + 88
6   com.apple.HIToolbox             0x925cd480 RunCurrentEventLoopInMode + 283
7   com.apple.HIToolbox             0x925cd299 ReceiveNextEventCommon + 374
8   com.apple.HIToolbox             0x925cd10d 
BlockUntilNextEventMatchingListInMode + 106
9   com.apple.AppKit                0x936a83ed _DPSNextEvent + 657
10  com.apple.AppKit                0x936a7ca0 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
11  com.apple.AppKit                0x936a0cdb -[NSApplication run] + 795
12  com.apple.AppKit                0x9366df14 NSApplicationMain + 574
13  org.vim.MacVim                  0x0000240b _start + 209
14  org.vim.MacVim                  0x00002339 start + 41

Original comment by tsha...@gmail.com on 8 Dec 2008 at 8:16

[GoogleCodeExporter]

Scratch that, I'm using snapshot 39 with quickstart off.

Original comment by tsha...@gmail.com on 8 Dec 2008 at 8:17

[GoogleCodeExporter]

I'm starting to get some ideas as to what may be going on here so I put 
together a binary which logs a bit more 
information and I'd like to ask you to use this for the next couple of days.  
Download here:

http://bjorn.winckler.googlepages.com/MacVim-081209.zip

It is an Intel-only build, huge version with cscope and python (but no ruby).  
It doesn't log too much stuff, just 
make sure to initially start it from Finder (else all the logs will appear on 
your Terminal which is annoying).  Once 
MacVim has started it is safe to use the mvim script (logs will go to console 
as long as the first window is started 
from finder).

tshatch: the latest bug is likely the same one despite a different call stack.  
Just to be clear: that crash happened 
with Quickstart disabled, right?

Please keep Quickstart off for now.

When there is a crash, open Console.app and copy whatever info MacVim logged, 
then send it to me.  Thanks!

Original comment by bjorn.winckler@gmail.com on 9 Dec 2008 at 6:58

[GoogleCodeExporter]

tshatch (and roberto): Could you please zip up your .vim folder and email it 
and your .vimrc/.gvimrc files to my 
gmail account?  It may be that something in there will allow me to recreate the 
problem on my machine as well.  
Thank you.

Original comment by bjorn.winckler@gmail.com on 9 Dec 2008 at 7:34

[GoogleCodeExporter]

Have either of you had any crashes yet with the binary I uploaded?

I've had no crashes over here using Tim's runtime files yet so I doubt they 
have anything to do with it...

Original comment by bjorn.winckler@gmail.com on 15 Dec 2008 at 9:16

[GoogleCodeExporter]

No crashes yet, but I've been traveling most of last week (so not editing much, 
and
with only one screen).

Original comment by tsha...@gmail.com on 16 Dec 2008 at 1:07

[GoogleCodeExporter]

Aha! Still with only one screen, closing the last window (crash still 
objc_msgSend + 24):

12/15/08 6:19:07 PM MacVim[335] [scheduleClose] Delay removal of vim controller
(pid=2872) 
12/15/08 6:19:07 PM MacVim[335] [handleMessage:data:] CloseWindowMsgID received
(pid=2872) 
12/15/08 6:19:07 PM MacVim[335] [removeVimController:] Remove vim controller
(pid=2872 count=8) 
12/15/08 6:19:45 PM MacVim[335] [scheduleClose] Delay removal of vim controller
(pid=1100) 
12/15/08 6:19:45 PM MacVim[335] [handleMessage:data:] CloseWindowMsgID received
(pid=1100) 
12/15/08 6:19:45 PM MacVim[335] [removeVimController:] Remove vim controller
(pid=1100 count=7) 
12/15/08 6:19:48 PM MacVim[335] [scheduleClose] Delay removal of vim controller
(pid=334) 
12/15/08 6:19:48 PM MacVim[335] [handleMessage:data:] CloseWindowMsgID received
(pid=334) 
12/15/08 6:19:48 PM MacVim[335] [removeVimController:] Remove vim controller 
(pid=334
count=6) 
12/15/08 6:28:03 PM MacVim[335] [scheduleClose] Delay removal of vim controller
(pid=1728) 
12/15/08 6:28:03 PM MacVim[335] [handleMessage:data:] CloseWindowMsgID received
(pid=1728) 
12/15/08 6:28:03 PM MacVim[335] [removeVimController:] Remove vim controller
(pid=1728 count=5) 
12/15/08 6:33:41 PM MacVim[335] [scheduleClose] Delay removal of vim controller
(pid=2280) 
12/15/08 6:33:41 PM MacVim[335] [handleMessage:data:] CloseWindowMsgID received
(pid=2280) 
12/15/08 6:33:41 PM MacVim[335] [removeVimController:] Remove vim controller
(pid=2280 count=4) 
12/15/08 6:33:42 PM MacVim[335] [scheduleClose] Delay removal of vim controller
(pid=2274) 
12/15/08 6:33:42 PM MacVim[335] [handleMessage:data:] CloseWindowMsgID received
(pid=2274) 
12/15/08 6:33:42 PM MacVim[335] [removeVimController:] Remove vim controller
(pid=2274 count=3) 
12/15/08 6:40:45 PM MacVim[335] [connectBackend:pid:] Add vim controller 
(pid=3180
index=2) 
12/15/08 6:40:53 PM MacVim[335] [scheduleClose] Delay removal of vim controller
(pid=3180) 
12/15/08 6:40:53 PM MacVim[335] [handleMessage:data:] CloseWindowMsgID received
(pid=3180) 
12/15/08 6:40:54 PM MacVim[335] [removeVimController:] Remove vim controller
(pid=3180 count=3) 
12/15/08 6:40:59 PM MacVim[335] [connectBackend:pid:] Add vim controller 
(pid=3267
index=2) 
12/15/08 6:41:04 PM MacVim[335] [scheduleClose] Delay removal of vim controller
(pid=3267) 
12/15/08 6:41:04 PM MacVim[335] [handleMessage:data:] CloseWindowMsgID received
(pid=3267) 
12/15/08 6:41:04 PM MacVim[335] [removeVimController:] Remove vim controller
(pid=3267 count=3) 
12/15/08 6:46:03 PM MacVim[335] [scheduleClose] Delay removal of vim controller
(pid=2699) 
12/15/08 6:46:03 PM MacVim[335] [handleMessage:data:] CloseWindowMsgID received
(pid=2699) 
12/15/08 6:46:03 PM MacVim[335] [removeVimController:] Remove vim controller
(pid=2699 count=2)

Original comment by tsha...@gmail.com on 16 Dec 2008 at 2:47

[GoogleCodeExporter]

And again,

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000c0067697
Crashed Thread:  0

Thread 0 Crashed:
0   libobjc.A.dylib                 0x9660a688 objc_msgSend + 24
1   com.apple.CoreFoundation        0x906b2b45 CFRunLoopRunSpecific + 4469
...

12/18/08 10:25:18 AM MacVim[3354] [connectBackend:pid:] Add vim controller 
(pid=16501
index=4) 
12/18/08 10:25:20 AM MacVim[3354] [scheduleClose] Delay removal of vim 
controller
(pid=16501) 
12/18/08 10:25:20 AM MacVim[3354] [handleMessage:data:] CloseWindowMsgID 
received
(pid=16501) 
12/18/08 10:25:20 AM MacVim[3354] [removeVimController:] Remove vim controller
(pid=16501 count=5) 
12/18/08 10:25:24 AM MacVim[3354] [connectBackend:pid:] Add vim controller 
(pid=16527
index=4) 
12/18/08 10:26:03 AM MacVim[3354] [scheduleClose] Delay removal of vim 
controller
(pid=16527) 
12/18/08 10:26:03 AM MacVim[3354] [handleMessage:data:] CloseWindowMsgID 
received
(pid=16527) 
12/18/08 10:26:03 AM MacVim[3354] [removeVimController:] Remove vim controller
(pid=16527 count=5) 
12/18/08 10:26:30 AM MacVim[3354] [connectBackend:pid:] Add vim controller 
(pid=16903
index=4) 
12/18/08 10:26:34 AM MacVim[3354] [scheduleClose] Delay removal of vim 
controller
(pid=16903) 
12/18/08 10:26:34 AM MacVim[3354] [handleMessage:data:] CloseWindowMsgID 
received
(pid=16903) 
12/18/08 10:26:34 AM MacVim[3354] [removeVimController:] Remove vim controller
(pid=16903 count=5) 
12/18/08 10:26:38 AM MacVim[3354] [scheduleClose] Delay removal of vim 
controller
(pid=11170) 
12/18/08 10:26:38 AM MacVim[3354] [handleMessage:data:] CloseWindowMsgID 
received
(pid=11170) 
12/18/08 10:26:38 AM MacVim[3354] [removeVimController:] Remove vim controller
(pid=11170 count=4) 

Original comment by tsha...@gmail.com on 18 Dec 2008 at 6:29

[GoogleCodeExporter]

Thanks.  Unfortunately these logs do not point at the bug I was suspecting.  
Well...that's also a good thing since I 
now know to look somewhere else.  I'll keep thinking about it...

Original comment by bjorn.winckler@gmail.com on 18 Dec 2008 at 6:38

[GoogleCodeExporter]

Happened again with snapshot 42.  objc_msgSend+24 same as before.  Console log 
shows:

1/21/09 3:32:43 PM Vim[15277] WARNING[connectionDidDie:]: Main connection was 
lost
before process had a chance to terminate; preserving swap files. 
1/21/09 3:32:43 PM Vim[16626] WARNING[connectionDidDie:]: Main connection was 
lost
before process had a chance to terminate; preserving swap files. 
1/21/09 3:32:43 PM Vim[12362] WARNING[connectionDidDie:]: Main connection was 
lost
before process had a chance to terminate; preserving swap files. 
1/21/09 3:32:43 PM Vim[16497] WARNING[connectionDidDie:]: Main connection was 
lost
before process had a chance to terminate; preserving swap files. 

Original comment by tsha...@gmail.com on 21 Jan 2009 at 11:40

[GoogleCodeExporter]

Thanks for keeping me updated. Maybe you can try some "debugging" on your 
machine since I can't reproduce 
this bug.  In particular, I was thinking you could enable zombies as described 
here:

http://developer.apple.com/technotes/tn2004/tn2124.html#SECFOUNDATION

and to some extent, also here:

http://weblog.bignerdranch.com/?p=2

Basically, just set the environment variable NSZombieEnabled to YES and then 
start MacVim using 'mvim' (you'll 
have to make sure you set the variable before starting MacVim [Quit if its 
already open] and that you start MacVim 
from the same terminal window).  Anyway, this was just a thought; if the 
problem is that some object is getting 
released too many times (as seemed to be the case from some of those crash 
logs) then this may help pinpoint 
the problem.

Original comment by bjorn.winckler@gmail.com on 22 Jan 2009 at 9:06

[GoogleCodeExporter]

I set up some flags as described in the links Bjorn mentioned in comment 23,

$ gdb /Applications/MacVim.app/Contents/MacOS/MacVim
(gdb) run -NSScriptingDebugLogLevel 1 -NSTraceEvents YES
...

 and was able to reproduce the crash after a day or so.  Here's what the log says (I
was closing a tab with Cmd-W, I don't remember if it was the last one in a 
window or
not):

2009-10-23 10:31:56.827 MacVim[23463:a0f] Received event: KeyDown at: 
531.0,377.0
time: 913238221182000 flags: 0x100108 win: 0 ctxt: 26173 data: 0,252,119,13,119
2009-10-23 10:31:56.827 MacVim[23463:a0f]     In Application: NSEvent: 
type=KeyDown
loc=(0,610) time=913238.2 flags=0x100108 win=0x0 winNum=71411 ctxt=0x26173 
chars="w"
unmodchars="w" repeat=0 keyCode=13
2009-10-23 10:31:56.853 MacVim[23463:a0f] timeout = 62835892083.146057 seconds, 
mask
= ffffffff, dequeue = 1, mode = kCFRunLoopDefaultMode
2009-10-23 10:31:56.854 MacVim[23463:a0f] Received event: KeyUp at: 531.0,377.0 
time:
913238349172000 flags: 0x100108 win: 0 ctxt: 26173 data: 0,252,119,13,119
2009-10-23 10:31:56.854 MacVim[23463:a0f]     In Application: NSEvent: 
type=KeyUp
loc=(0,610) time=913238.3 flags=0x100108 win=0x0 winNum=71411 ctxt=0x26173 
chars="w"
unmodchars="w" repeat=0 keyCode=13
2009-10-23 10:31:56.855 MacVim[23463:a0f] timeout = 62835892083.144897 seconds, 
mask
= ffffffff, dequeue = 1, mode = kCFRunLoopDefaultMode
2009-10-23 10:31:57.453 MacVim[23463:a0f] Received event: FlagsChanged at:
587.0,284.0 time: 913238949182000 flags: 0x100 win: 0 ctxt: 26173
2009-10-23 10:31:57.454 MacVim[23463:a0f]     In Application: NSEvent:
type=FlagsChanged loc=(0,800) time=913238.9 flags=0x100 win=0x0 winNum=0 
ctxt=0x26173
keyCode=55
2009-10-23 10:31:57.454 MacVim[23463:a0f] timeout = 62835892082.545303 seconds, 
mask
= ffffffff, dequeue = 1, mode = kCFRunLoopDefaultMode
2009-10-23 10:31:57.554 MacVim[23463:a0f] *** -[MMTextViewHelper retain]: 
message
sent to deallocated instance 0x30d76a30

The backtrace is uninteresting (normal message-loop stuff).  This is in 
Snapshot 49.

Original comment by tsha...@gmail.com on 23 Oct 2009 at 5:38

[GoogleCodeExporter]

Aha!  Now we're getting somewhere.  I think I've found the bug so I patched it 
and built a new binary for you to 
try:

http://rapidshare.com/files/296947171/MacVim-091023.zip

It is a universal i386/x86_64 binary, with huge features and +cscope +python 
+ruby that runs on 10.5+.  Run 
with it for a while and let me know how it goes.

Original comment by bjorn.winckler@gmail.com on 23 Oct 2009 at 6:47

[GoogleCodeExporter]

A quick note about that binary: it comes with the Core Text renderer, so if you 
enable "ATSUI" in the advanced 
preferences you'll actually get Core Text, not ATSUI.  (It is faster but has 
some quirks.)

Original comment by bjorn.winckler@gmail.com on 23 Oct 2009 at 6:49

[GoogleCodeExporter]

Oh.  I forgot to patch the (same) bug in the Core Text renderer (the patch is 
in the repo though if you build from 
sources), so please don't use it when testing the binary I linked to -- i.e. 
you must go into the Advanced 
preferences and disable ATSUI or the bug will most likely still be there. 

Original comment by bjorn.winckler@gmail.com on 24 Oct 2009 at 10:01

[GoogleCodeExporter]

Thanks Bjorn.  With the ATSUI preference off, I've gone 5 days without a crash. 
 I
think you can mark this one as fixed!

Original comment by tsha...@gmail.com on 29 Oct 2009 at 11:13

[GoogleCodeExporter]

Excellent!  The problem was that I had written

[object dealloc];

instead of

[object release];

...how silly is that!

Original comment by bjorn.winckler@gmail.com on 6 Nov 2009 at 7:06

• Changed state: Fixed