[regression] Undefined symbols in sdk-nightly-1.37.2-2017_02_03_23_19-64bit #4960
Comments
|
Strange, I'm not aware of changes around that time that seem like they could influence that. Bisecting to the specific commit that changed things for you would help. If that's not possible a testcase that reproduces the issue would be good. |
|
This still holds true for |
|
Does building with the environment variable |
|
After the last few hours of testing, I think I can say it is related to linking ASM.js and WASM targets in parallel. Our setup looks more or less like this: add_library("sample_lib" ...)
add_executable("sample" ...)
target_link_libraries("sample" "sample_lib")
add_executable("sample_wasm" ...)
target_link_libraries("sample_wasm" "sample_lib")
set_target_properties("sample_wasm" PROPERTIES LINK_FLAGS "-s WASM=1")This works fine for small sample projects. It also mostly works fine on bigger projects on a machine with excess power. However when building our big projects on a VM (4 cores, 8 GB) this setup has a ~60% failure rate with random symbols reported missing. add_dependencies("sample_wasm" "sample")This issue is present in all recent nightlies, including |
|
Setting |
|
Hi, Then starting from Because of non-deterministic nature of this issue, I'm not 100% positive yet that mentioned version is the one what introduced this behavior. |
|
The issue still persists, in latest nightlies as well as latest incomming (as of this morning, March 7th, 7:30 CET). The workaround described above (preventing linking ASM.js and WASM in parallel) does not completely remove the problem, but drastically reduces the failure rate. It failed once with random symbols missing in a period of a week or so. The random missing symbols happen when linking ASM.js. |
|
I suppose the VM client OS is 64-bit? How much swap space does it have, can running out of swap space be safely ruled out? Have you ever seen the issue outside that VM environment? Which VM software and host/client OS are being used? The call stack text file I got via email suggests that an earlier llvm link/output run has written out a corrupted object file, which causes the later llvm-nm call to crash. |
|
Hi @juj, in my cases it was native Linux Ubuntu 16.04, also I reproduced this on Fedora 25. 32GB of RAM for both cases. |
|
@juj the issues are reproduced on multiple machines (both VM and bare metal), running out of memory can be safely ruled out as the memory usage never goes above 50%. I am testing our big project on various versions of 64-bit Ubuntu Linux (14.04 LTS, 15.04, and 16.04.1 LTS). The call stack I mailed you was running on bare metal. |
…ss from subprocesses. Clean up temporary directory created for llvm-ar at process exit. Fix race condition in llvm-ar temporary directory creation. Fixes emscripten-core#4960.
…ss from subprocesses. Clean up temporary directory created for llvm-ar at process exit. Fix race condition in llvm-ar temporary directory creation. Fixes emscripten-core#4960.
|
I was able to reproduce this by building another big project multiple times in parallel, and I think I found the issue. The above PR should provide a fix. |
|
Hi, Test configuration: Test unmodified nightly, 10 times
Test of patched nightly version with #5004
In meantime while I will do a stress test of this solution with more samples, @artur-matuszewski might try to confirm another case with a larger project and sequential linkage. Edit: Text correction, ATM: Artur didn't confirm that it works for his use-case. |
|
Hi @juj Test configurationSDK: 'sdk-incoming-64bit' compiled with
Unmodified SDK
Please note that in this test error rate is lower than in nightly build. Patched SDK with #5004
poke @kripken:
513,515c513,515
< (export "_testSetjmp" (func $4282))
< (export "_saveSetjmp" (func $4278))
< (export "_free" (func $3870))
---
> (export "_testSetjmp" (func $4283))
> (export "_saveSetjmp" (func $4279))
> (export "_free" (func $3871))later in a whole file enumeration of functions is shifted by 1,
|
|
Since #5004 is already merged, I tested the latest |
|
I think this case is closed, I spawned: WebAssembly/binaryen#936 to investigate wasm build corruption. |
Hi,
sdk-nightly-1.37.2-2017_02_03_23_19-64bit has introduced to our compilation process problem with undefined symbols, it looks that every further release has this problem.
All symbols come form our game implementation.
Tested project was compiled with 'debug' mode. Please let me know how I can provide you more information.
The text was updated successfully, but these errors were encountered: