if compiled and run with ASan, it would report stack-use-after-return. please see https://github.com/llvm/llvm-project/issues/59723 for more details Reproducible: Always
as the upstream won't backport the fix to llvm 16, so we need to backport the fix to f38 package. filed following pull request to address this issue - https://src.fedoraproject.org/rpms/clang/pull-request/211 - https://src.fedoraproject.org/rpms/llvm/pull-request/182
FEDORA-2023-7cdaddb308 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-7cdaddb308
FEDORA-2023-7cdaddb308 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-7cdaddb308` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-7cdaddb308 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
updates-testing llvm-16.0.6-3.fc38 is somehow breaking Fedora's chromium and Google's chrome browsers. 100% reproducible. Simply upgrade llvm-libs and restart either browser to see extreme rendering glitches and slow video. https://twitter.com/wtogami/status/1699560023947399239 Screenshot of rendering glitches. This is supposed to be the Ctrl-T new window search screen. It is failing to render the images including "Google" and the icons below it. If you view any Youtube video it plays with extreme frame drop and 100% CPU.
@tchaikov Could you investigate this, please?
kernel-6.4.14-200.fc38.x86_64 AMD Ryzen 7 PRO 5850U with Radeon Graphics If I were to guess llvm-libs broke something to do with GPU hardware acceleration?
(In reply to Tulio Magno Quites Machado Filho from comment #5) > @tchaikov Could you investigate this, please? sure. will take a look this weekend. meanwhile, will keep needinfo flag.
(In reply to Warren Togami from comment #4) > updates-testing llvm-16.0.6-3.fc38 is somehow breaking Fedora's chromium and > Google's chrome browsers. > > 100% reproducible. > > Simply upgrade llvm-libs and restart either browser to see extreme rendering > glitches and slow video. > > https://twitter.com/wtogami/status/1699560023947399239 > Screenshot of rendering glitches. This is supposed to be the Ctrl-T new > window search screen. It is failing to render the images including "Google" > and the icons below it. > If you view any Youtube video it plays with extreme frame drop and 100% CPU. hi Warren, thank you for testing the testing build of llvm-libs and for the directions. but i don't really think that the updated llvm-libs is the root cause of the extreme rendering glitches and slow video on chromium and the google chrome browsers. please let me explain what's new in llvm-16.0.6-3 in comparision to the previous release (-2). the gist is the patch at https://src.fedoraproject.org/fork/tchaikov/rpms/llvm/c/2f5dbfd99349d76d24d242a7ad053c09e3af0630?branch=f38 . the change touches one of coroutine passes. these coroutine passes performs the transformations and optimizations to lower the coroutine intrinitcs to, well, lower level representations of the LLVM IR. in thie case, the CoroElide pass checks if we can avoid heap allocation by inlining the coroutine for better performance. this happens after the source code is parsed by Clang frontend, and then compiled into LLVM IR. C++20 coroutine, as its name suggests, is a C++20 features, but chomium does not use C++20 yet. see https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/c++-features.md . so, the pass should not take effect when building chromium. llvm-libs provides the shared bits of the LLVM compiler. so that, for instance, clang and llvm-ar can shared the code in a single place. in other words, llvm-libs are part of the clang's toolchain. in general, it is not even necessary from a regular user's perspective. > Simply upgrade llvm-libs and restart either browser to see extreme rendering glitches and slow video. yeah, the chromium packages are compiled using clang by default (https://src.fedoraproject.org/rpms/chromium/blob/f38/f/chromium.spec#_123). but the llvm-libs only kicks in when compiling and linking the application. once the application is built and packaged, i don't think llvm-libs is used anymore. IIUC, one can even install and use chromium without llvm-libs, as llvm-libs is not one of its (indirect) runtime dependencies. if possible, could you please try to remove llvm-libs, and test chromium and/or google's chrome browsers again?
(In reply to Kefu Chai from comment #8) > yeah, the chromium packages are compiled using clang by default > (https://src.fedoraproject.org/rpms/chromium/blob/f38/f/chromium.spec#_123). > but the llvm-libs only kicks in when compiling and linking the application. Or at runtime, when code is generated using LLVM, e.g. via Mesa's LLVMpipe. > once the application is built and packaged, i don't think llvm-libs is used > anymore. IIUC, one can even install and use chromium without llvm-libs, as > llvm-libs is not one of its (indirect) runtime dependencies. Won't this drop support for HW acceleration?
Warren, are your issues here separate from your mesa bug #2238198? i.e. are there problems with this LLVM build *without* that problematic mesa build? Either way, I wonder if it could be similar caching problems as mentioned here: https://discussion.fedoraproject.org/t/chromium-based-browsers-display-garbled-web-pages-after-mesa-is-updated/83438
> Warren, are your issues here separate from your mesa bug #2238198? > i.e. are there problems with this LLVM build *without* that problematic mesa build? The new mesa build was pushed to updates-testing after this llvm was unpushed. I had removed this llvm update before testing that mesa update. > Either way, I wonder if it could be similar caching problems as mentioned here: > https://discussion.fedoraproject.org/t/chromium-based-browsers-display-garbled-web-pages-after-mesa-is-updated/83438 That said both of these issues seem to be duplicates of Bug #2193335. Deleting chrome/chromium's generated code caches fixes both chrome and chromium with llvm-16.0.6-3.fc38. So this isn't llvm's fault. Chromium needs to learn when to invalidate its caches which is Bug #2193335. A lot of people will have an unexpected surprise from their browser. But this isn't llvm's fault.
(In reply to Tulio Magno Quites Machado Filho from comment #9) > (In reply to Kefu Chai from comment #8) > > yeah, the chromium packages are compiled using clang by default > > (https://src.fedoraproject.org/rpms/chromium/blob/f38/f/chromium.spec#_123). > > but the llvm-libs only kicks in when compiling and linking the application. > > Or at runtime, when code is generated using LLVM, e.g. via Mesa's LLVMpipe. > > > once the application is built and packaged, i don't think llvm-libs is used > > anymore. IIUC, one can even install and use chromium without llvm-libs, as > > llvm-libs is not one of its (indirect) runtime dependencies. > > Won't this drop support for HW acceleration? ahh, right. i missed the runtime code generation case. but the argument on C++20 coroutine still holds.
FEDORA-2023-7cdaddb308 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.