x86/Linux progress

[parjong]

This issue for tracking x86/Linux progress with respect to the regression tests.

Here is the current status on Ubuntu 14.04 Docker Container (on Ubuntu 16.04 x64) and full result:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  : 
# Tests Discovered : 7027
# Passed           : 5592
# Failed           : 1156
# Skipped          : 279
=======================

The above result comes from 63607d8 with https://github.com/parjong/coreclr/tree/fix/x86_4byte_alignment and dotnet/coreclr#9261.

[parjong]

\CC @seanshpark @wateret

[parjong]

63607d8 (with alignment workaround) shows the following result:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7027
# Passed           : 5892
# Failed           : 856
# Skipped          : 279
=======================
53 minutes and 59 seconds taken to run CoreCLR tests.

dotnet/coreclr#9121 seems to resolve GC and JIT related failures.

[parjong]

Here is the result from 2ecadf5 (without any additional patch):

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7027
# Passed           : 5874
# Failed           : 874
# Skipped          : 279
=======================
65 minutes and 29 seconds taken to run CoreCLR tests.

Recently merged dotnet/coreclr#8849 eliminates the need for alignment workaround. There is a small increase in the number of failed tests, and most of them are caused by stack smashing. Incorrect funclet prolog/epilog may cause this stack smashing issue.

[janvorli]

@parjong, @seanshpark, @wateret - I was trying to build and run dotnet for x86 Linux today, using the current state of the master branch, but I was unable to make it work. So I was wondering if you could share a list of steps to successfuly build and gather all parts of the dotnet core the way you do it.
I have tried to build the coreclr and corefx native binaries both using the cross build and a build inside of a docker container with x86 ubuntu 14.04 (running the container on x64 Ubuntu 14.04). I have built the corefx managed assemblies on my x64 ubuntu.
When I try to run a simple hello world like app inside of the docker container, I get a strange assertion in the native runtime even before the coreclr_initialize completes.

[parjong]

@janvorli It is a bit strange. I have used the same environment (docker container from docker image imported from x86/rootfs in Core CLR). Could you let me know the assert failure that you got?

[parjong]

And, I am currently using a bit old Core FX (although I am not sure whether it is relevant).

[janvorli]

The assert and call stack is below. I guess it has to do something with how I've collected all the files. I have created the docker image myself from vanilla Ubuntu 14.04 x86 image and installed all the dependencies, clang, etc.
Could you please write down a step by step list of how to get a working environment from scratch?

Assert failure(PID 59096 [0x0000e6d8], Thread: 59096 [0xe6d8]): Consistency check failed: Illegal null pointerFAILED: ok
         FAILED: CheckPointer(pMT)
                /home/janvorli/git/coreclr/src/vm/appdomain.cpp, line: 13816
    File: /home/janvorli/git/coreclr/src/inc/check.h Line: 373
    Image: /home/janvorli/dotnet/test/corerun

#0  DBG_DebugBreak () at debugbreak.S:114
dotnet/coreclr#1  0xf7899a88 in DebugBreak () at /home/janvorli/git/coreclr/src/pal/src/debug/debug.cpp:404
dotnet/coreclr#2  0xf6ce977c in CHECK::Setup (this=0xffffbfa4, message=0xf79daf30 "Illegal null pointer", condition=0xf7a6ba26 "ok",
    file=0xf79daf45 "/home/janvorli/git/coreclr/src/inc/check.h", line=373) at /home/janvorli/git/coreclr/src/utilcode/check.cpp:218
dotnet/coreclr#3  0xf6e3e308 in CheckPointer<MethodTable> (o=0x0, ok=NULL_NOT_OK) at /home/janvorli/git/coreclr/src/inc/check.h:373
dotnet/coreclr#4  0xf7226147 in BaseDomain::LookupType (this=0xf7c9f940 <g_pSharedDomainMemory>, id=60) at /home/janvorli/git/coreclr/src/vm/appdomain.cpp:13816
dotnet/coreclr#5  0xf72260f3 in BaseDomain::LookupType (this=0x8077208, id=60) at /home/janvorli/git/coreclr/src/vm/appdomain.cpp:13813
dotnet/coreclr#6  0xf6f4d993 in VSD_ResolveWorker (pTransitionBlock=0xffffc324, siteAddrForRegisterIndirect=354570792, token=3979264)
    at /home/janvorli/git/coreclr/src/vm/virtualcallstub.cpp:1579
dotnet/coreclr#7  0xf71f349a in ResolveWorkerAsmStub () at asmhelpers.S:1041
dotnet/coreclr#8  0xffffc324 in ?? ()
dotnet/coreclr#9  0xf4fd0222 in ?? ()
dotnet/coreclr#10 0xf633b14c in ?? ()
dotnet/coreclr#11 0xf71f31ab in CallDescrWorkerInternal () at asmhelpers.S:442
dotnet/coreclr#12 0xf6f85d08 in CallDescrWorker (pCallDescrData=0xffffcba8) at /home/janvorli/git/coreclr/src/vm/callhelpers.cpp:146
dotnet/coreclr#13 0xf6f85ab9 in CallDescrWorkerWithHandler (pCallDescrData=0xffffcba8, fCriticalCall=0) at /home/janvorli/git/coreclr/src/vm/callhelpers.cpp:89
dotnet/coreclr#14 0xf6f87a2b in MethodDescCallSite::CallTargetWorker (this=0xffffcdd8, pArguments=0xffffcf00, pReturnValue=0xffffcc18, cbReturnValue=8)
    at /home/janvorli/git/coreclr/src/vm/callhelpers.cpp:656
