DDMAL
MEI status is always checking for Einsiedeln
As shown in the screenshot, when uploading the Einsiedeln manuscript to neon, the MEI status is always checking. This appears in both browser neon and local neon.
The error shows in the console is:
Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 16777216, (2) compile with -s ALLOW_MEMORY_GROWTH=1 which adjusts the size at runtime but prevents some optimizations, (3) set Module.TOTAL_MEMORY to a higher value before the program runs, or if you want malloc to return NULL (0) instead of this abort, compile with -s ABORTING_MALLOC=0
We have come up with a temporary fix that will allow for the Einsiedeln files to be checked and declared valid or invalid in browser. Rather than TOTAL_MEMORY: options.TOTAL_MEMORY, , we changed it to TOTAL_MEMORY:26777216 to be able to accommodate the additional space needed. Something that is not hardcoding would be preferred, but we will look into that later.
Yesterday I tried to build Verovio with the following command.
./buildToolkit -x "Gootville,Petaluma" -wDHPX
w enables WASM compiling. At first, it worked well with einsiedeln. But to be sure, I tried to build without w and then with w again, it reports an error:
wasm-ld: error: libverovio.a(pugixml.cpp.o): undefined symbol: typeinfo for std::bad_alloc wasm-ld: error: libverovio.a(pugixml.cpp.o): undefined symbol: typeinfo for std::bad_alloc wasm-ld: error: libverovio.a(pugixml.cpp.o): undefined symbol: typeinfo for std::bad_alloc wasm-ld: error: libverovio.a(pugixml.cpp.o): undefined symbol: typeinfo for std::bad_alloc wasm-ld: error: libverovio.a(pugixml.cpp.o): undefined symbol: typeinfo for std::bad_alloc wasm-ld: error: libverovio.a(pugixml.cpp.o): undefined symbol: typeinfo for std::bad_alloc wasm-ld: error: libverovio.a(pugixml.cpp.o): undefined symbol: vtable for __cxxabiv1::__si_class_type_info wasm-ld: error: libverovio.a(pugixml.cpp.o): undefined symbol: typeinfo for std::exception wasm-ld: error: libverovio.a(pugixml.cpp.o): undefined symbol: vtable for __cxxabiv1::__class_type_info wasm-ld: error: libverovio.a(pugixml.cpp.o): undefined symbol: vtable for __cxxabiv1::__si_class_type_info wasm-ld: error: libverovio.a(pugixml.cpp.o): undefined symbol: vtable for __cxxabiv1::__class_type_info wasm-ld: error: libverovio.a(vrv.cpp.o): undefined symbol: typeinfo for std::out_of_range wasm-ld: error: libverovio.a(vrv.cpp.o): undefined symbol: vtable for std::__2::basic_stringstream<char, std::__2::char_traits
, std::__2::allocator > wasm-ld: error: libverovio.a(vrv.cpp.o): undefined symbol: vtable for std::__2::basic_stringstream<char, std::__2::char_traits , std::__2::allocator > wasm-ld: error: libverovio.a(vrv.cpp.o): undefined symbol: VTT for std::__2::basic_stringstream<char, std::__2::char_traits , std::__2::allocator > wasm-ld: error: libverovio.a(vrv.cpp.o): undefined symbol: VTT for std::__2::basic_stringstream<char, std::__2::char_traits , std::__2::allocator > wasm-ld: error: libverovio.a(vrv.cpp.o): undefined symbol: VTT for std::__2::basic_stringstream<char, std::__2::char_traits , std::__2::allocator > wasm-ld: error: libverovio.a(vrv.cpp.o): undefined symbol: VTT for std::__2::basic_stringstream<char, std::__2::char_traits , std::__2::allocator > wasm-ld: error: libverovio.a(vrv.cpp.o): undefined symbol: VTT for std::__2::basic_stringstream<char, std::__2::char_traits , std::__2::allocator > wasm-ld: error: libverovio.a(vrv.cpp.o): undefined symbol: VTT for std::__2::basic_stringstream<char, std::__2::char_traits , std::__2::allocator > wasm-ld: error: too many errors emitted, stopping now (use -error-limit=0 to see all errors) emcc: error: '/Users/yinanzhou/SIMSSA/verovio/emscripten/emsdk/upstream/bin/wasm-ld -o build/verovio.wasm libverovio.a -L/Users/yinanzhou/SIMSSA/verovio/emscripten/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten -lc -lcompiler_rt -ldlmalloc -lc_rt_wasm -lsockets --fatal-warnings -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --import-undefined --strip-debug --export-if-defined=vrvToolkit_constructor --export-if-defined=vrvToolkit_destructor --export-if-defined=vrvToolkit_edit --export-if-defined=vrvToolkit_editInfo --export-if-defined=vrvToolkit_getAvailableOptions --export-if-defined=vrvToolkit_getElementAttr --export-if-defined=vrvToolkit_getElementsAtTime --export-if-defined=vrvToolkit_getExpansionIdsForElement --export-if-defined=vrvToolkit_getHumdrum --export-if-defined=vrvToolkit_getLog --export-if-defined=vrvToolkit_getMEI --export-if-defined=vrvToolkit_getMIDIValuesForElement --export-if-defined=vrvToolkit_getNotatedIdForElement --export-if-defined=vrvToolkit_getOptions --export-if-defined=vrvToolkit_getPageCount --export-if-defined=vrvToolkit_getPageWithElement --export-if-defined=vrvToolkit_getTimeForElement --export-if-defined=vrvToolkit_getVersion --export-if-defined=vrvToolkit_loadData --export-if-defined=vrvToolkit_redoLayout --export-if-defined=vrvToolkit_redoPagePitchPosLayout --export-if-defined=vrvToolkit_renderData --export-if-defined=vrvToolkit_renderToMIDI --export-if-defined=vrvToolkit_renderToSVG --export-if-defined=vrvToolkit_renderToTimemap --export-if-defined=vrvToolkit_setOptions --export-if-defined=stackSave --export-if-defined=stackRestore --export-if-defined=stackAlloc --export-if-defined=__wasm_call_ctors --export-if-defined=__errno_location --export-if-defined=malloc --export-if-defined=free --export-if-defined=_get_tzname --export-if-defined=_get_daylight --export-if-defined=_get_timezone --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-table -z stack-size=268435456 --initial-memory=536870912 --no-entry --max-memory=536870912 --global-base=1024' failed (returned 1) Failed.
I went through the issue all over again. It seems to happen within xmllint.js and has nothing to do with verovio. xmllint cannot process large files (https://knowledgebase.progress.com/articles/Article/P11630). The best solution I found so far is to validate XML with a hardcoded TOTAL_MEMORY value (https://github.com/kripken/xml.js/issues/12) like we did previously.
@yinanazhou we think this doesn't happen anymore. Could you confirm we can close this issue?
This issue is related to issue #767, about xmllint in Neon. It is temporarily solved with a hardcoded memory limit. We need to find a better way to solve this.