Created attachment 580900 [details]
backtrace from dumped core (using gdb)
Description of problem:
Running any python commands within vim causes a segfault
Version-Release number of selected component (if applicable):
$ sudo yum info vim-X11
Loaded plugins: auto-update-debuginfo, fastestmirror, langpacks, presto, refresh-packagekit
Name : vim-X11
Arch : x86_64
Epoch : 2
Version : 7.3.444
Release : 1.fc17
Size : 2.3 M
Repo : installed
From repo : fedora
Summary : The VIM version of the vi editor for the X Window System
URL : http://www.vim.org/
License : Vim
Steps to Reproduce:
1. run gvim
2. type ":python print 1"
I get the same results with vim-enhanced-7.3.444-1.fc17.x86_64 (running vim instead of gvim).
I'm almost certain this is the same bug as:
The fix under arch so far has been to remove -O2 from the CFLAGS.
I'm guessing this is gcc 4.7 related, but I still don't know the underlying problem :/
It may be a result of:
As the discussion on the vim_dev forum suggests:
Note that http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53084
was also in the 4.6 branch which makes this bug unlikely since the previous vim compiled with 4.6 didn't seem to have this bug.
The conversation on vim-dev has progressed and it sounds like Debian has an updated gcc which might help: https://groups.google.com/d/msg/vim_dev/yBL4GkGVUdM/l5fSHMG2dWcJ
(In reply to comment #4)
> The conversation on vim-dev has progressed and it sounds like Debian has an
> updated gcc which might help:
In fact this gcc fix is already in F17 so maybe rebuilding vim would do the trick. I'm running the same version as the OP so it hasn't been rebuilt since the gcc update. (I'm trying to rebuild locally but running into protected multilib versions installing dependencies; looks like the i686 and x86_64 repos are out of sync at the moment.)
have you tried vim-7.3.515-1.fc17 from updates-testing ?
vim-7.3.515-1.fc17 from updates-testing prevents vim from segfaulting.
It does not seem to fix this issue.
Printing to the output buffer will return null.
As the following commit log suggests:
(In reply to comment #6)
> have you tried vim-7.3.515-1.fc17 from updates-testing ?
Thanks, vim no longer segfaults with this version. I had inadvertently disabled updates-testing previously.
(In reply to comment #7)
> vim-7.3.515-1.fc17 from updates-testing prevents vim from segfaulting.
> It does not seem to fix this issue.
> Printing to the output buffer will return null.
> As the following commit log suggests:
Yeah, for example ":python raise Exception" on F16 displays the exception, but on F17 with vim-7.3.515-1.fc17 it's just silent. Not sure if this deserves a separate ticket or if it's okay to keep using this one.
I wonder if it would work to build vim-7.3.515-1.fc17 omitting patch 497 (the workaround) using gcc-4.7.0-5.fc17.x86_64 (theoretically has the fix, according to Debian folks)
Just an fyi, archlinux using the gcc snapshot 4.7-20120505 still encounters this problem.
(In reply to comment #9)
> I wonder if it would work to build vim-7.3.515-1.fc17 omitting patch 497 (the
> workaround) using gcc-4.7.0-5.fc17.x86_64 (theoretically has the fix, according
> to Debian folks)
I rebuilt vim-7.3.444-1.fc17 using gcc-4.7.0-5.fc17.x86_64 and got the segfault, so it seems like the supposed gcc fix doesn't help.
While it won't segfault, python functioanllty is disabled ( :python print "hello" does nothing), as a result many of rope-vim functionality is disabled.
Any updates regarding this ?
This problem persists in vim-7.3.622-2.fc18. It's no longer a segfault since that was fixed by patch 497, but it's still a pain because python print and exceptions no longer generate output.
I'll attach a patch that works around the problem by building if_python.o (and only that) with -O0. Since this has been broken for a few months and there's progress on vim-dev, would you consider including this workaround for now?
Created attachment 603642 [details]
build if_python.o with -O0
I've used the diff and rebuilt the packages, python with vim works again now.
+1 for including it (at least some better solution will surface).
vim-7.3.638-2.fc17 has been submitted as an update for Fedora 17.
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing vim-7.3.638-2.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
After testing this version there is no segfault, but that was already the case due to the workaround. Since printing from python still doesn't work, I think we'd need to revert the workaround (from http://code.google.com/p/vim/source/detail?r=e34c620007be9fd805556c43fe848de521f3b64c) in order to see if this is really fixed.
Why is this bug marked ON_QA? vim-7.3.638-2.fc17 doesn't fix the problem. The segfault is avoided but that was already the case. It's just a symptom (albeit a nasty one) of the underlying issue.
Rather than the workaround I posted in comment 14, here's the proper fix: https://groups.google.com/forum/?fromgroups=#!topic/vim_dev/zxXc0aGhaKM
Created attachment 608523 [details]
Patch vim.spec to include vim-7.3-py_ssize_t.patch
Created attachment 608524 [details]
vim-7.3.638-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Hey Karsten, this bug is CLOSED ERRATA but I don't think it should be. I attached a patch above that fixes the real issue. Would you consider reopening this bug and applying the patch?
+1 For Aron, please reopen and use the upstream patch which Aron pointed to at comment 19.
Upstream released patch 7.3.652 which should fix the python issue. I'll prepare updated packages soon.
Problem: Workaround for Python crash isn't perfect.
Solution: Change the type of the length argument. (Sean Estabrooks)
Hi, any updates on that ?
On archlinux, latest vim doesn't have this problem anymore
I meant package wise.
Sorry, missed the updated packages (got using to deselecting vim related stuff).
Seems great now. IMO this can be closed.
Yup, agreed - I no longer have the issue, and printing works from python. Hopefully "upstream" is the right close reason?