On Fri, Aug 22, 2008 at 3:32 AM, Matt Wozniski wrote:

> Not sure what's going on here, but I've found a crash that's easy to
> reproduce.  First, open two X11 enabled vim (not gvim) processes.  In
> the first, do:
> :let @+ = repeat('a', 1024*1024)
> in order to store 1MB of data to the clipboard.  The exact amount is
> irrelevant, but the larger the size, the more often it will lead to a
> segfault.
>
> Then, in the second vim instance, repeatedly do ":reg +" and see what
> gets displayed.  Depending upon the amount of data that you put on the
> clipboard, as well as upon some other factor I'm not seeing, this will
> either a) show a bunch of a's in register +, b) not show any
> registers, as though register + didn't exist, or c) cause the vim in
> which you copied to segfault, and the vim in which you're trying to
> display the register to enter a tight loop wasting a lot of CPU and
> only dying for kill -9.  Just try the command 5 or so times and you
> should see a segfault - as well as the missing-register behavior.  If
> you don't get the segfault at all, try upping the amount of data
> stored to the clipboard.  If you get the segfault, but not the
> missing-register behavior, try lowering the amount of data stored to
> the clipboard.  And if you can't reproduce either, that might help to
> pin down what exactly causes this.
>
> I can reproduce this on both a vim linked with the GTK2-Gnome gui, and
> one linked with the X11-Motif gui, so it doesn't seem to be something
> gnome-specific, either.  This is vim 7.2.
>
> Let me know if we need more details.
>
> ~Matt


I tried it with Vim-7.2.2 (GTK2-GNOME) on Linux x86 and ":reg +" did
not show anything for me, no crash observed. But I expected to see
"aaa...." when doing ":reg +".  Running both instances of Vim with
Valgrind memory checker finds problems in both instances of Vim:

1/ In first instance of vim where  :let @+ = repeat('a', 1024*1024)  is typed:

==6632== Invalid free() / delete / delete[]
==6632==    at 0x402265C: free (vg_replace_malloc.c:323)
==6632==    by 0x48B2D90: XtFree (in /usr/lib/libXt.so.6.0.0)
==6632==    by 0x48D7ECC: (within /usr/lib/libXt.so.6.0.0)
==6632==    by 0x48CDFA9: (within /usr/lib/libXt.so.6.0.0)
==6632==    by 0x48CE0E1: XtAppNextEvent (in /usr/lib/libXt.so.6.0.0)
==6632==    by 0x814D13B: xterm_update (os_unix.c:6502)
==6632==    by 0x814B46F: RealWaitForChar (os_unix.c:4968)
==6632==    by 0x814B0E0: WaitForChar (os_unix.c:4639)
==6632==    by 0x8147033: mch_inchar (os_unix.c:389)
==6632==    by 0x81B1F38: ui_inchar (ui.c:193)
==6632==    by 0x80D585E: inchar (getchar.c:2959)
==6632==    by 0x80D548F: vgetorpeek (getchar.c:2735)
==6632==    by 0x80D3992: vgetc (getchar.c:1552)
==6632==    by 0x80D3F0D: safe_vgetc (getchar.c:1757)
==6632==    by 0x8121128: normal_cmd (normal.c:643)
==6632==    by 0x80E540D: main_loop (main.c:1179)
==6632==    by 0x80E4F5A: main (main.c:938)

==6632==  Address 0x6c2d028 is 0 bytes inside a block of size 1,048,577 free'd
==6632==    at 0x402265C: free (vg_replace_malloc.c:323)
==6632==    by 0x48B2D90: XtFree (in /usr/lib/libXt.so.6.0.0)
==6632==    by 0x48D4492: (within /usr/lib/libXt.so.6.0.0)
==6632==    by 0x48D7DB3: (within /usr/lib/libXt.so.6.0.0)
==6632==    by 0x48C13E4: XtDispatchEventToWidget (in /usr/lib/libXt.so.6.0.0)
==6632==    by 0x48C1D87: (within /usr/lib/libXt.so.6.0.0)
==6632==    by 0x48C0CF6: XtDispatchEvent (in /usr/lib/libXt.so.6.0.0)
==6632==    by 0x814D193: xterm_update (os_unix.c:6512)
==6632==    by 0x814B46F: RealWaitForChar (os_unix.c:4968)
==6632==    by 0x814B0E0: WaitForChar (os_unix.c:4639)
==6632==    by 0x8147033: mch_inchar (os_unix.c:389)
==6632==    by 0x81B1F38: ui_inchar (ui.c:193)
==6632==    by 0x80D585E: inchar (getchar.c:2959)
==6632==    by 0x80D548F: vgetorpeek (getchar.c:2735)
==6632==    by 0x80D3992: vgetc (getchar.c:1552)
==6632==    by 0x80D3F0D: safe_vgetc (getchar.c:1757)
==6632==    by 0x8121128: normal_cmd (normal.c:643)
==6632==    by 0x80E540D: main_loop (main.c:1179)
==6632==    by 0x80E4F5A: main (main.c:938)

==6632== 408 (332 direct, 76 indirect) bytes in 2 blocks are
definitely lost in loss record 38 of 56
==6632==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==6632==    by 0x48B2F27: XtMalloc (in /usr/lib/libXt.so.6.0.0)
==6632==    by 0x48D727B: (within /usr/lib/libXt.so.6.0.0)
==6632==    by 0x48D73BE: (within /usr/lib/libXt.so.6.0.0)
==6632==    by 0x48D76D5: (within /usr/lib/libXt.so.6.0.0)
==6632==    by 0x48D791A: (within /usr/lib/libXt.so.6.0.0)
==6632==    by 0x48C13E4: XtDispatchEventToWidget (in /usr/lib/libXt.so.6.0.0)
==6632==    by 0x48C1D87: (within /usr/lib/libXt.so.6.0.0)
==6632==    by 0x48C0CF6: XtDispatchEvent (in /usr/lib/libXt.so.6.0.0)
==6632==    by 0x814D193: xterm_update (os_unix.c:6512)
==6632==    by 0x814B46F: RealWaitForChar (os_unix.c:4968)
==6632==    by 0x814B0E0: WaitForChar (os_unix.c:4639)
==6632==    by 0x8147033: mch_inchar (os_unix.c:389)
==6632==    by 0x81B1F38: ui_inchar (ui.c:193)
==6632==    by 0x80D585E: inchar (getchar.c:2959)
==6632==    by 0x80D548F: vgetorpeek (getchar.c:2735)
==6632==    by 0x80D3992: vgetc (getchar.c:1552)
==6632==    by 0x80D3F0D: safe_vgetc (getchar.c:1757)
==6632==    by 0x8121128: normal_cmd (normal.c:643)
==6632==    by 0x80E540D: main_loop (main.c:1179)
==6632==    by 0x80E4F5A: main (main.c:938)


2/ In Vim instance where ":reg +" is typed:

==6651== Invalid read of size 1
==6651==    at 0x40239E3: strlen (mc_replace_strmem.c:242)
==6651==    by 0x81B44CA: clip_x11_request_selection_cb (ui.c:2079)
==6651==    by 0x48D5FBA: (within /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48C13E4: XtDispatchEventToWidget (in /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48C1D87: (within /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48C0CF6: XtDispatchEvent (in /usr/lib/libXt.so.6.0.0)
==6651==    by 0x814D193: xterm_update (os_unix.c:6512)
==6651==    by 0x814B46F: RealWaitForChar (os_unix.c:4968)
==6651==    by 0x814B027: mch_breakcheck (os_unix.c:4582)
==6651==    by 0x81B20E5: ui_breakcheck (ui.c:368)
==6651==    by 0x8135BD6: ex_display (ops.c:3999)
==6651==    by 0x80A615D: do_one_cmd (ex_docmd.c:2621)
==6651==    by 0x80A3A00: do_cmdline (ex_docmd.c:1095)
==6651==    by 0x81288B3: nv_colon (normal.c:5214)
==6651==    by 0x8121F3E: normal_cmd (normal.c:1181)
==6651==    by 0x80E540D: main_loop (main.c:1179)
==6651==    by 0x80E4F5A: main (main.c:938)

==6651==  Address 0x621a8a0 is 0 bytes after a block of size 1,048,576 alloc'd
==6651==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==6651==    by 0x48B2F27: XtMalloc (in /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48B3030: __XtMalloc (in /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48D5B9A: (within /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48D5CBA: (within /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48C13E4: XtDispatchEventToWidget (in /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48C1D87: (within /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48C0CF6: XtDispatchEvent (in /usr/lib/libXt.so.6.0.0)
==6651==    by 0x81B46F3: clip_x11_request_selection (ui.c:2161)
==6651==    by 0x814D24B: clip_xterm_request_selection (os_unix.c:6538)
==6651==    by 0x81B3C04: clip_gen_request_selection (ui.c:1480)
==6651==    by 0x81386A1: clip_get_selection (ops.c:5640)
==6651==    by 0x813038E: may_get_selection (ops.c:916)
==6651==    by 0x8135A83: ex_display (ops.c:3957)
==6651==    by 0x80A615D: do_one_cmd (ex_docmd.c:2621)
==6651==    by 0x80A3A00: do_cmdline (ex_docmd.c:1095)
==6651==    by 0x81288B3: nv_colon (normal.c:5214)
==6651==    by 0x8121F3E: normal_cmd (normal.c:1181)
==6651==    by 0x80E540D: main_loop (main.c:1179)
==6651==    by 0x80E4F5A: main (main.c:938)

==6651== 1 bytes in 1 blocks are definitely lost in loss record 1 of 58
==6651==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==6651==    by 0x4AE0B8C: XGetWindowProperty (in /usr/lib/libX11.so.6.2.0)
==6651==    by 0x48D5EC2: (within /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48C13E4: XtDispatchEventToWidget (in /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48C1D87: (within /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48C0CF6: XtDispatchEvent (in /usr/lib/libXt.so.6.0.0)
==6651==    by 0x814D193: xterm_update (os_unix.c:6512)
==6651==    by 0x814B46F: RealWaitForChar (os_unix.c:4968)
==6651==    by 0x814B027: mch_breakcheck (os_unix.c:4582)
==6651==    by 0x81B20E5: ui_breakcheck (ui.c:368)
==6651==    by 0x8135BD6: ex_display (ops.c:3999)
==6651==    by 0x80A615D: do_one_cmd (ex_docmd.c:2621)
==6651==    by 0x80A3A00: do_cmdline (ex_docmd.c:1095)
==6651==    by 0x81288B3: nv_colon (normal.c:5214)
==6651==    by 0x8121F3E: normal_cmd (normal.c:1181)
==6651==    by 0x80E540D: main_loop (main.c:1179)
==6651==    by 0x80E4F5A: main (main.c:938)

==6651== 516 (440 direct, 76 indirect) bytes in 3 blocks are
definitely lost in loss record 42 of 58
==6651==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==6651==    by 0x48B2F27: XtMalloc (in /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48D3CEA: (within /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48D3DEA: (within /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48D6865: (within /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48D6FCF: XtGetSelectionValue (in /usr/lib/libXt.so.6.0.0)
==6651==    by 0x81B4675: clip_x11_request_selection (ui.c:2132)
==6651==    by 0x814D24B: clip_xterm_request_selection (os_unix.c:6538)
==6651==    by 0x81B3C04: clip_gen_request_selection (ui.c:1480)
==6651==    by 0x81386A1: clip_get_selection (ops.c:5640)
==6651==    by 0x8130368: may_get_selection (ops.c:909)
==6651==    by 0x8135A83: ex_display (ops.c:3957)
==6651==    by 0x80A615D: do_one_cmd (ex_docmd.c:2621)
==6651==    by 0x80A3A00: do_cmdline (ex_docmd.c:1095)
==6651==    by 0x81288B3: nv_colon (normal.c:5214)
==6651==    by 0x8121F3E: normal_cmd (normal.c:1181)
==6651==    by 0x80E540D: main_loop (main.c:1179)
==6651==    by 0x80E4F5A: main (main.c:938)
==6651==
==6651==
==6651== 2,097,166 bytes in 2 blocks are possibly lost in loss record 58 of 58
==6651==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==6651==    by 0x48B2F27: XtMalloc (in /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48B3030: __XtMalloc (in /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48D5B9A: (within /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48D5CBA: (within /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48C13E4: XtDispatchEventToWidget (in /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48C1D87: (within /usr/lib/libXt.so.6.0.0)
==6651==    by 0x48C0CF6: XtDispatchEvent (in /usr/lib/libXt.so.6.0.0)
==6651==    by 0x81B46F3: clip_x11_request_selection (ui.c:2161)
==6651==    by 0x814D24B: clip_xterm_request_selection (os_unix.c:6538)
==6651==    by 0x81B3C04: clip_gen_request_selection (ui.c:1480)
==6651==    by 0x81386A1: clip_get_selection (ops.c:5640)
==6651==    by 0x813038E: may_get_selection (ops.c:916)
==6651==    by 0x8135A83: ex_display (ops.c:3957)
==6651==    by 0x80A615D: do_one_cmd (ex_docmd.c:2621)
==6651==    by 0x80A3A00: do_cmdline (ex_docmd.c:1095)
==6651==    by 0x81288B3: nv_colon (normal.c:5214)
==6651==    by 0x8121F3E: normal_cmd (normal.c:1181)
==6651==    by 0x80E540D: main_loop (main.c:1179)
==6651==    by 0x80E4F5A: main (main.c:938)


Doing the same with a smaller value such as ":let @+ = repeat('a', 10*10"
gives no error with Valgrind, and the second instance of Vim shows a bunch
of "aaa..." when doing ":reg +" as expected.  I did not have the time to look
further yet.

-- Dominique

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply via email to