| 1 |
> > When I discovered, to my surprise, that I was forced to use nano, I |
| 2 |
> > immediately decided to take your Portage system for a spin, and typed |
| 3 |
> > 'emerge app-editors/vi'. Vi was built from source (though I'm not |
| 4 |
> > clear on which particular vi you used). However, when I tried to run |
| 5 |
> > it, it segfaulted. So I was stuck with nano. |
| 6 |
> |
| 7 |
> Could you please give me a backtrace of this? I'm the one "responsible" |
| 8 |
> for vi as of the moment, and this is the second occurance of a random |
| 9 |
> heisenbug for vi that I've seen, noone so far has been able to debug it |
| 10 |
> since it goes away with their second install (It works for me, in the |
| 11 |
> systems I've tried, could be a library interdependency bug) |
| 12 |
|
| 13 |
It segfaults for me too... but only if I run vi in the plain text console |
| 14 |
(please correct me if I use the wrong terminology -- I'm new to Linux, but |
| 15 |
not to Unix). If I run vi from withing Gnome, it works fine. I have yet |
| 16 |
to install it a second time. |
| 17 |
|
| 18 |
The backtrace doesn't look so instructive since there's no debug |
| 19 |
information in the executable (and I'm afraid that recompiling vi will |
| 20 |
make the problem go away): |
| 21 |
|
| 22 |
#0 0x400495aa in tgoto () from /lib/libncurses.so.5 |
| 23 |
#1 0x0805856a in getline () |
| 24 |
#2 0x08049fad in strcpy () |
| 25 |
#3 0x4007e3bd in __libc_start_main () from /lib/libc.so.6 |
| 26 |
|
| 27 |
Is there anything you need to know about my system? |
| 28 |
|
| 29 |
|
| 30 |
Wes |
Archives