Re: bug/feature: tab-completion in command-line

On Sat, 11 Mar 2006 18:24:04 -0500
tpgww@xxxxxxxxxxx wrote:

> On Thu, 9 Mar 2006 01:19:46 +0100
> Atman Sense <mattenklicker@xxxxxxx> wrote:
> 
> > On Wed, 8 Mar 2006 23:57:05 -0500
> > tpgww@xxxxxxxxxxx wrote:
> > 
> > > On Tue, 7 Mar 2006 16:48:28 +0100
> > > Atman Sense <mattenklicker@xxxxxxx> wrote:
> > > 
> > > > emelfm2 crashes when i want to complete a command-name with
> > > > tab. For example mplayer, first time it works, the second time:
> > > > 
> > > > (emelfm2:16318): GLib-CRITICAL **: g_strsplit: assertion
> > > > `string != NULL' failed Speicherzugriffsfehler
> > > > 
> > > > or
> > > > 
> > > > *** glibc detected *** double free or corruption (!prev):
> > > > 0x082fa578 *** Abgebrochen
> > > 
> > > This one is tough to understand! The g_strsplit() applies to
> > > $PATH, and it's not obvious why that would cease to exist
> > > between commands. Certainly, command-completion is repeatable
> > > here.
> > > 
> > > Can you please describe your context in more detail, including
> > > what $PATH is before and after the tab-completion, and check
> > > whether the problem is evident for other command(s) too ?
> > 
> > I tried following now:
> > Moved ~/.emelfm2
> > xhost +
> > env -i DISPLAY=':0.0' strace -o /tmp/emelfm ./emelfm2 -l -n -x
> > then tried to expand commands (any, also non-existing)--> crash
> > in idle state in /tmp/emelfm ther are ongoing gettimeofday messages,
> > tried to put q and <tab> in command-line these last lines appear:
> > 
> > write(2, "\n(emelfm2:26285): GLib-CRITICAL "..., 82) = 82
> > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > +++ killed by SIGSEGV +++
> > 
> > I use gentoo-linux, gcc-3.3.6/3.4.5
> > Build platform: GTK+ 2.8.8 Linux 2.6.15-gentoo-r1/i686
> > windowmaker
> > Eterm
> > bash
> > 
> > I tried a remote debian-machine: a bit different behavior, emelfm
> > hang up or crashed, strace shows something like this (in case of
> > trying to expand grep): 
> > access("/usr/bin/grep-changelog.emacs21", X_OK) = 0
> > stat64("/usr/bin/grep-changelog.emacs21", {st_mode=S_IFREG|0755,
> > st_size=6950, ...}) = 0 getdents64(8, /* 124 entries */, 4096)  =
> > 4072 getdents64(8, /* 125 entries */, 4096)  = 4088
> > getdents64(8, /* 125 entries */, 4096)  = 4088
> > getdents64(8, /* 125 entries */, 4096)  = 4096
> > getdents64(8, /* 128 entries */, 4096)  = 4072
> > getdents64(8, /* 126 entries */, 4096)  = 4096
> > getdents64(8, /* 130 entries */, 4096)  = 4096
> > getdents64(8, /* 122 entries */, 4096)  = 4088
> > getdents64(8, /* 127 entries */, 4096)  = 4080
> > getdents64(8, /* 79 entries */, 4096)   = 2616
> > getdents64(8, /* 0 entries */, 4096)    = 0
> > close(8)                                = 0
> > open("/bin", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 8
> > fstat64(8, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> > fcntl64(8, F_SETFD, FD_CLOEXEC)         = 0
> > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> > +++ killed by SIGSEGV +++
> 
> Seems like something bad has been sent to glib's "open directory"
> function. I suspect it's another filename encoding problem. The
> pre-release code has since been cleaned up, in that regard, so I
> propose that we resume investigation of this using the next release
> for testing purposes.

Oh, yes, emelfm compiled with FILES_UTF8ONLY=1 has not this problem.

Bye,
Atman


-- 
Users can unsubscribe from the list by sending email to 
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by 
logging into the web interface.

Other related posts: