protected _start_malloc_hookĠ0812c70 g D google_malloc 00000000 Base. protected _start_google_mallocĠ080e688 g D malloc_hook 00000000 Base. I noticed there are 4 new global symbols:Ġ080efc0 g D google_malloc 00000000 Base.
My guess is Chromium is linking libtcmalloc.so.4, so the symbols are already loaded and TLS is already allocated, and malloc() has been replaced at this point before they dlopen(libwidevinecdm.so). The last 2 arguments are forcing a link to libtcmalloc.so.4 even though it is not needed by the C program, and run with LD_DEBUG=all you see it gets past linking and calls init in libwidevinecdm and results in a segmentation fault. usr/lib/ld-linux-armhf.so.3 (0xb6fb3000)Īrm-linux-gnueabihf-gcc-8 -Wall -o wvdl wvdl.c -ldl -Wl,-no-as-needed ~/libtcmalloc.so.4.5.3 You can tell because it has a dependency on the armhf dynamic linker: 20:29:53.661 T:4807 ERROR : AddOnLog: inputstream.adaptive: OpenDRMSystem failed
20:29:53.661 T:4807 ERROR : AddOnLog: inputstream.adaptive: Unable to load widevine shared library (/storage/.kodi/cdm/libwidevinecdm.so) Also the dlerror() message is squashed and never bubbles up. In any case these are the errors, but there isn't enough logging to know the issue. It appears Google may have changed the latest Widevine libraries, the size has changed by about 1M, and it is not linking all of the same libraries as it used to (perhaps some stuff is statically linked now).
0 kommentar(er)
