Hi, On Thu, Mar 31, 2011 at 10:12 PM PDT, Dominique Pellé wrote: DP> Mun wrote: DP> DP> > Hi, DP> > DP> > My OS: Red Hat Enterprise Linux 5.6 DP> > My configure command: DP> > configure --with-features=huge --enable-perlinterp --enable-pythoninterp --enable-gui DP> > DP> > I must apologize that I don't have too much to go on with this issue, DP> > but I'll provide what I have and I will try to get more data if requested. DP> > DP> > I had a simple macro that would take a line and reformat it by adding DP> > strings to the beginning and ending of the line. Nothing tricky or DP> > complex. DP> > DP> > The file I was operating on had roughly 11,000 lines. If I executed the DP> > macro with a count of about 2,000 vim crashes on me. DP> > DP> > When I use the following vim command: DP> > % vim --noplugin <filename> DP> > DP> > I get the following lines outut to the terminal when vim crashes: DP> > DP> > ------------------------------ Delimiter BEGIN -------------------------------- DP> > DP> > BadRequest (invalid request code or no such operation) DP> > Vim: Got X error DP> > Vim: preserving files... DP> > Vim: Finished. DP> > 44;0MBadRequest (invalid request code or no such operation) DP> > Vim: Got X error DP> > Vim: Finished. DP> > 44;0M DP> > ------------------------------- Delimiter END --------------------------------- DP> DP> Hi DP> DP> Things worth trying for debugging: DP> DP> - put a breakpoint in x_error_handler(...) in vim/src/os_unix.c. DP> That's the function which prints "Vim: Got X error". And DP> send the stack trace when it gets there. Alternatively, DP> you can put an abort() in that function. Vim will dump DP> core when the function is called and with gdb you can DP> look at the stack and variables. DP> DP> - try running with valgrind memory checker. It will run much DP> slower but it may catch something: DP> $ valgrind vim --log-file=valgrind.log DP> For more details, see: http://dominique.pelle.free.fr/valgrind.txt.html DP> DP> In both cases, compile Vim with "CFLAGS = -g -O0" and DP> make sure Vim is not stripped. You can comment this DP> line in src/Makefile: DP> DP> $(STRIP) $(DEST_BIN)/$(VIMTARGET)
I used the valgrind method to acquire some additional information. After my first run crashed I noticed that every valgrind error seemed to reference Python (I hit the valgrind limit of 100 errors during the run). So I recompiled vim without the Python code. But again vim crashed during my experiment, but this time with only two valgrind errors (see attachment for the log file). My *guess* would be that the errors are related to XOpenDisplay and/or gtk in some way. But I'm at a loss here. Thanks in advance. Regards, -- Mun -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
==15021== Memcheck, a memory error detector ==15021== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==15021== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==15021== Command: /usr/local/bin/vim -g list_of_sync_flops_fdr2_TRIAL.txt ==15021== Parent PID: 3992 ==15021== ==15021== Syscall param writev(vector[...]) points to uninitialised byte(s) ==15021== at 0x37C7CCCE5C: writev (in /lib64/libc-2.5.so) ==15021== by 0x37C904663B: ??? (in /usr/lib64/libX11.so.6.2.0) ==15021== by 0x37C904B4BE: _XSend (in /usr/lib64/libX11.so.6.2.0) ==15021== by 0x37C903D19F: XQueryExtension (in /usr/lib64/libX11.so.6.2.0) ==15021== by 0x37C9031993: XInitExtension (in /usr/lib64/libX11.so.6.2.0) ==15021== by 0x37CB403B89: XFixesFindDisplay (in /usr/lib64/libXfixes.so.3.1.0) ==15021== by 0x37CB403DF8: XFixesQueryExtension (in /usr/lib64/libXfixes.so.3.1.0) ==15021== by 0x33CC83A4FE: gdk_display_open (in /usr/lib64/libgdk-x11-2.0.so.0.1000.4) ==15021== by 0x33CC819ABC: gdk_display_open_default_libgtk_only (in /usr/lib64/libgdk-x11-2.0.so.0.1000.4) ==15021== by 0x33CD92AF23: gtk_init_check (in /usr/lib64/libgtk-x11-2.0.so.0.1000.4) ==15021== by 0x5D36D3: gui_mch_init_check (gui_gtk_x11.c:1432) ==15021== by 0x5C6E5B: gui_init_check (gui.c:304) ==15021== Address 0x52f4a54 is 308 bytes inside a block of size 16,384 alloc'd ==15021== at 0x4A05140: calloc (vg_replace_malloc.c:418) ==15021== by 0x37C90372B6: XOpenDisplay (in /usr/lib64/libX11.so.6.2.0) ==15021== by 0x33CC83A358: gdk_display_open (in /usr/lib64/libgdk-x11-2.0.so.0.1000.4) ==15021== by 0x33CC819ABC: gdk_display_open_default_libgtk_only (in /usr/lib64/libgdk-x11-2.0.so.0.1000.4) ==15021== by 0x33CD92AF23: gtk_init_check (in /usr/lib64/libgtk-x11-2.0.so.0.1000.4) ==15021== by 0x5D36D3: gui_mch_init_check (gui_gtk_x11.c:1432) ==15021== by 0x5C6E5B: gui_init_check (gui.c:304) ==15021== by 0x5EAD3F: main (main.c:370) ==15021== ==15021== Syscall param writev(vector[...]) points to uninitialised byte(s) ==15021== at 0x37C7CCCE5C: writev (in /lib64/libc-2.5.so) ==15021== by 0x37C904663B: ??? (in /usr/lib64/libX11.so.6.2.0) ==15021== by 0x37C904B4BE: _XSend (in /usr/lib64/libX11.so.6.2.0) ==15021== by 0x37CAC05CC3: XRenderCompositeTrapezoids (in /usr/lib64/libXrender.so.1.3.0) ==15021== by 0x37CF03525E: ??? (in /usr/lib64/libcairo.so.2.9.2) ==15021== by 0x37CF01AB00: ??? (in /usr/lib64/libcairo.so.2.9.2) ==15021== by 0x37CF01DA6F: ??? (in /usr/lib64/libcairo.so.2.9.2) ==15021== by 0x37CF01CE2E: ??? (in /usr/lib64/libcairo.so.2.9.2) ==15021== by 0x37CF01D75A: ??? (in /usr/lib64/libcairo.so.2.9.2) ==15021== by 0x37CF01DB6B: ??? (in /usr/lib64/libcairo.so.2.9.2) ==15021== by 0x37CF01B87E: ??? (in /usr/lib64/libcairo.so.2.9.2) ==15021== by 0x37CF0100BF: ??? (in /usr/lib64/libcairo.so.2.9.2) ==15021== Address 0x52f4941 is 33 bytes inside a block of size 16,384 alloc'd ==15021== at 0x4A05140: calloc (vg_replace_malloc.c:418) ==15021== by 0x37C90372B6: XOpenDisplay (in /usr/lib64/libX11.so.6.2.0) ==15021== by 0x33CC83A358: gdk_display_open (in /usr/lib64/libgdk-x11-2.0.so.0.1000.4) ==15021== by 0x33CC819ABC: gdk_display_open_default_libgtk_only (in /usr/lib64/libgdk-x11-2.0.so.0.1000.4) ==15021== by 0x33CD92AF23: gtk_init_check (in /usr/lib64/libgtk-x11-2.0.so.0.1000.4) ==15021== by 0x5D36D3: gui_mch_init_check (gui_gtk_x11.c:1432) ==15021== by 0x5C6E5B: gui_init_check (gui.c:304) ==15021== by 0x5EAD3F: main (main.c:370) ==15021== ==15021== ==15021== HEAP SUMMARY: ==15021== in use at exit: 13,145,875 bytes in 140,829 blocks ==15021== total heap usage: 533,315 allocs, 392,486 frees, 77,519,241 bytes allocated ==15021== ==15021== LEAK SUMMARY: ==15021== definitely lost: 44,977 bytes in 348 blocks ==15021== indirectly lost: 48,320 bytes in 1,510 blocks ==15021== possibly lost: 10,190,062 bytes in 115,996 blocks ==15021== still reachable: 2,862,516 bytes in 22,975 blocks ==15021== suppressed: 0 bytes in 0 blocks ==15021== Rerun with --leak-check=full to see details of leaked memory ==15021== ==15021== For counts of detected and suppressed errors, rerun with: -v ==15021== Use --track-origins=yes to see where uninitialised values come from ==15021== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 8 from 6) ==15021== ==15021== HEAP SUMMARY: ==15021== in use at exit: 17,953,590 bytes in 203,249 blocks ==15021== total heap usage: 8,897,595 allocs, 8,694,346 frees, 1,787,209,492 bytes allocated ==15021== ==15021== LEAK SUMMARY: ==15021== definitely lost: 387,145 bytes in 2,752 blocks ==15021== indirectly lost: 48,837 bytes in 1,528 blocks ==15021== possibly lost: 11,593,550 bytes in 118,060 blocks ==15021== still reachable: 5,924,058 bytes in 80,909 blocks ==15021== suppressed: 0 bytes in 0 blocks ==15021== Rerun with --leak-check=full to see details of leaked memory ==15021== ==15021== For counts of detected and suppressed errors, rerun with: -v ==15021== Use --track-origins=yes to see where uninitialised values come from ==15021== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 8 from 6)
