xerus issueshttps://git.hemio.de/xerus/xerus/-/issues2021-06-08T22:29:46+02:00https://git.hemio.de/xerus/xerus/-/issues/268Fancy callstacks cause memory leaks2021-06-08T22:29:46+02:00Sebastian WolfFancy callstacks cause memory leaksCan be reproduced by with Valgrind or by compiling XerusTest with address sanitizer and running
```
$ ASAN_OPTIONS=alloc_dealloc_mismatch=0 ./XerusTest Tensor:triple_indices
##############################################################...Can be reproduced by with Valgrind or by compiling XerusTest with address sanitizer and running
```
$ ASAN_OPTIONS=alloc_dealloc_mismatch=0 ./XerusTest Tensor:triple_indices
###############################################################################
# unit-testing #
###############################################################################
| Tensor:triple_indices starting: ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
| Tensor:triple_indices: passed! (83.552 ms)
|
|
| total summary 1 of 1 passed
-------------------------------------------------------------------------------
|
| Total time elapsed: 83.639 ms
-------------------------------------------------------------------------------
=================================================================
==47735==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 5415540 byte(s) in 31 object(s) allocated from:
#0 0x7ff33cdd193f in __interceptor_malloc (/lib64/libasan.so.6+0xae93f)
#1 0x1088be5 in bfd_malloc /builddir/build/BUILD/binutils-2.35.1/bfd/libbfd.c:275
Direct leak of 526 byte(s) in 9 object(s) allocated from:
#0 0x7ff33cd7c967 in strdup (/lib64/libasan.so.6+0x59967)
#1 0x10d7b6a in scan_unit_for_symbols dwarf2.c:3530
#2 0x10d7b6a in comp_unit_maybe_decode_line_info dwarf2.c:3946
#3 0x10d7b6a in comp_unit_maybe_decode_line_info dwarf2.c:3924
SUMMARY: AddressSanitizer: 5416066 byte(s) leaked in 40 allocation(s).
```https://git.hemio.de/xerus/xerus/-/issues/259`HTNetwork::move core` does not work for networks of degree 12019-06-17T14:21:52+02:00Philipp Trunschke`HTNetwork::move core` does not work for networks of degree 1Version 4.0RoteKekseRoteKeksehttps://git.hemio.de/xerus/xerus/-/issues/256REQUIREs in `uq_ra_adf_iv` are too restrictive2019-06-13T12:51:20+02:00Manuel MarschallREQUIREs in `uq_ra_adf_iv` are too restrictiveThe function `xerus::uq::uq_ra_adf_iv` in `src/xerus/applications/uqADF.cpp` requires
```
_x.order() <= _measurements.parameterVectors[i].size()
```
This is too restrictive in the UQ setting.
It requires the order of the tensor to be l...The function `xerus::uq::uq_ra_adf_iv` in `src/xerus/applications/uqADF.cpp` requires
```
_x.order() <= _measurements.parameterVectors[i].size()
```
This is too restrictive in the UQ setting.
It requires the order of the tensor to be less than the order of the rank-one measurement.
This does not take into account the fact that the first mode is reserved for the physical domain.
I propose to change the `REQUIRE` condition to
```
_x.order() <= _measurements.parameterVectors[i].size()+1
```Version 4.0Philipp TrunschkePhilipp Trunschkehttps://git.hemio.de/xerus/xerus/-/issues/230Memory Leak in Python Interface2019-06-13T01:30:25+02:00Philipp TrunschkeMemory Leak in Python InterfaceThere is a memory leak in the python interface to `xerus`.
Minimal working example:
```
import xerus as xe
i, = xe.indices(1)
d = xe.Tensor.random([100]*3)
while True:
d_tmp = xe.Tensor()
d_tmp(i&0) << d(i&0)
```There is a memory leak in the python interface to `xerus`.
Minimal working example:
```
import xerus as xe
i, = xe.indices(1)
d = xe.Tensor.random([100]*3)
while True:
d_tmp = xe.Tensor()
d_tmp(i&0) << d(i&0)
```Version 4.0Philipp TrunschkePhilipp Trunschkehttps://git.hemio.de/xerus/xerus/-/issues/253make recompiles xerus even without changes2019-06-12T22:00:18+02:00RoteKeksemake recompiles xerus even without changesVersion 4.0https://git.hemio.de/xerus/xerus/-/issues/251Bug with fenics and mkl2019-04-10T15:29:08+02:00Philipp TrunschkeBug with fenics and mkl```
OS: openSUSE Leap 42.3
MKL Info:
Major version: 2019
Minor version: 0
Update version: 1
Product status: Product
Build: 20180928
Platform: Intel(R) 64 architectur...```
OS: openSUSE Leap 42.3
MKL Info:
Major version: 2019
Minor version: 0
Update version: 1
Product status: Product
Build: 20180928
Platform: Intel(R) 64 architecture
Processor optimization: Intel(R) Advanced Vector Extensions (Intel(R) AVX) enabled processors
================================================================
```
[Working example is attached.](/uploads/657409540901107570a60a2d1a340483/xerus___dolfin___libmkl___buggy.py)Version 4.0https://git.hemio.de/xerus/xerus/-/issues/248uq_ra_adf may diverge with non-uniform weights2019-04-05T12:54:54+02:00Philipp Trunschkeuq_ra_adf may diverge with non-uniform weightsVersion 4.0Philipp TrunschkePhilipp Trunschkehttps://git.hemio.de/xerus/xerus/-/issues/84Building and using the static library with LTO and clang++ fails2019-04-03T18:52:42+02:00Sebastian WolfBuilding and using the static library with LTO and clang++ failsThe gcc wrapper used to create LTO enabled static libraries don't seem to work with clang++.The gcc wrapper used to create LTO enabled static libraries don't seem to work with clang++.https://git.hemio.de/xerus/xerus/-/issues/202failing tests in gitlab pipeline2019-04-03T18:51:52+02:00Fuchsi*failing tests in gitlab pipelinesome of them are very strange. e.g. the following one should never fail
```
| Product_1000x1000 starting: ✗ +00:01:39,286 fullTensor_product.cxx: 409 : warning : memcmp(res.get_dense_data(), C.get_dense_data(), sizeof(value_t)*1000*...some of them are very strange. e.g. the following one should never fail
```
| Product_1000x1000 starting: ✗ +00:01:39,286 fullTensor_product.cxx: 409 : warning : memcmp(res.get_dense_data(), C.get_dense_data(), sizeof(value_t)*1000*1000)==0 failed
✓ ✓
| Product_1000x1000: FAILED! (535.353 ms, seed = baadf00d)
```
(see https://git.hemio.de/xerus/xerus/-/jobs/2291 )https://git.hemio.de/xerus/xerus/-/issues/201calling ALS(A, x, x) results in strange behaviour2019-03-24T04:13:23+01:00Fuchsi*calling ALS(A, x, x) results in strange behaviourshould either print an error or better yet: create a local copy of x as rhs.should either print an error or better yet: create a local copy of x as rhs.Version 4.0Sebastian WolfSebastian Wolfhttps://git.hemio.de/xerus/xerus/-/issues/240invalid read of size 8 in TRASD unittest2019-03-23T15:19:36+01:00Fuchsi*invalid read of size 8 in TRASD unittest```
| Fixed_Rank_Recovery starting: ==9814== Invalid read of size 8
==9814== at 0x4EC23A: tt_dofs(std::vector<unsigned long, std::allocator<unsigned long> > const&, std::vector<unsigned long, std::allocator<unsigned long> > const&) (c...```
| Fixed_Rank_Recovery starting: ==9814== Invalid read of size 8
==9814== at 0x4EC23A: tt_dofs(std::vector<unsigned long, std::allocator<unsigned long> > const&, std::vector<unsigned long, std::allocator<unsigned long> > const&) (common.hxx:38)
==9814== by 0x4F14AD: random_low_tt_ranks (common.hxx:83)
==9814== by 0x4F14AD: {lambda()#1}::operator()() const [clone .isra.151] (asd.cxx:39)
==9814== by 0x68571F: operator() (std_function.h:687)
==9814== by 0x68571F: xerus::misc::internal::test(std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::function<void ()> > const&, unsigned long) [clone .constprop.118] (test.cpp:112)
==9814== by 0x481A4B: main (test.cpp:231)
==9814== Address 0xcabaae8 is 0 bytes after a block of size 8 alloc'd
==9814== at 0x4838E86: operator new(unsigned long) (vg_replace_malloc.c:344)
==9814== by 0x4F13B6: allocate (new_allocator.h:111)
==9814== by 0x4F13B6: allocate (alloc_traits.h:436)
==9814== by 0x4F13B6: _M_allocate (stl_vector.h:296)
==9814== by 0x4F13B6: _M_create_storage (stl_vector.h:311)
==9814== by 0x4F13B6: _Vector_base (stl_vector.h:260)
==9814== by 0x4F13B6: vector (stl_vector.h:460)
==9814== by 0x4F13B6: random_low_tt_ranks (common.hxx:80)
==9814== by 0x4F13B6: {lambda()#1}::operator()() const [clone .isra.151] (asd.cxx:39)
==9814== by 0x68571F: operator() (std_function.h:687)
==9814== by 0x68571F: xerus::misc::internal::test(std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::function<void ()> > const&, unsigned long) [clone .constprop.118] (test.cpp:112)
==9814== by 0x481A4B: main (test.cpp:231)
```Version 4.0Sebastian WolfSebastian Wolfhttps://git.hemio.de/xerus/xerus/-/issues/225HT::round uses wrong index to access desired rank2019-03-20T11:29:56+01:00Fuchsi*HT::round uses wrong index to access desired rankfrom valgrind:
```
==19016== Invalid read of size 8
==19016== at 0x698428: xerus::HTNetwork<true>::round(std::vector<unsigned long, std::allocator<unsigned long> > const&, double) (htNetwork.cpp:727)
==19016== by 0x698946: xerus::H...from valgrind:
```
==19016== Invalid read of size 8
==19016== at 0x698428: xerus::HTNetwork<true>::round(std::vector<unsigned long, std::allocator<unsigned long> > const&, double) (htNetwork.cpp:727)
==19016== by 0x698946: xerus::HTNetwork<true>::round(unsigned long) (htNetwork.cpp:740)
==19016== by 0x6989C4: xerus::HTNetwork<true>::round(int) (htNetwork.cpp:747)
==19016== by 0x4F038C: {lambda()#11}::operator()() const [clone .isra.201] (htArithmetic.cxx:393)
==19016== by 0x67E80F: operator() (std_function.h:687)
==19016== by 0x67E80F: xerus::misc::internal::test(std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::function<void ()> > const&, unsigned long) [clone .constprop.118] (test.cpp:112)
==19016== by 0x47D70B: main (test.cpp:231)
==19016== Address 0xaafe060 is 0 bytes after a block of size 16 alloc'd
==19016== at 0x4838E86: operator new(unsigned long) (vg_replace_malloc.c:344)
==19016== by 0x6988AF: allocate (new_allocator.h:111)
==19016== by 0x6988AF: allocate (alloc_traits.h:436)
==19016== by 0x6988AF: _M_allocate (stl_vector.h:296)
==19016== by 0x6988AF: _M_create_storage (stl_vector.h:311)
==19016== by 0x6988AF: _Vector_base (stl_vector.h:260)
==19016== by 0x6988AF: vector (stl_vector.h:429)
==19016== by 0x6988AF: xerus::HTNetwork<true>::round(unsigned long) (htNetwork.cpp:740)
==19016== by 0x6989C4: xerus::HTNetwork<true>::round(int) (htNetwork.cpp:747)
==19016== by 0x4F038C: {lambda()#11}::operator()() const [clone .isra.201] (htArithmetic.cxx:393)
==19016== by 0x67E80F: operator() (std_function.h:687)
==19016== by 0x67E80F: xerus::misc::internal::test(std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::function<void ()> > const&, unsigned long) [clone .constprop.118] (test.cpp:112)
==19016== by 0x47D70B: main (test.cpp:231)
==19016==
==19016== Invalid read of size 8
==19016== at 0x698428: xerus::HTNetwork<true>::round(std::vector<unsigned long, std::allocator<unsigned long> > const&, double) (htNetwork.cpp:727)
==19016== by 0x698946: xerus::HTNetwork<true>::round(unsigned long) (htNetwork.cpp:740)
==19016== by 0x6989C4: xerus::HTNetwork<true>::round(int) (htNetwork.cpp:747)
==19016== by 0x4F053E: {lambda()#11}::operator()() const [clone .isra.201] (htArithmetic.cxx:395)
==19016== by 0x67E80F: operator() (std_function.h:687)
==19016== by 0x67E80F: xerus::misc::internal::test(std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::function<void ()> > const&, unsigned long) [clone .constprop.118] (test.cpp:112)
==19016== by 0x47D70B: main (test.cpp:231)
==19016== Address 0xa4d6770 is 0 bytes after a block of size 16 alloc'd
==19016== at 0x4838E86: operator new(unsigned long) (vg_replace_malloc.c:344)
==19016== by 0x6988AF: allocate (new_allocator.h:111)
==19016== by 0x6988AF: allocate (alloc_traits.h:436)
==19016== by 0x6988AF: _M_allocate (stl_vector.h:296)
==19016== by 0x6988AF: _M_create_storage (stl_vector.h:311)
==19016== by 0x6988AF: _Vector_base (stl_vector.h:260)
==19016== by 0x6988AF: vector (stl_vector.h:429)
==19016== by 0x6988AF: xerus::HTNetwork<true>::round(unsigned long) (htNetwork.cpp:740)
==19016== by 0x6989C4: xerus::HTNetwork<true>::round(int) (htNetwork.cpp:747)
==19016== by 0x4F053E: {lambda()#11}::operator()() const [clone .isra.201] (htArithmetic.cxx:395)
==19016== by 0x67E80F: operator() (std_function.h:687)
==19016== by 0x67E80F: xerus::misc::internal::test(std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::function<void ()> > const&, unsigned long) [clone .constprop.118] (test.cpp:112)
==19016== by 0x47D70B: main (test.cpp:231)
```
(HT::round should also be changed to divide provided _eps by the square-root of rounding operations performed to have error guarantees)Version 4.0RoteKekseRoteKeksehttps://git.hemio.de/xerus/xerus/-/issues/211Creation of big TT Train crashes2018-10-09T09:16:28+02:00RoteKekseCreation of big TT Train crashesHey ho,
the following code crushes.
```cpp
#include <xerus.h>
using namespace xerus;
int main() {
auto bigTT = TTTensor::random(std::vector<size_t>(784, 4), std::vector<size_t>(783,2));
}
```
It crushes in the QR decomposition i...Hey ho,
the following code crushes.
```cpp
#include <xerus.h>
using namespace xerus;
int main() {
auto bigTT = TTTensor::random(std::vector<size_t>(784, 4), std::vector<size_t>(783,2));
}
```
It crushes in the QR decomposition in ```blasLapackWrapper.cpp line 361``` (on development branch). It is able to perform 700 QR decomposition before it crushes. And indeed for smaller size it compiles:
```cpp
#include <xerus.h>
using namespace xerus;
int main() {
auto bigTT = TTTensor::random(std::vector<size_t>(700, 4), std::vector<size_t>(699,2));
}
```
Any ideas? The matrizes for the qQRare small, memory and cpu is plenty left. Maybe it is only on my machine?
Best regards MichaSebastian WolfSebastian Wolfhttps://git.hemio.de/xerus/xerus/-/issues/210offset_add is not behaving as expected2018-08-14T16:01:17+02:00RoteKekseoffset_add is not behaving as expected```cpp
#include <xerus.h>
using namespace xerus;
int main() {
auto test1 = xerus::Tensor::dirac({1,1,1},0);
auto test2 = xerus::Tensor::dirac({2,2,1},0);
test2[3] = 4;
test2[1] = 2;
test2[2] = 3;
XERUS_LOG(info, "test1 = \n" <<...```cpp
#include <xerus.h>
using namespace xerus;
int main() {
auto test1 = xerus::Tensor::dirac({1,1,1},0);
auto test2 = xerus::Tensor::dirac({2,2,1},0);
test2[3] = 4;
test2[1] = 2;
test2[2] = 3;
XERUS_LOG(info, "test1 = \n" << test1 );
XERUS_LOG(info, "test2 = \n" << test2 );
std::unique_ptr<Tensor> comb(new Tensor({3,3,2}));
comb->offset_add(test1, std::vector<size_t>({0,0,0}));
comb->offset_add(test2, std::vector<size_t>({1,1,1}));
XERUS_LOG(info, "comb = \n" << *comb );
}
```
The above code returns:
```
+00:00:00,000 testAddition.cpp : 10 : info : test1 =
1.000000
+00:00:00,000 testAddition.cpp : 11 : info : test2 =
1.000000 0.000000
0.000000 1.000000
+00:00:00,002 testAddition.cpp : 28 : info : comb =
1.000000 / 0.000000 0.000000 / 0.000000 0.000000 / 0.000000
0.000000 / 0.000000 0.000000 / 1.000000 0.000000 / 2.000000
0.000000 / 3.000000 0.000000 / 4.000000 0.000000 / 0.000000
```
I expected
```
+00:00:00,000 testAddition.cpp : 10 : info : test1 =
1.000000
+00:00:00,000 testAddition.cpp : 11 : info : test2 =
1.000000 0.000000
0.000000 1.000000
+00:00:00,002 testAddition.cpp : 28 : info : comb =
1.000000 / 0.000000 0.000000 / 0.000000 0.000000 / 0.000000
0.000000 / 0.000000 0.000000 / 1.000000 0.000000 / 2.000000
0.000000 / 0.000000 0.000000 / 3.000000 0.000000 / 4.000000
```
Is this a bug?
Cheers MichaSebastian WolfSebastian Wolfhttps://git.hemio.de/xerus/xerus/-/issues/205compilation errors on MacOS2018-05-12T09:56:25+02:00Fuchsi*compilation errors on MacOSfrom a mail sent to us:
````
I encounter a problem when trying to install Xerus on my macbook with clang++. When I typed ‘make install -j4’, I got the error message as in the attached screenshot.
I have installed all the libraries as s...from a mail sent to us:
````
I encounter a problem when trying to install Xerus on my macbook with clang++. When I typed ‘make install -j4’, I got the error message as in the attached screenshot.
I have installed all the libraries as stated in Xerus’ documentation. Is there something else that I missed? I hope you would help me with resolving this issue. Also attached is the config file that I used.
In addition, some info about my macbook:
- macOS High Sierra
- Apple LLVM version 9.0.0 (clang-900.0.38)
Thank you very much for your time!
````
In the attached screenshot there is an error in simplenumerics.cpp line 64: an ambiguous call to misc::pow.https://git.hemio.de/xerus/xerus/-/issues/23Code coverage detection not working properly2018-04-23T03:03:39+02:00Sebastian WolfCode coverage detection not working properlyCode coverage says:
file index.hpp : 2 of 4 tests performed
However there are only two REQUIREs in index.hpp, which are most certainly called. Probably the problem is that the corresponding functions also appear inlined?Code coverage says:
file index.hpp : 2 of 4 tests performed
However there are only two REQUIREs in index.hpp, which are most certainly called. Probably the problem is that the corresponding functions also appear inlined?Version 1.2Fuchsi*Fuchsi*https://git.hemio.de/xerus/xerus/-/issues/33problems with the MISC_NAMESPACE macro2018-04-23T03:03:39+02:00Fuchsi*problems with the MISC_NAMESPACE macro1. not defining it before including any individual misc/*.h file will result in a warning about undefined macros / variables
2. setting it via `#define MISC_NAMESPACE` results in `#define MISC` which interestingly results in the followi...1. not defining it before including any individual misc/*.h file will result in a warning about undefined macros / variables
2. setting it via `#define MISC_NAMESPACE` results in `#define MISC` which interestingly results in the following error message:
```
bla.cpp:(.text+0xa58): undefined reference to `(anonymous namespace)::get_call_stack()'
```
This might be the only way to reference an anonymous namespace...???version 1.1https://git.hemio.de/xerus/xerus/-/issues/44REQUIRE_TEST macro file name identification (in cases of ../ in the path)2018-04-23T03:03:39+02:00Fuchsi*REQUIRE_TEST macro file name identification (in cases of ../ in the path)Version 1.0Fuchsi*Fuchsi*https://git.hemio.de/xerus/xerus/-/issues/54Compiling xerus without runtime checks causes the test cases to end with and ...2018-04-23T03:03:39+02:00Sebastian WolfCompiling xerus without runtime checks causes the test cases to end with and segmentation fault.Version 1.0https://git.hemio.de/xerus/xerus/-/issues/61Makefile does not cover changes in .hxx files correctly2018-04-23T03:03:38+02:00Fuchsi*Makefile does not cover changes in .hxx files correctlychanges in .hxx files cause recompilation of the binary - but apparently not the text object fileschanges in .hxx files cause recompilation of the binary - but apparently not the text object filesVersion 1.0Sebastian WolfSebastian Wolf