Question: Code failing to execute when changes CUDA to reference executor #817
Labels
is:bug
Something looks wrong.
Comments
|
Thanks for your report! Can you try running the same code under |
|
And yes, our documentation and examples deserve a bit more attention, we are working on that :) |
I stripped my project specific paths with gdb logProgram received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007fffe6ea4859 in __GI_abort () at abort.c:79
#2 0x00007fffe6f0f3ee in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fffe7039285 "%s\n")
at ../sysdeps/posix/libc_fatal.c:155
#3 0x00007fffe6f1747c in malloc_printerr (str=str@entry=0x7fffe703b1e0 "munmap_chunk(): invalid pointer")
at malloc.c:5347
#4 0x00007fffe6f176cc in munmap_chunk (p=<optimized out>) at malloc.c:2830
#5 0x00005555559a7618 in gko::Executor::free (this=0x555557cacc30, ptr=0x555557cd53d0)
at %path%/ginkgo/include/ginkgo/core/base/executor.hpp:509
#6 0x00005555559c411e in gko::executor_deleter<double []>::operator() (this=0x555557cd7520, ptr=0x555557cd53d0)
at %path%/ginkgo/include/ginkgo/core/base/executor.hpp:744
#7 0x00005555559c0f04 in std::_Function_handler<void (double*), gko::executor_deleter<double []> >::_M_invoke(std::_Any_data const&, double*&&) (__functor=..., __args#0=@0x7fffffff90e0: 0x555557cd53d0)
at /usr/include/c++/9/bits/std_function.h:300
#8 0x00005555559b0425 in std::function<void (double*)>::operator()(double*) const (this=0x555557ceb5e8,
__args#0=0x555557cd53d0) at /usr/include/c++/9/bits/std_function.h:688
#9 0x00005555559acfb1 in std::unique_ptr<double [], std::function<void (double*)> >::~unique_ptr() (
this=0x555557ceb5e8, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/unique_ptr.h:559
#10 0x00005555559aa5bc in gko::Array<double>::~Array (this=0x555557ceb5e0, __in_chrg=<optimized out>)
at %path%/ginkgo/include/ginkgo/core/base/array.hpp:84
#11 0x00005555559b28e0 in gko::matrix::Dense<double>::~Dense (this=0x555557ceb4f0, __in_chrg=<optimized out>)
at %path%/ginkgo/include/ginkgo/core/matrix/dense.hpp:91
#12 0x00005555559b2bba in gko::matrix::Dense<double>::~Dense (this=0x555557ceb4f0, __in_chrg=<optimized out>)
at %path%/ginkgo/include/ginkgo/core/matrix/dense.hpp:91
#13 0x00007fffe9b893eb in gko::solver::Bicgstab<double>::apply_impl(gko::LinOp const*, gko::LinOp*) const ()
from %path%/ginkgo/lib/libginkgo.so.1.3.0
#14 0x00005555559ae0c4 in gko::EnableLinOp<gko::solver::Bicgstab<double>, gko::LinOp>::apply (this=0x555557cd2c20,
b=0x555557cb2d90, x=0x555557cb2ed0)
at %path%/ginkgo/include/ginkgo/core/base/lin_op.hpp:679
#15 0x00005555559a58e2 in (anonymous namespace)::_DOCTEST_ANON_FUNC_2 ()
at %path%/gko_test.cpp:129
#16 0x00005555555cb271 in doctest::Context::run (this=0x7fffffffa020)
at %path%/doctest/include/doctest/doctest.h:6291
#17 0x00005555555cbc8e in main (argc=2, argv=0x7fffffffa138)
at %path%/doctest/include/doctest/doctest.h:6375
#16 0x00005555555cb271 in doctest::Context::run (this=0x7fffffffa020)
at %path%/doctest/include/doctest/doctest.h:6291
#15 0x00005555559a58e2 in (anonymous namespace)::_DOCTEST_ANON_FUNC_2 ()
at %path%/gko_test.cpp:129Frame 15 is: Valgrind log a bit noised by boost_log warns/errors, but here it is: valgrind log |
|
I have a suspicion what might be going wrong: the |
|
Worth noting, my example finishes correctly during Valgrind session and fails with `munmap_chunk(): invalid pointer
Yes, the reason was in off-by-one error in json-s. After changing indexation error, I obtain expected behaviour. Thank you! |
|
I'm glad you were able to fix it :) Yes, I would assume that is an artifact of how allocation data structures work on Linux - the allocation metadata is stored directly adjacent to the allocated blocks, so if you write out-of-bounds, you destroy these data structures. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have some piece of code that works when executor is CUDA, but fails with
munmap_chunk(): invalid pointerwhen I change executor toReferenceorOmp.{ std::ifstream ifs {f}; auto j = nlohmann::json::parse(ifs); auto dim = 0ul; auto nnz = 0ul; j.at("nnz").get_to(nnz); j.at("dim").get_to(dim); std::vector<int> I(nnz); std::vector<int> J(nnz); std::vector<double> V(nnz); std::vector< double > B(dim); j.at("I").get_to(I); j.at("J").get_to(J); j.at("V").get_to(V); j.at("B").get_to(B); auto host = gko::ReferenceExecutor::create(); // auto exec = gko::ReferenceExecutor::create(); // auto exec = gko::OmpExecutor::create(); auto exec = gko::CudaExecutor::create(0, gko::ReferenceExecutor::create(), true); { using coo = gko::matrix::Coo<double>; using vec = gko::matrix::Dense<double>; auto lA = coo::create(exec, gko::dim<2>{dim, dim}, gko::Array<double>::view(host, nnz, V.data()), gko::Array<int>::view(host, nnz, J.data()), gko::Array<int>::view(host, nnz, I.data())); auto lB = vec::create(exec, gko::dim<2>{dim, 1}, gko::Array< double >::view(host, nnz, B.data()), 1); auto lX = vec::create(exec, gko::dim<2>{dim, 1}, gko::Array< double >::view(host, nnz, B.data()), 1); auto solver = gko::solver::Bicgstab<>::build() .with_preconditioner(gko::preconditioner::Jacobi<>::build().on(exec)) .with_criteria( gko::stop::Iteration::build().with_max_iters(dim).on(exec), gko::stop::ResidualNormReduction<>::build() .with_reduction_factor(1E-10) .on(exec)) .on(exec) ->generate(gko::give(lA)); solver->apply(gko::lend(lB), gko::lend(lX)); } }If I create system matrix with
readfrom matrix marketmtxfile, it will work. So, I think, the problem is in the way I create Coo matrix from existing data.matrix.zip
Thanks!
P.S. It would be nice if you add several documented examples in doxygen/wiki how to create
gko::matricesfrom existing data (includingthrust::device_vector). Because it is quite hard for beginner to figure this out. I addressed your article and unit-tests to compose my little program.The text was updated successfully, but these errors were encountered: