Shader compilation error in 0.3.0

gagarin55 commented 3 years ago

Ubuntu 20.04, VirtualBox. Compose Desktop 0.3.0 after run crashed. It was OK with 0.3.0-build*

Shader compilation error
------------------------
   1    uniform sampler2D uTextureSampler_0_Stage0;
   2    in half3 vinShadowParams_Stage0;in half4 vinColor_Stage0;void main() {half4 outputColor_Stage0;half4 outputCoverage_Stage0;{ // Stage 0, RRectShadow
   3    half3 shadowParams;shadowParams = vinShadowParams_Stage0;outputColor_Stage0 = vinColor_Stage0;half d = length(shadowParams.xy);float2 uv = float2(shadowParams.z * (1.0 - d), 0.5);half factor = sample(uTextureSampler_0_Stage0, uv).a;outputCoverage_Stage0 = half4(factor);}{ // Xfer Processor: Porter Duff
   4    sk_FragColor = outputColor_Stage0 * outputCoverage_Stage0;}}
Errors:
error: 3: floating-point value is too large: 1.0
3: floating-point value is too large: 1.0

1 error

free(): invalid pointer

olonho commented 3 years ago

What application did you run?

gagarin55 commented 3 years ago

Default empty project by Kotlin Multiplatform template

olonho commented 3 years ago

Seems to be related to https://github.com/JetBrains/compose-jb/issues/413 , crash looks like this

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7d94859 in __GI_abort () at abort.c:79
#2  0x00007ffff7dff3ee in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7f29285 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007ffff7e0747c in malloc_printerr (str=str@entry=0x7ffff7f274ae "free(): invalid pointer") at malloc.c:5347
#4  0x00007ffff7e08cac in _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:4173
#5  0x00007fffb8b5596a in std::locale::_Impl::~_Impl() () from /lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007fffb8b55bb7 in std::locale::~locale() () from /lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x00007fffb8bae575 in std::basic_ios<char, std::char_traits<char> >::imbue(std::locale const&) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#8  0x00007fffba8ec30d in SkSL::stod(SkSL::StringFragment const&, float*) ()
   from /home/test/.skiko/d517b586bca16b08ad774360b0733675e27186b21df9755ecb2cf2098c5f7a44/libskiko-linux-x64.so
#9  0x00007fffba8d5b95 in SkSL::Parser::floatLiteral(float*) ()
   from /home/test/.skiko/d517b586bca16b08ad774360b0733675e27186b21df9755ecb2cf2098c5f7a44/libskiko-linux-x64.so
#10 0x00007fffba8dc3f8 in SkSL::Parser::term() () from /home/test/.skiko/d517b586bca16b08ad774360b0733675e27186b21df9755ecb2cf2098c5f7a44/libskiko-linux-x64.so
#11 0x00007fffba8dc85e in SkSL::Parser::postfixExpression() ()
   from /home/test/.skiko/d517b586bca16b08ad774360b0733675e27186b21df9755ecb2cf2098c5f7a44/libskiko-linux-x64.so
#12 0x00007fffba8dca26 in SkSL::Parser::unaryExpression() ()

jimgoog commented 3 years ago

It is not yet clear to me if error: 4: floating-point value is too large: 1.0 is the cause of free(): invalid pointer or just a second bug also occurring on Linux machines and thus commonly seen together. But yes, it does seem believable that they're related.

olonho commented 3 years ago

Bug is actually here:

#7  0x00007fffb8bae575 in std::basic_ios<char, std::char_traits<char> >::imbue(std::locale const&) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#8  0x00007fffba8ec30d in SkSL::stod(SkSL::StringFragment const&, float*) ()

Although we linked libstdc++ as static library, system libstdc++ was invoked via PLT and we intermixed two implementations of libstdc++, which surely will not work.

olonho commented 3 years ago

Interestingly, if one will use Ubuntu provided OpenJDK build (i.e. sudo apt install openjdk-14-jdk) everything works, but is triggered only if use AdoptOpenJDK or Oracle JVM builds.

olonho commented 3 years ago

Seems it works as

ubuntu@ubuntu2004:~/compose/compose-jb/examples/codeviewer$ ldd /usr/lib/jvm/java-14-openjdk-amd64/lib/server/libjvm.so 
    linux-vdso.so.1 (0x00007fff99d01000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f96f5e88000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f96f5e65000)
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f96f5c84000)
^^^^^^^^^^
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f96f5b35000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f96f5b1a000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f96f5928000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f96f7133000)

vs.

ubuntu@ubuntu2004:~/compose/compose-jb/examples/codeviewer$ ldd /usr/lib/jvm/jdk-15.0.2+7/lib/server/libjvm.so 
    linux-vdso.so.1 (0x00007fffebf78000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0afb526000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0afb503000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0afb3b4000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0afb1c2000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f0afca8b000)

I.e. non-vendor builds include C++ standard lib into the VM binary.

olonho commented 3 years ago

So for now one could just use Ubuntu's packaged JDK as a workaround.

jimgoog commented 3 years ago

cc @theapache64

gagarin55 commented 3 years ago

Interestingly, if one will use Ubuntu provided OpenJDK build (i.e. sudo apt install openjdk-14-jdk) everything works, but is triggered only if use AdoptOpenJDK or Oracle JVM builds.

I'm using follows

$ java -version
openjdk version "15-ea" 2020-09-15
OpenJDK Runtime Environment (build 15-ea+32-Ubuntu-220.04)
OpenJDK 64-Bit Server VM (build 15-ea+32-Ubuntu-220.04, mixed mode, sharing)

UPDATE: same for openjdk-14