failed to compile android in ecryptfs

Bug #1073399 reported by jonathan
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
eCryptfs
Incomplete
High
Tyler Hicks

Bug Description

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

Revision history for this message
Tyler Hicks (tyhicks) wrote :

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.

Changed in ecryptfs:
assignee: nobody → Tyler Hicks (tyhicks)
importance: Undecided → High
Revision history for this message
jonathan (sprbeyond) wrote :

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

Revision history for this message
jonathan (sprbeyond) wrote :

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;
  }

Revision history for this message
jonathan (sprbeyond) wrote :

 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)
Changed in ecryptfs:
status: New → In Progress
Revision history for this message
Tyler Hicks (tyhicks) wrote :

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.

Changed in ecryptfs:
status: In Progress → Invalid
Revision history for this message
jonathan (sprbeyond) wrote :

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.

Changed in ecryptfs:
status: Invalid → Confirmed
status: Confirmed → Invalid
status: Invalid → Incomplete
Revision history for this message
jonathan (sprbeyond) wrote :

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

Revision history for this message
Tyler Hicks (tyhicks) wrote :

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.

Revision history for this message
jonathan (sprbeyond) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.