castfs is broken with fuse >=2.8.7 on i686 and x86_64 (Bug #393)


Added by Vlad Glagolev about 2 years ago. Updated over 1 year ago.


Status:Closed Start date:05/15/2012
Priority:Immediate Due date:
Assignee:Vlad Glagolev % Done:

100%

Category:Disk
Target version:-
Grimoire:Test

Description

For some spells, at least for 'gettext', which is critical, it's broken on i686 arch.

Steps to reproduce:

1. cast -c fuse
2. cast -c castfs
(doesn't matter is it statically or dynamically linked)
3. cast -c gettext

on installation phase you get an infinite loop with "Transport endpoint is not connected" errors.
until it's solved, fuse will stay for 2.8 branch. Bump to 2.9.* will be reverted in a second.


History

Updated by Vlad Glagolev about 2 years ago

Confirming for x86_64 too (linux spell)

  • Subject changed from castfs is broken with fuse >=2.9.0 on i686 to castfs is broken with fuse >=2.9.0 on i686 and x86_64
  • Status changed from New to In Progress

Updated by Vlad Glagolev about 2 years ago

After deeper digging through the issue and aggressive testing I've found that this bug appeared even earlier -- in 2.8.7.
Here it is.

What behaviour we receive, even when trying to cast fuse itself (when 2.8.7 is compiled, and castfs is linked against it):

Preparing to install fuse
Dispelled spell: fuse
castfs: checking sanity of <mnt-dir> and <stage-dir>
castfs: stagedir is okay!
Installing fuse into the stage
Making install in include
make[1]: Entering directory `/usr/src/fuse-2.8.7/include'
make[2]: Entering directory `/usr/src/fuse-2.8.7/include'
make[2]: Nothing to be done for `install-exec-am'.
test -z "/usr/include/fuse" || /bin/mkdir -p "/usr/include/fuse" 
test -z "/usr/include" || /bin/mkdir -p "/usr/include" 
 /bin/install -c -m 644 fuse.h fuse_compat.h fuse_common.h fuse_common_compat.h fuse_lowlevel.h fuse_lowlevel_compat.h fuse_opt.h cuse_lowlevel.h '/usr/include/fuse'
 /bin/install -c -m 644 old/fuse.h ulockmgr.h '/usr/include'
make[2]: Leaving directory `/usr/src/fuse-2.8.7/include'
make[1]: Leaving directory `/usr/src/fuse-2.8.7/include'
Making install in lib
make[1]: Entering directory `/usr/src/fuse-2.8.7/lib'
make[2]: Entering directory `/usr/src/fuse-2.8.7/lib'
test -z "//lib" || /bin/mkdir -p "//lib" 
make[2]: Nothing to be done for `install-data-am'.
 /bin/sh ../libtool   --mode=install /bin/install -c   libfuse.la libulockmgr.la '//lib'
libtool: install: /bin/install -c .libs/libfuse.so.2.8.7 //lib/libfuse.so.2.8.7
libtool: install: (cd //lib && { ln -s -f libfuse.so.2.8.7 libfuse.so.2 || { rm -f libfuse.so.2 && ln -s libfuse.so.2.8.7 libfuse.so.2; }; })
libtool: install: (cd //lib && { ln -s -f libfuse.so.2.8.7 libfuse.so || { rm -f libfuse.so && ln -s libfuse.so.2.8.7 libfuse.so; }; })
libtool: install: /bin/install -c .libs/libfuse.lai //lib/libfuse.la
libtool: install: /bin/install -c .libs/libulockmgr.so.1.0.1 //lib/libulockmgr.so.1.0.1
libtool: install: (cd //lib && { ln -s -f libulockmgr.so.1.0.1 libulockmgr.so.1 || { rm -f libulockmgr.so.1 && ln -s libulockmgr.so.1.0.1 libulockmgr.so.1; }; })
libtool: install: (cd //lib && { ln -s -f libulockmgr.so.1.0.1 libulockmgr.so || { rm -f libulockmgr.so && ln -s libulockmgr.so.1.0.1 libulockmgr.so; }; })
libtool: install: /bin/install -c .libs/libulockmgr.lai //lib/libulockmgr.la
libtool: install: /bin/install -c .libs/libfuse.a //lib/libfuse.a
libtool: install: chmod 644 //lib/libfuse.a
libtool: install: ranlib //lib/libfuse.a
libtool: install: /bin/install -c .libs/libulockmgr.a //lib/libulockmgr.a
libtool: install: chmod 644 //lib/libulockmgr.a
libtool: install: ranlib //lib/libulockmgr.a
ranlib: unable to rename '//lib/libulockmgr.a'; reason: Software caused connection abort
tee: /tmp/sorcery/cast/21486/fuse.compile.log: Transport endpoint is not connected
make[2]: *** [install-libLTLIBRARIES] Error 1
tee: /tmp/sorcery/cast/21486/fuse.compile.log: Transport endpoint is not connected
make[2]: Leaving directory `/usr/src/fuse-2.8.7/lib'
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/usr/src/fuse-2.8.7/lib'
make: *** [install-recursive] Error 1
Running make with 2 jobs failed. Attempt to run with a single job? [y] tee: /tmp/sorcery/cast/21486/fuse.compile.log: Transport endpoint is not connected
n
/var/lib/sorcery/modules/liblock: line 81: /bin/mkdir: Transport endpoint is not connected
/var/lib/sorcery/modules/liblock: line 85: sleep: command not found
/var/lib/sorcery/modules/liblock: line 55: sleep: command not found
/var/lib/sorcery/modules/liblock: line 81: /bin/mkdir: Transport endpoint is not connected
/var/lib/sorcery/modules/liblock: line 85: sleep: command not found
/var/lib/sorcery/modules/liblock: line 55: sleep: command not found
/var/lib/sorcery/modules/liblock: line 81: /bin/mkdir: Transport endpoint is not connected
/var/lib/sorcery/modules/liblock: line 85: sleep: command not found
/var/lib/sorcery/modules/liblock: line 55: sleep: command not found
/var/lib/sorcery/modules/liblock: line 81: /bin/mkdir: Transport endpoint is not connected
/var/lib/sorcery/modules/liblock: line 85: sleep: command not found
/var/lib/sorcery/modules/liblock: line 55: sleep: command not found
...

It's tested with multijob build too.

Noone noticed the bug cause castfs was never triggered (or someone just still use installwatch-only systems) on fuse update.
Now it is fixed with 14b13f11a597c7d31c2cf8bae44f89be2a1747bf in test.

What we need to do, is understand, probably with help of Remko where the actual bug sits in.

As a temporary fix (3a7b1e7288b43bf3621926568abe189a5c13d59d in test) was revert of official patch to our current spell version -- 2.9.0.
Tested on both arches -- no problems so far.

All these changes have been ported to devel-xorg-modular and stable-rc-0.61 branches.

  • Assignee set to Remko van der Vossen
  • % Done changed from 0 to 10
  • Subject changed from castfs is broken with fuse >=2.9.0 on i686 and x86_64 to castfs is broken with fuse >=2.8.7 on i686 and x86_64

Updated by Vlad Glagolev almost 2 years ago

Oh well, it took almost 3 months to find and fix the issue by ustream.

The error was pretty easy:

-                       free(path1);
+                       free(*path1);

Fixed in upstream vcs with (3c4c063a2fd5cc6e9ce2b5db82e2a0dfa59b2e40), and also in new 2.9.1 release tarball.

Fixed in test grimoire with (382a264886735197a83dcf8c700e541a77dd2c04).

Tested on x86_64 and i686.

Marking the bug as resolved.

  • % Done changed from 10 to 100
  • Assignee changed from Remko van der Vossen to Vlad Glagolev
  • Status changed from In Progress to Resolved

Updated by Vlad Glagolev over 1 year ago

Closing the bug.

  • Status changed from Resolved to Closed

Also available in: Atom PDF