Bug 150569

I'm not sure the forward slash in the file name is valid. The shell
doesn't handle it correctly.

$ touch foo\/bar gives an error.

Seems more like an extfs bug. Don't think it should accept files with
slashes in the name.

Ok. Assuming the second slash is a path separator...

I have no problem whatsoever moving or copying either the file, or one
of the parent dirs around. I'm running a 4.6.1-pre build, but that
shouldn't matter for this issue.

Please explain how step 1) is involved.

Dear Radek,

1. Please verify that the loop is really endless.
2. What happens if you leave out step 1?
3. Which process is taking the CPU? (run top(1)). Is it really mc?
   Is it in userspace or in system space?

Roland

Roland, step 3 .. mc takes 99.9% of CPU .. this is what top says and
what I already said! 

Leonard, about step 1. Sorry for fwd slashes, the files were get from
Windows filesystem, downloaded to a local machine and then I've played
around with them. It really seems like there's sth broken in utf8
patch, attaching gdb to a process and doing backtrace says, that it
freezes on mbstrlen function. Here's the patch for mc-utf8.patch which
jnovy proposed to me and it kills the deadloop.. So with this patch
the issue is fixed.


@@ -2427,6 +2427,9 @@
 +            size_t len;
 +
 +            len = mbrtowc (&c, str, MB_CUR_MAX, NULL);
++	    
++	    if (len == (size_t)(-1)) break;
++	    
 +            if (len > 0) {
 +                int wcsize = wcwidth(c);
 +                width += wcsize > 0 ? wcsize : 0;

Radek,

the patch I sent you was a quick hack to figure out whether the problem is in
the fact that mbrtowc() founds characters that it considers as a multi-byte
sequence that it's unable to parse.

The code of the mbstrlen() is:

size_t
mbstrlen (const char *str)
{
#ifdef UTF8
    if (SLsmg_Is_Unicode) {
        size_t width = 0;

        for (; *str; str++) {
            wchar_t c;
            size_t len;

            len = mbrtowc (&c, str, MB_CUR_MAX, NULL);

            if (len > 0) {
                int wcsize = wcwidth(c);
                width += wcsize > 0 ? wcsize : 0;
                str += len-1;
            }
        }

        return width;
    } else
#endif
       return strlen (str);
}

Please note that if mbrtowc() returns (size_t)(-1) in case of invalid multibyte
sequence, what actually means that len=0xffffffff because size_t is an unsigned
int. The condition len > 0 is always true except of len==0. Then str+=len-1 will
cause decrement of two of the str pointer, what is incremented of one by str++
at the end of the for loop. So actually we moved one character back. If the call
of mbrtowc() for the previous character succeeds and len=1, we'll be parsing
again the invalid byte sequence -> here we go with the infinite loop.

Leonard, Roland, this won't affect the upstream mc as it's a utf8 patch that
needs to be fixed. I found at least one place in the upstream mc code, where the
glibc calls are not properly checked whether they end up successfully and the
problem is very similar to this one (may cause something different than infinite
loops, but for sure something odd). Unfortunately it remained unnoticed up to now.

Please see:
http://mail.gnome.org/archives/mc-devel/2005-February/msg00041.html

Fix for this issue is now applied in CVS. I also ported the UTF8 patch to the
today's mc CVS checkout, so the fix will come also with the recent mc.

I couldn't build it today, because of the BuildRoot pollution on ppc64,
hopefully it'll be fixed tomorrow.

The problem was finally with the fact that mc configure script on ppc64 defined
umode_t macro even if it was defined by sys/types.h already.