Giters

DMTF / libredfish

libRedfish is a C client library that allows for Creation of Entities (POST), Read of Entities (GET), Update of Entities (PATCH), Deletion of Entities (DELETE), running Actions (POST), receiving events, and providing some basic query abilities.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unable to terminate program correctly

martinkennelly opened this issue · comments

commented

Hey all,
My program is asynchronously using your software to make queries to a redfish API. I am having trouble safely closely my program. How would you recommend safely terminating the threads created by libredfish?

Thank you for any input.

commented

If you cleanup returned redfishPayload objects and run either serviceDecRef or serviceDecRefAndWait when done with the redfishService entity the thread will self terminate (the service keeps a reference counter for all the times it is used, when that counter reaches 0 it will kill the thread and clean itself up).

commented

I tried serviceDefRefAndWait in my cleanup function, but valgrind is telling me there is possible leak. I hope to show you the code in its entirety in a weeks time if you would have a look.
The only way I can prevent the possible leak is if I wait for a period of time, usually up to 10-20 seconds & then exit.

==18831== HEAP SUMMARY:
==18831== in use at exit: 279,504 bytes in 459 blocks
==18831== total heap usage: 1,581,773 allocs, 1,581,314 frees, 158,677,450 bytes allocated
==18831==
==18831== 320 bytes in 1 blocks are possibly lost in loss record 82 of 110
==18831== at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18831== by 0x40134A6: allocate_dtv (dl-tls.c:286)
==18831== by 0x40134A6: _dl_allocate_tls (dl-tls.c:530)
==18831== by 0x4E44227: allocate_stack (allocatestack.c:627)
==18831== by 0x4E44227: pthread_create@@GLIBC_2.2.5 (pthread_create.c:644)
==18831== by 0x60629E9: startAsyncThread (asyncRaw.c:419)
==18831== by 0x60629A7: initAsyncThread (asyncRaw.c:409)
==18831== by 0x6061D13: startRawAsyncRequest (asyncRaw.c:95)
==18831== by 0x6067582: getUriFromServiceAsync (service.c:428)
==18831== by 0x6067A19: getRedfishServiceRootAsync (service.c:563)
==18831== by 0x6067C53: getPayloadByPathAsync (service.c:638)
==18831== by 0x5E5A9DF: XXXXXXXXXX(XXXXXX.c:869)
==18831== by 0x4E436DA: start_thread (pthread_create.c:463)
==18831== by 0x538088E: clone (clone.S:95)
==18831==
==18831== LEAK SUMMARY:
==18831== definitely lost: 0 bytes in 0 blocks
==18831== indirectly lost: 0 bytes in 0 blocks
==18831== possibly lost: 320 bytes in 1 blocks
==18831== still reachable: 279,184 bytes in 458 blocks
==18831== suppressed: 0 bytes in 0 blocks
==18831== Reachable blocks (those to which a pointer was found) are not shown.
==18831== To see them, rerun with: --leak-check=full --show-leak-kinds=all

commented

Here is the commit:
collectd/collectd@05302d8
Thank you for any input.

commented

Does this only occur under valgrind? I've got a workaround in the code for valgrind if you look at line 133 in src/asyncRaw.c you'll see it. For some reason I always see pthread_join() fail with EDEADLK under valgrind so it doesn't work right. I put a sleep in there that usually gives everything enough time to clean up properly. But in this case apparently isn't. So if this is just a valgrind thing then I think it's a false positive. If you are seeing the thread hang during normal runtime then please let me know.

commented

I can only see this occurring under valgrind. The 10 second delay valgrind fix does not prevent the issue on my end. I do not see the thread hanging during normal run time with no valgrind. Happy to close this for now. Thank you for your input.