dotnet/coreclr#15 0xf6d56064 in MethodDescCallSite::Call_RetOBJECTREF (this=0xffffcdd8, pArguments=0xffffcf00) at /home/janvorli/git/coreclr/src/vm/callhelpers.h:436
dotnet/coreclr#16 0xf7205fd4 in AppDomain::DoSetup (this=0x8077208, setupInfo=0xffffd2f8) at /home/janvorli/git/coreclr/src/vm/appdomain.cpp:5735
dotnet/coreclr#17 0xf6d4a3cc in CorHost2::_CreateAppDomain (this=0x805e8d8, wszFriendlyName=0x805e910 u"unixcorerun", dwFlags=336, wszAppDomainManagerAssemblyName=0x0,
    wszAppDomainManagerTypeName=0x0, nProperties=5, pPropertyNames=0x805e938, pPropertyValues=0x805e958, pAppDomainID=0xffffd650)
    at /home/janvorli/git/coreclr/src/vm/corhost.cpp:1717
dotnet/coreclr#18 0xf6d4d9ac in CorHost2::CreateAppDomainWithManager (this=0x805e8d8, wszFriendlyName=0x805e910 u"unixcorerun", dwFlags=336,
    wszAppDomainManagerAssemblyName=0x0, wszAppDomainManagerTypeName=0x0, nProperties=5, pPropertyNames=0x805e938, pPropertyValues=0x805e958,
    pAppDomainID=0xffffd650) at /home/janvorli/git/coreclr/src/vm/corhost.cpp:1890
dotnet/coreclr#19 0xf6cd1623 in coreclr_initialize (exePath=0x8052014 "/home/janvorli/dotnet/test/corerun", appDomainFriendlyName=0x804e529 "unixcorerun", propertyCount=5,
    propertyKeys=0xffffd694, propertyValues=0xffffd680, hostHandle=0xffffd654, domainId=0xffffd650)
    at /home/janvorli/git/coreclr/src/dlls/mscoree/unixinterface.cpp:219
dotnet/coreclr#20 0x0804c51f in ExecuteManagedAssembly (currentExeAbsolutePath=0x8052014 "/home/janvorli/dotnet/test/corerun",
    clrFilesAbsolutePath=0x8052084 "/home/janvorli/dotnet/test", managedAssemblyAbsolutePath=0x805204c "/home/janvorli/dotnet/test/nullref.exe",
    managedAssemblyArgc=0, managedAssemblyArgv=0x0) at /home/janvorli/git/coreclr/src/coreclr/hosts/unixcoreruncommon/coreruncommon.cpp:404
dotnet/coreclr#21 0x0804b228 in corerun (argc=2, argv=0xffffd864) at /home/janvorli/git/coreclr/src/coreclr/hosts/unixcorerun/corerun.cpp:149
dotnet/coreclr#22 0x0804b35a in main (argc=2, argv=0xffffd864) at /home/janvorli/git/coreclr/src/coreclr/hosts/unixcorerun/corerun.cpp:161

[parjong]

I'll first check whether master works for me.

[parjong]

To collect Core FX managed dll(s), I used a bit old collecting script of the following form (OS is Linux):

MANAGED_TAGS=()
MANAGED_TAGS+=("AnyOS.AnyCPU")
MANAGED_TAGS+=("Unix.AnyCPU")
MANAGED_TAGS+=("${OS}.AnyCPU")

    for MANAGED_TAG in ${MANAGED_TAGS[@]}; do
      REPO="${SRC_DIR}/${MANAGED_TAG}.${PRESET}"

      for BASE in $(find "${REPO}"  -iname '*.dll' \! -iwholename '*test*' \! -iwholename '*/ToolRuntime/*' \! -iwholename '*/RemoteExecutorConsoleApp/*' \! -iwholename '*/net*' \! -iwholename '*aot*' -exec dirname {} \; | uniq | xargs -i basename {}); do
        PDB_FILE="${REPO}/${BASE}/${BASE}.pdb"
        DLL_FILE="${REPO}/${BASE}/${BASE}.dll"

        if [[ -f "${DLL_FILE}" ]]; then
          cp -t "${MANAGED_BIN_FILE_INTO}" "${DLL_FILE}"
        fi
      done
    done

[parjong]

Here is the brief steps that I am currently using:

• Cross-build Core CLR with the following command and copy the artifacts into output directory:

coreclr $ ./build.sh cross x86  skipnuget debug cmakeargs "-DSKIP_LLDBPLUGIN=true" clang3.8
...
$ cp bin/Product/Linux.x86.Debug/* [OUTPUT DIR]

• Collect Core FX native so(s)

corefx $  cp bin/Linux.x86.Debug/* [OUTPUT DIR]

• Collect Core FX managed dll(s) using the above script

[janvorli]

@parjong thank you. These match the steps I have done. I guess I'll try to create the docker image from the rootfs as you've said you did to see if it makes any difference.

[parjong]

@janvorli Please let me know if there is any problem. I checked the current tip (7f3a87a) and it works for me.

[janvorli]

@parjong it is weird. I have just deleted the whole bin folder in coreclr, rebuilt the sources one more time and now it works. I am sorry for wasting your time.
Btw, I have not specified the "-DSKIP_LLDBPLUGIN=true" and the libsosplugin.so was also built fine.

[parjong]

@janvorli Thanks you for check 👍

FYI, -DSKIP_LLDBPLUGIN=true was just a workaround during bring up, but remains unchanged as lldb-plugin is not used currently.

[parjong]

Here is the result (XML) from b957f8c:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  : 
# Tests Discovered : 7027
# Passed           : 5913
# Failed           : 833
# Skipped          : 281
=======================