summaryrefslogtreecommitdiffstats
path: root/vespalib
Commit message (Collapse)AuthorAgeFilesLines
* fix undefined behavior in unit tests -- WIPHåvard Pettersen2022-06-073-1/+12
|
* Remove test that invokes undefined pthread behaviorTor Brede Vekterli2022-06-072-12/+2
| | | | | | It is not well-defined to call a pthread function with a thread that is no longer valid. Remove test and add a precondition comment to the function that IDs must be valid.
* Remove vespalib::rmdir and vespalib::mkdirTor Egge2022-06-033-178/+23
|
* Merge pull request #22874 from ↵Tor Brede Vekterli2022-06-032-0/+7
|\ | | | | | | | | vespa-engine/vekterli/dump-stack-of-deadlocked-thread Let deadlock detector dump stack of potentially deadlocked threads
| * Let deadlock detector dump stack of potentially deadlocked threadsTor Brede Vekterli2022-06-022-0/+7
| | | | | | | | | | | | | | | | | | | | | | Enable cross-thread stack tracing as part of signal handler init code in both storage and proton daemons. Make deadlock detector parameters live configurable. Remove existing `restart` config definition annotations to reflect this. Remove dumping of bucket DB locks which hasn't really worked for a long time now.
* | Remove most use of vespalib::rmdir in vespalib. Deprecate vespalib::mkdir.Tor Egge2022-06-025-9/+14
|/
* Merge pull request #22788 from ↵Tor Brede Vekterli2022-06-026-26/+232
|\ | | | | | | | | vespa-engine/vekterli/add-cross-thread-stack-trace-dumping Add support for cross-thread stack dumping to vespalib
| * Really, really, really don't inline the backtrace-test functionTor Brede Vekterli2022-06-012-1/+2
| |
| * Ensure names are visible in backtrace by moving functions to a shared libraryTor Brede Vekterli2022-06-014-15/+35
| | | | | | | | Name resolving does not necessarily work for static functions.
| * No need to specify noinline for signal handler landing pad functionTor Brede Vekterli2022-06-011-3/+1
| |
| * Use compare_exchange to check and un-set pending signal handlerTor Brede Vekterli2022-06-011-3/+4
| |
| * Enable cross-thread stack tracing once for all testsTor Brede Vekterli2022-06-011-5/+5
| |
| * Simplify to just use seq_cst instead of rel/acq for signal handler completionTor Brede Vekterli2022-05-311-2/+2
| | | | | | | | Matches the use of seq_cst for the rest of the stack dumping logic.
| * Add support for cross-thread stack dumping to vespalibTor Brede Vekterli2022-05-304-26/+212
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no existing API for conveniently getting the stack trace of any other thread than your own, so we have to turn things around a bit and make the target thread dump its own stack in a way that we can then safely access and return it. We allow for hooking SIGUSR2 at process startup time and use this as our dedicated stack dump signal internally. The process of stack dumping is then basically: 1. Caller sends SIGUSR2 to the target thread. This happens within a global mutex that ensures no other callers can attempt to dump stack at the same time. This is because we use a single, globally shared state between caller and target (the same signal handler function is used by all threads). 2. Caller acquire-polls (with 1ms sleep) for target thread signal handler completion. Fancy technologies such as mutexes and condition variables are not safe to use from within a signal handler and therefore cannot be used. 3. Target thread suddenly finds itself in Narnia (signal handler). Since the signal is the magical SIGUSR2, it proceeds to dump its stack frame addresses in a shared buffer. It then toggles completion, with release semantics, before returning to its regularly scheduled programming. 4. Caller exits poll-loop and assembles a complete stack trace from the frame addresses in the shared buffer, demangled and shiny. Signal-safe stack frame dumping currently uses Boost.Stacktrace, which is a header-only dependency and appears to use libunwind under the hood.
* | Merge pull request #22854 from vespa-engine/balder/inline-tensor-access-methodsHenning Baldersheim2022-06-022-10/+4
|\ \ | | | | | | - Optimize get_tensor_ref optimizing for no branches on happy path.
| * | - Optimize get_tensor_ref optimizing for no branches on happy path.Henning Baldersheim2022-06-012-10/+4
| | | | | | | | | | | | | | | - Also drop check for reference as that is done in the next called method. - Inline DirectTensorStore::get_tensor.
* | | Merge pull request #22851 from ↵Geir Storli2022-06-023-59/+14
|\ \ \ | | | | | | | | | | | | | | | | vespa-engine/toregge/convert-vespalib-rmdir-to-deprecated-shim Convert vespalib::rmdir to a deprecated shim.
| * | | Convert vespalib::rmdir to a deprecated shim.Tor Egge2022-06-013-59/+14
| | | |
* | | | Avoid huge amounts of cold code in hot path.Henning Baldersheim2022-06-021-0/+3
| | | |
* | | | If all else is equal the compiler will assume the if branch is more likely ↵Henning Baldersheim2022-06-021-10/+10
| |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | than the else branch. This is based on experience since gcc 2.8 and til today, and is not a definitive truth. Just more likely. if (criteria) { most_likely_executed code } else { less_likely_executed code } While a single branched if is assumed less likely.
* | | When you have no special needs, you should just take the default allocator.Henning Baldersheim2022-06-012-1/+7
|/ /
* | vesapAndreas Eriksen2022-06-012-2/+2
| |
* | Avoid pulling in stringfmt.h in by moving code to .cpp file.Henning Baldersheim2022-05-312-2/+1
| |
* | Fix forward declarations.Tor Egge2022-05-311-1/+1
|/
* Avoid using vespalib::Identifiable.Henning Baldersheim2022-05-271-1/+1
|
* fix undefined behaviorHåvard Pettersen2022-05-271-1/+1
| | | | more testing means uncovering more undefined behavior
* Include searchcommon/attribut/config.h yourself and prepare for hiding large ↵Henning Baldersheim2022-05-251-0/+3
| | | | | | implementation. Add setters to vespalib::GrowStrategy.
* Merge pull request #22729 from ↵Henning Baldersheim2022-05-253-34/+45
|\ | | | | | | | | vespa-engine/balder/introduce-concept-of-minimum-capacity - Introduce the concept of minimal capacity for rcu vectors.
| * - Introduce the concept of minimal capacity for rcu vectors.Henning Baldersheim2022-05-243-34/+45
| | | | | | | | | | - This is to prevent shrinking down past what has been configured in proton.documentdb[].allocation.initialnumdocs - shrinking down past the configured value is not supported as that would counter the preallocation done to prevent resizing.
* | avoid undefined behavior in vespalib unit testsHåvard Pettersen2022-05-259-17/+27
| |
* | fix undefined behavior in messagebus unit testsHåvard Pettersen2022-05-251-1/+3
|/ | | | | also avoids hanging/leaving processes after running all unit tests with UBSAN without recovery.
* Reduce inclusion of rcuvector.hppHenning Baldersheim2022-05-232-1/+5
|
* Move calcNewSize to implementation file.Henning Baldersheim2022-05-232-7/+12
|
* - Stick to using GrowStragey everywhere.Henning Baldersheim2022-05-233-60/+20
| | | | - Store the full config in the rcu vector.
* Fold fastlib into vespalib and gc some unused code.Henning Baldersheim2022-05-2152-0/+171462
| | | | Also move some code only used by juniper up into juniper test module.
* Fold staging_vespalib into vespalibHenning Baldersheim2022-05-20144-2/+11030
|
* Use method static instead of global to enable use in other static/global ↵Henning Baldersheim2022-05-201-3/+8
| | | | constructions.
* Move state_server, metrivs and some all executors from staging_vespalib too ↵Henning Baldersheim2022-05-18133-2/+9343
| | | | vespalib.
* Merge pull request #22565 from ↵Henning Baldersheim2022-05-1244-0/+511
|\ | | | | | | | | vespa-engine/toregge/add-cgroup-resource-limits-class Add CGroupResourceLimits class.
| * Extend class comments.Tor Egge2022-05-122-2/+27
| |
| * Add CGroupResourceLimits class.Tor Egge2022-05-1244-0/+486
| |
* | Add some more information when madvise/munmap fails, and allow madvise to ↵Henning Baldersheim2022-05-121-4/+15
|/ | | | fail as it might depending on how huge pages are set up.
* make new bitvector when growingHåvard Pettersen2022-05-111-10/+0
|
* Add madvise(buf, len, MADV_HUGEPAGE) call to signal that you strongly prefer ↵Henning Baldersheim2022-05-111-0/+3
| | | | | | huge pages. This will make a difference if /sys/kernel/mm/transparent_hugepage/enabled has been set to [madvise], and not [always].
* Use data() for more buffer pointer reads rather than subscript operatorTor Brede Vekterli2022-05-061-6/+6
|
* Prefer std::vector over vespalib::ArrayHenning Baldersheim2022-05-062-6/+1
|
* Use raw buffer ptr for (Const)ArrayRef ctors instead of going via subscript ↵Tor Brede Vekterli2022-05-062-24/+28
| | | | | | | | operator Avoids triggering technically undefined behavior when creating an array ref for a nullptr range, since the subscript operators will take a reference to the underlying nullptr.
* Merge pull request #22468 from ↵Henning Baldersheim2022-05-061-0/+3
|\ | | | | | | | | vespa-engine/vekterli/avoid-nullptr-ref-from-empty-file-read Early return from asciistream file read if file is empty
| * Early return from asciistream file read if file is emptyTor Brede Vekterli2022-05-051-0/+3
| | | | | | | | | | | | Avoids a transitive vespalib::string append with nullptr buffer and zero length, which in turn ends up passing nullptr to memmove, which is undefined.
* | Avoid ref of nullptr in nbostream::extend() when existing buffer is emptyTor Brede Vekterli2022-05-062-3/+5
|/ | | | | | Add `Array::data()` utility function to get raw buffer pointer instead of going via `operator[]` which always takes a ref; the latter is not well defined if the underlying buffer is nullptr.