On Thu, Jul 6, 2017 at 12:21 PM, Przemysław Sobala <przemyslaw.sob...@gmail.com> wrote: > Hello > [In the preface I want to say that it can be valgrind's false positive]. > I'm building a C++ class that uses libuv (1.13.0) and libcurl (7.54.1) for > non-blocking file downloading. UV loop is being initialized in object's > constructor, deinitialized in destructor and it's being kept a class member. > When it's a pointer type class member (uv_loop_t *), initialized via malloc: > loop = (uv_loop_t *) malloc(sizeof(uv_loop_t)); > if (loop == NULL) { > throw std::bad_alloc(); > } > uv_loop_init(loop); > and deinitialized via uv_loop_close(loop) there's no memory leak. > > But when it's a struct type class member (uv_loop_t) it's initialized > automatically while object construction, then in constructor I call > uv_loop_init(&loop) and uv_loop_close(&loop) in destructor, valgrind reports > a memory leak: > ==2337== 256 bytes in 1 blocks are definitely lost in loss record 790 of 840 > ==2337== at 0x4C2FC47: realloc (vg_replace_malloc.c:785) > ==2337== by 0x816560: maybe_resize (core.c:808) > ==2337== by 0x816560: uv__io_start (core.c:847) > ==2337== by 0x8181EB: uv_poll_start (poll.c:120) > ==2337== by 0x417ECE: > imageresizer::engine::FileDownloader::handle_socket(void*, int, int, void*) > (FileDownloader.cpp:298) > ==2337== by 0x417E28: > imageresizer::engine::FileDownloader::handle_socket_cb(void*, int, int, > void*, void*) (FileDownloader.cpp:277) > ==2337== by 0x7D1798: singlesocket (in > /opt/WP/imageresizer-worker/dist/Debug/GNU-Linux/imageresizer-worker) > ==2337== by 0x7D4AD9: multi_socket (in > /opt/WP/imageresizer-worker/dist/Debug/GNU-Linux/imageresizer-worker) > ==2337== by 0x7D4C86: curl_multi_socket_action (in > /opt/WP/imageresizer-worker/dist/Debug/GNU-Linux/imageresizer-worker) > ==2337== by 0x417D59: > imageresizer::engine::FileDownloader::on_timeout(uv_timer_s*) > (FileDownloader.cpp:248) > ==2337== by 0x417D25: > imageresizer::engine::FileDownloader::on_timeout_cb(uv_timer_s*) > (FileDownloader.cpp:242) > ==2337== by 0x81D4B4: uv__run_timers (timer.c:165) > ==2337== by 0x8159AB: uv_run (core.c:353) > > Can you help me with getting rid of that memory leak? > > -- > regards > Przemysław Sobala
Check the return value of uv_loop_close(). My guess it's UV_EBUSY, indicating the event loop can't be closed yet because there are open handles or requests. -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to libuv+unsubscr...@googlegroups.com. To post to this group, send email to libuv@googlegroups.com. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.