Comments (8)
Hi @der-eismann,
I'd guess this is the C++ stdlib.
C++ programs need some code (not the std::
functions, this is more basic) linked in at runtime to support things like memory allocation and exception handling. clang and gcc handle this differently (from memory, clang needs a separate item on the link line? I forget) and you need to be cautious. If you link the wrong libc++, you'll get crashes.
It works OK on ubuntu 23.10, I see:
$ CC=clang CXX=clang++ meson setup build --prefix ~/vips --libdir lib -Dmagick=disabled
... stuff
$ cd build/
$ ninja install
...
And we build with clang for fuzzing, so it should work.
from libvips.
It looks like it's failing in library introspection. You probably don't need this, try adding -Dintrospection=disabled
to your meson setup line.
from libvips.
This appears to be a crash in Clang during linking with the -flto
flag; unfortunately, this happens while linking libvips.so.42
, so -Dintrospection=disabled
does not mitigate the issue.
Details
$ coredumpctl debug
[...]
Program terminated with signal SIGSEGV, Segmentation fault.
#0 std::vector<std::unique_ptr<llvm::GlobalValueSummary, std::default_delete<llvm::GlobalValueSummary> >, std::allocator<std::unique_ptr<llvm::GlobalValueSummary, std::default_delete<llvm::GlobalValueSummary> > > >::data (this=0x18)
at /usr/bin/../lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/bits/stl_vector.h:1263
1263 { return _M_data_ptr(this->_M_impl._M_start); }
(gdb) bt
#0 std::vector<std::unique_ptr<llvm::GlobalValueSummary, std::default_delete<llvm::GlobalValueSummary> >, std::allocator<std::unique_ptr<llvm::GlobalValueSummary, std::default_delete<llvm::GlobalValueSummary> > > >::data (this=0x18)
at /usr/bin/../lib/gcc/x86_64-redhat-linux/13/../../../../include/c++/13/bits/stl_vector.h:1263
#1 llvm::ArrayRef<std::unique_ptr<llvm::GlobalValueSummary, std::default_delete<llvm::GlobalValueSummary> > >::ArrayRef<std::allocator<std::unique_ptr<llvm::GlobalValueSummary, std::default_delete<llvm::GlobalValueSummary> > > > (
Vec=<error reading variable: Cannot access memory at address 0x20>, this=<optimized out>) at /usr/src/debug/llvm-17.0.6-3.fc39.x86_64/include/llvm/ADT/ArrayRef.h:97
#2 llvm::ValueInfo::getSummaryList (this=<optimized out>) at /usr/src/debug/llvm-17.0.6-3.fc39.x86_64/include/llvm/IR/ModuleSummaryIndex.h:189
#3 llvm::computeDeadSymbolsAndUpdateIndirectCalls(llvm::ModuleSummaryIndex&, llvm::DenseSet<unsigned long, llvm::DenseMapInfo<unsigned long, void> > const&, llvm::function_ref<llvm::PrevailingType (unsigned long)>)::$_0::operator()(llvm::ValueInfo, bool) const (this=0x7ffcdd4c04d0, VI=..., IsAliasee=false) at /usr/src/debug/llvm-17.0.6-3.fc39.x86_64/lib/Transforms/IPO/FunctionImport.cpp:962
#4 0x00007f3bbc247bee in llvm::computeDeadSymbolsAndUpdateIndirectCalls(llvm::ModuleSummaryIndex&, llvm::DenseSet<unsigned long, llvm::DenseMapInfo<unsigned long, void> > const&, llvm::function_ref<llvm::PrevailingType (unsigned long)>)
(Index=..., GUIDPreservedSymbols=..., isPrevailing=...) at /usr/src/debug/llvm-17.0.6-3.fc39.x86_64/lib/Transforms/IPO/FunctionImport.cpp:1013
#5 0x00007f3bbc7e6a72 in llvm::computeDeadSymbolsWithConstProp(llvm::ModuleSummaryIndex&, llvm::DenseSet<unsigned long, llvm::DenseMapInfo<unsigned long, void> > const&, llvm::function_ref<llvm::PrevailingType (unsigned long)>, bool) (
Index=..., GUIDPreservedSymbols=..., isPrevailing=..., ImportEnabled=<optimized out>) at /usr/src/debug/llvm-17.0.6-3.fc39.x86_64/lib/Transforms/IPO/FunctionImport.cpp:1034
#6 llvm::lto::LTO::run(std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_delete<llvm::CachedFileStream> > > (unsigned int, llvm::Twine const&)>, std::function<llvm::Expected<std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_delete<llvm::CachedFileStream> > > (unsigned int, llvm::Twine const&)> > (unsigned int, llvm::StringRef, llvm::Twine const&)>) (this=0x55e9f9a8f370, AddStream=..., Cache=...)
at /usr/src/debug/llvm-17.0.6-3.fc39.x86_64/lib/LTO/LTO.cpp:1174
#7 0x00007f3bcf2d782b in runLTO () at /usr/src/debug/llvm-17.0.6-3.fc39.x86_64/tools/gold/gold-plugin.cpp:1099
#8 allSymbolsReadHook () at /usr/src/debug/llvm-17.0.6-3.fc39.x86_64/tools/gold/gold-plugin.cpp:1123
#9 0x00007f3bcf2d1b3e in all_symbols_read_hook () at /usr/src/debug/llvm-17.0.6-3.fc39.x86_64/tools/gold/gold-plugin.cpp:1148
#10 0x000055e9f69a57b2 in plugin_call_all_symbols_read () at ../../ld/plugin.c:1329
#11 lang_process () at ../../ld/ldlang.c:7943
#12 0x000055e9f698e533 in main (argc=96, argv=<optimized out>) at ../../ld/ldmain.c:499
A similar crash was reported in llvm/llvm-project#62613.
from libvips.
I think the cc.links
fix resolves this, and will be in 8.15.2. I'll close.
from libvips.
Awesome, thanks!
from libvips.
I think the cc.links fix resolves this, and will be in 8.15.2. I'll close.
I wasn't expecting #3888 to fix this but happy if it has.
There's a downstream Gentoo bug about this too - see https://bugs.gentoo.org/921728
from libvips.
This appears to impact the build of the OSS-Fuzz introspector as well, see:
https://oss-fuzz-build-logs.storage.googleapis.com/log-28bb0e48-641c-430c-b5d3-45963d09534f.txt
https://github.com/google/oss-fuzz/blob/bf577d8664b7f7c06ba42f95c01f9161c73cd5ff/infra/base-images/base-builder/Dockerfile#L73C39-L73C44
Details
$ gdb /usr/bin/x86_64-linux-gnu-ld.gold 'core.ld\x2egold.1000.f0e7e2cf4aaa4465acc8476884e70e1f.217441.1714902089000000'
[...]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/ld.gold -pie -z relro --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -d'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fba4c73e936 in llvm::computeDeadSymbolsAndUpdateIndirectCalls(llvm::ModuleSummaryIndex&, llvm::DenseSet<unsigned long, llvm::DenseMapInfo<unsigned long, void> > const&, llvm::function_ref<llvm::PrevailingType (unsigned long)>)::$_0::operator()(llvm::ValueInfo, bool) const () from /usr/local/bin/../lib/LLVMgold.so
(gdb) bt
#0 0x00007fba4c73e936 in llvm::computeDeadSymbolsAndUpdateIndirectCalls(llvm::ModuleSummaryIndex&, llvm::DenseSet<unsigned long, llvm::DenseMapInfo<unsigned long, void> > const&, llvm::function_ref<llvm::PrevailingType (unsigned long)>)::$_0::operator()(llvm::ValueInfo, bool) const () from /usr/local/bin/../lib/LLVMgold.so
#1 0x00007fba4c73e7bd in llvm::computeDeadSymbolsAndUpdateIndirectCalls(llvm::ModuleSummaryIndex&, llvm::DenseSet<unsigned long, llvm::DenseMapInfo<unsigned long, void> > const&, llvm::function_ref<llvm::PrevailingType (unsigned long)>)
() from /usr/local/bin/../lib/LLVMgold.so
#2 0x00007fba4c73eb62 in llvm::computeDeadSymbolsWithConstProp(llvm::ModuleSummaryIndex&, llvm::DenseSet<unsigned long, llvm::DenseMapInfo<unsigned long, void> > const&, llvm::function_ref<llvm::PrevailingType (unsigned long)>, bool) ()
from /usr/local/bin/../lib/LLVMgold.so
#3 0x00007fba4c6ded9e in llvm::lto::LTO::run(std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_delete<llvm::CachedFileStream> > > (unsigned int, llvm::Twine const&)>, std::function<llvm::Expected<std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_delete<llvm::CachedFileStream> > > (unsigned int, llvm::Twine const&)> > (unsigned int, llvm::StringRef, llvm::Twine const&)>) ()
from /usr/local/bin/../lib/LLVMgold.so
#4 0x00007fba4c3e4210 in all_symbols_read_hook() () from /usr/local/bin/../lib/LLVMgold.so
#5 0x000055b7e853c28f in ?? ()
#6 0x000055b7e853c3e0 in ?? ()
#7 0x000055b7e8581b98 in ?? ()
#8 0x000055b7e8581dea in ?? ()
#9 0x000055b7e8451ee5 in ?? ()
#10 0x00007fba4e9c5083 in __libc_start_main (main=0x55b7e84518d0, argc=103, argv=0x7ffe2a4eb388, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe2a4eb378) at ../csu/libc-start.c:308
#11 0x000055b7e8452ace in ?? ()
I haven't investigated it further yet, but I can confirm that building without -flto
resolves this (see PR #3952).
There's a downstream Gentoo bug about this too - see https://bugs.gentoo.org/921728
According to that bug report, this issue is not related to Highway.
from libvips.
I just opened PR #3953 for this and reported this reduced example upstream at llvm/llvm-project#70184 (comment).
from libvips.
Related Issues (20)
- Conversion to PFM gives incorrect output HOT 2
- Improve `tilecache` performance
- JXL Support in Libvips Web Build HOT 3
- vips: unknown action "dzsave", vips-8.15.1 on Gentoo HOT 1
- Row sums from vips_project do not necessarily give the same value like summing img(i,j) along i HOT 2
- Looks like 8.15.2 tag is wrong? HOT 1
- vips 8.15.2 failed to build with latest xcode HOT 11
- HDR AVIF to HEIC (hdr) HOT 4
- Feature request: Support SDR→HDR via RTX HDR (upmapping / inverse tone mapping)
- AVIF with bitdepth 10 or 12 crashes
- Add nclx->icc colour management to heifload HOT 24
- Segmentation fault when performing very large number of operations HOT 1
- Subsample mode not working with jpegli HOT 4
- Add target write to `rawsave` HOT 2
- Cannot link to proper libraries on Windows 11 Pro. HOT 1
- Thumbnail/Resize removes color on Alpine HOT 1
- Add support for fractional tiff values (eg. 10 or 12 bits per pixel) HOT 6
- Include JXL as Foreign TIFF Compression HOT 3
- The position of "#include <vips/vips8>" matters. HOT 2
- distance transform HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libvips.