Hi,

Thanks for notifying me of this issue.

I have tested this in gvim for widows, but was not able to find this issue.

I am not yet able to test this on a mac. Can you tell me what exactly
happens? Does it hangs or shows any messages before it ends? Have you
noticed this issue with any similar plugins?

Thanks,
Sandeep.

On Fri, Jun 22, 2012 at 9:56 AM, David Joyner <
[email protected]

wrote:

I've reproduced this both on MacVim 7.3 pl 315 and Apple's vim 7.3 that
ships with Lion. If I've brought up buffet and accidentally open a file
for edit using :e then vim dies a horrible death. Interestingly this
doesn't occur with :split or :vsplit.

---

Reply to this email directly or view it on GitHub:
#7

from buffet.vim.

I can confirm that the issue doesn't occur with gvim on Windows.

On the Mac, MacVim and terminal mode vim both terminate immediately after I
hit for the :e command. vim prints:

Vim: Caught deadly signal SEGV
Vim: Finished.
Segmentation fault: 11

I checked the crash logs and there are entries for both MacVim and terminal
mode vim. The former is more useful as the stack backtrace actually has
symbol decodes. It looks like a NULL pointer was dereferenced in
set_last_cursor(), called from close_buffer().

Obviously as a plug-in developer this probably isn't your issue but it
might give you some ideas of what to change to work around the issue and
avoid the crash. I think I need to go file this against vim as well. When
an editor crashes like this it is very disconcerting.

Process: Vim [11553]
Path: /Applications/MacVim.app/Contents/MacOS/Vim
Identifier: Vim
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: MacVim [11543]

Date/Time: 2012-06-22 00:21:47.673 -0400
OS Version: Mac OS X 10.7.4 (11E53)
Report Version: 9

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

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: 0x000000000000000d, 0x0000000000000000

VM Regions Near 0:
-->
__TEXT 0000000100516000-00000001006fd000 [ 1948K]
r-x/rwx SM=COW /Applications/MacVim.app/Contents/MacOS/Vim

Application Specific Information:
objc[11553]: garbage collection is OFF

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff8a58782a __kill + 10
1 Vim 0x0000000100601c0c mch_exit + 220
2 Vim 0x00000001005ff1c2 deathtrap + 450
3 libsystem_c.dylib 0x00007fff8d14bcfa _sigtramp + 26
4 Vim 0x00000001005a7a2b set_last_cursor + 11
5 Vim 0x000000010051dcd2 close_buffer + 130
6 Vim 0x000000010055aacb do_ecmd + 1387
7 Vim 0x00000001005766cf do_exedit + 847
8 Vim 0x00000001005753e3 do_cmdline + 11747
9 Vim 0x00000001005db615 nv_colon + 165
10 Vim 0x00000001005e6770 normal_cmd + 5440
11 Vim 0x00000001006a6360 main_loop + 1232
12 Vim 0x00000001006aa0d2 main + 13138
13 Vim 0x00000001005175a4 start + 52

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0 libsystem_kernel.dylib 0x00007fff8a5887e6 kevent + 10
1 libdispatch.dylib 0x00007fff8b8b978a _dispatch_mgr_invoke +
923
2 libdispatch.dylib 0x00007fff8b8b831a _dispatch_mgr_thread +
54

Thread 2:
0 libsystem_kernel.dylib 0x00007fff8a588192 __workq_kernreturn +
10
1 libsystem_c.dylib 0x00007fff8d0f9594 _pthread_wqthread + 758
2 libsystem_c.dylib 0x00007fff8d0fab85 start_wqthread + 13

Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x0000000000000001 rcx: 0x0000000100b80a48
rdx: 0x0000000000000000
rdi: 0x0000000000002d21 rsi: 0x000000000000000b rbp: 0x0000000100b80a60
rsp: 0x0000000100b80a48
r8: 0x0000000000000000 r9: 0x00007f8902845800 r10: 0x0000000000000005
r11: 0xffffff80002da8d0
r12: 0x00007f890286e800 r13: 0x0000000000000000 r14: 0x000000000000000b
r15: 0x00007f8902845800
rip: 0x00007fff8a58782a rfl: 0x0000000000000206 cr2: 0x00000001005a4160
Logical CPU: 0

[Deletia]

from buffet.vim.

I filed a report with [email protected]. Also checked out the vim sources. What's happening is that when the last window for a buffer is being closed (in this case the Buffet window/buffer), the vim code makes a call to set_last_cursor(). This blindly assumes that the window still has a buffer associated with it.

In your case I think your BufLeave autocmd at line 661 is causing the issue:

au  BufLeave <buffer> call <sid>close()

When I comment this out the crash no longer occurs. I think the autocmd is causing the window and buffer to become disassociated before close_buffer() runs. I'm convinced that this is a bug in vim and it should be easy for a maintainer to fix. However, if you can find a workaround that preserves the nice auto-close effect you've got going there then you'll go a long way towards making it a non-issue. Who knows how long it takes for vim to roll fixes into new releases.

from buffet.vim.

Hi

I think i ve got some idea how to fix this. Thanks to all that info you
provided.

I remember reading something a like vim does not guarantee that the
function that return value of current buffer will return correct value in
bufleave autocommand. So I doubt this is a bug in vim.

I hope I can fix this in plug-in itself.

Thanks again for the info.

Have a nice day!

Sandeep.
On 23 Jun 2012 02:28, "David Joyner" <
[email protected]>
wrote:

I filed a report with [email protected]. Also checked out the vim sources.
What's happening is that when the last window for a buffer is being closed
(in this case the Buffet window/buffer), the vim code makes a call to
set_last_cursor(). This blindly assumes that the window still has a buffer
associated with it.

In your case I think your BufLeave autocmd at line 661 is causing the
issue:

au BufLeave call close()

When I comment this out the crash no longer occurs. I think the autocmd
is causing the window and buffer to become disassociated before
close_buffer() runs. I'm convinced that this is a bug in vim and it should
be easy for a maintainer to fix. However, if you can find a workaround
that preserves the nice auto-close effect you've got going there then
you'll go a long way towards making it a non-issue. Who knows how long it
takes for vim to roll fixes into new releases.

---

Reply to this email directly or view it on GitHub:
#7 (comment)

from buffet.vim.

From my POV an editor should never seg fault due to user input (even when that's in the form of a scripted plug-in). That said, I look forward to your fix. ;)

from buffet.vim.

Got a response from Bram:

There have been a few bug fixes for autocommands doing unexpected things
while closing a window or buffer. The last one was 7.3.557. Please try
to find a Vim binary with that patch included, or build it yourself.
Ask on the vim-mac maillist if you can't.

Sure enough, I downloaded a snapshot build of MacVim 7.3 with patches 1-390 and the issue is resolved!

from buffet.vim.

Thats great. I wonder what unexpected thing my plugin was doing though. :)

I was wondering how I am going to fix the issue, because I don't have
access to a mac to test it. Glad it turned out this way.

Any way great talking to you...

Have a nice day...!!

On Sat, Jun 23, 2012 at 10:05 PM, David Joyner <
[email protected]

wrote:

Got a response from Bram:

There have been a few bug fixes for autocommands doing unexpected things
while closing a window or buffer. The last one was 7.3.557. Please try
to find a Vim binary with that patch included, or build it yourself.
Ask on the vim-mac maillist if you can't.

Sure enough, I downloaded a snapshot build of MacVim 7.3 with patches
1-390 and the issue is resolved!

---

Reply to this email directly or view it on GitHub:
#7 (comment)

from buffet.vim.