failed to compile android in ecryptfs

[jonathan]

I don't compile android in ecryptfs on ubuntu 10.04 and ubuntu 12.04.

1 Android building enviroment

   a. mkdir ~/android ~/android_work

   b. mount -t ecryptfs ~/android ~/android_work

       select read plan text option

   c. cd ~/android

   d. tar zvfx android.tar.gz

   f. cd ~/android_work/android

   g. make -j4

   When compile android , there are some error information :

Included from external/llvm/lib/Target/ARM/ARM.td:17:
Included from frameworks/compile/slang/BitWriter_2_9/../../../../external/llvm/include/llvm/Target/Target.td:16:
Included from frameworks/compile/slang/BitWriter_2_9/../../../../external/llvm/include/llvm/Intrinsics.td:442:
frameworks/compile/slang/BitWriter_2_9/../../../../external/llvm/include/llvm/IntrinsicsPowerPC.td:466:1: error: Unexpected character

^
Included from external/llvm/lib/Target/ARM/ARM.td:17:
Included from frameworks/compile/slang/BitWriter_2_9/../../../../external/llvm/include/llvm/Target/Target.td:16:
Included from frameworks/compile/slang/BitWriter_2_9/../../../../external/llvm/include/llvm/Intrinsics.td:442:
frameworks/compile/slang/BitWriter_2_9/../../../../external/llvm/include/llvm/IntrinsicsPowerPC.td:466:1: error: Unexpected input at top level

^
Included from external/llvm/lib/Target/ARM/ARM.td:17:
.... ....

   I fount the IntrinsicsPowerPC.td is only line 465, but is read line 466.

2 If need other information , please send email to me.

ProblemType: Bug
DistroRelease: Ubuntu 10.04 ( Ubuntu12.04)
Uname: Linux 2.6.32-43-generic x86_64 (Linux3.2.0-32-generic)
Architecture: amd64
EcryptfsInUse: Yes
Android version: 4.0

[Tyler Hicks (tyhicks)]

Hi Jonathan - Thanks for opening a bug report!

This bug isn't being ignored. The eCryptfs developers have been busy with the Ubuntu Developer Summit throughout the last week.

[jonathan (sprbeyond)]

1 I find llvm cause this bug .

2 According to error information, there are following code in the TGLexer.cpp(in android/external/llvm/lib/TableGen):

  tgtok::TokKind TGLexer::LexToken() {
  TokStart = CurPtr;
  // This always consumes at least one character.
  int CurChar = getNextChar();

  switch (CurChar) {
  default:
    // Handle letters: [a-zA-Z_]
    if (isalpha(CurChar) || CurChar == '_')
      return LexIdentifier();

    printf(" TGLexer::LexToken : 0x%x-0x%x\n", CurChar, EOF);
    // Unknown character, emit an error.
    return ReturnError(TokStart, "Unexpected character");
  case EOF: return tgtok::Eof;
  ... ...

3 Analyzing code

3.1 When reading next char following real last char of the file , the char is n't EOF. why?

3.2 The proccess of reading file:

    MemoryBuffer::getFile->MemoryBuffer::getOpenFile->shouldUseMmap

[jonathan (sprbeyond)]

3.3 Should the char following the end of file in mapped buffer be zero? Android think so. Please read following code:

  int TGLexer::getNextChar() {
  char CurChar = *CurPtr++;
  switch (CurChar) {
  default:
    return (unsigned char)CurChar;
  case 0: { // token of the end of file ?????????????????????????????/

    // A nul character in the stream is either the end of the current buffer or
    // a random nul in the file. Disambiguate that here.
    if (CurPtr-1 != CurBuf->getBufferEnd())
      return 0; // Just whitespace.

    // If this is the end of an included file, pop the parent file off the
    // include stack.
    SMLoc ParentIncludeLoc = SrcMgr.getParentIncludeLoc(CurBuffer);
    if (ParentIncludeLoc != SMLoc()) {
      CurBuffer = SrcMgr.FindBufferContainingLoc(ParentIncludeLoc);
      CurBuf = SrcMgr.getMemoryBuffer(CurBuffer);
      CurPtr = ParentIncludeLoc.getPointer();
      return getNextChar();
    }

    // Otherwise, return end of file.
    --CurPtr; // Another call to lex will return EOF again.
    return EOF;
  }

[jonathan (sprbeyond)]

 I find the reason that bug occur:

1 Normally, zero indicate the read position is end of file. but now the next char to end of file is not zero, so error occur.

2 why is not zero? I think ecryptfs bring about it.

3 what do ecryptfs when reading file? I don't know.

[Tyler Hicks (tyhicks)]

Hi Jonathan - I'm unable to reproduce this bug. Using Ubuntu 12.04 (kernel 3.2.0-32-generic #51-Ubuntu), I followed the instructions on building Android from here:

http://source.android.com/source/initializing.html

I had no problem building "full-eng" inside of an eCryptfs mount, with the ecryptfs_passthrough mount option. I built it successfully with -j4 and with -j8.

As I mentioned in another bug report (https://bugs.launchpad.net/ecryptfs/+bug/1093072/comments/1), I'm unable to reproduce a couple of your bugs and I wonder if you have hardware issues. memtest86 is probably a good start.

Reopen this bug if you cannot identify any hardware issues and the bug is still reproduceable for you.

[jonathan (sprbeyond)]

1 a. mkdir ~/android ~/android_work

   b. mount -t ecryptfs ~/android ~/android_work

       select read plan text option

   c. cd ~/android

   d. tar zvfx android.tar.gz

   f. cd ~/android_work/android

   g. make -j4

2 android version is 4.0 or 4.2

do you compiled android with above condition?

I am sure this bug is caused by hardware issues.

[jonathan (sprbeyond)]

I am sure this bug is not caused by hardware issues.

[Tyler Hicks (tyhicks)]

Why are you sure that this bug is not caused by hardware issues? I'm unable to reproduce it and you're the only person affected by this bug. You filed another eCryptfs bug that is in the same state (I can't reproduce it and you're the only one affected).

You _must_ run memtest86 to verify that you don't have memory corruption issues before I devote any more time to this bug.

[jonathan (sprbeyond)]

this bug must be caused every time when compiling android4.0 or android 4.2 on five different phyical computes.

but i modify shouldUseMmap function to always return false in MemoryBuffer.c, this bug don't happen.