realloc calling free #447
Comments
|
Hey, I'm not sure where you would get a debug package for hiredis on CentOS but it should be really easy to just build from source. Just download the source and build it with a cc [your .c files] /full/path/to/libhiredis.aOr if you can create a small program where you can consistently reproduce the problem, just post it here and I can run it in a CentOS VM. Cheers |
|
Is there a way to load the symbols in gdb to look at an existing coredump? |
|
I've never really tried to do this, but it looks like you can, yes: First build hiredis (I think you'll need to keep the same optimization setting for the build). Then use objcopy --only-keep-symbols libhiredis.so hiredis.symbolsFinally start gdb like so: gdb --core <your.core.file> --symbols=hiredis.symbolsThis worked for me in a CentOS vm, but I just made test program, and didn't try it against libhiredis itself. |
|
I'm not sure what exactly is failing there. I only see see two ways how this can lead to a failure:
|
|
I allocate a new char* and set it to the command that needs to be sent to redis and I pass that in to redisAsyncCommand as both the privdata and format: For example: If I look at the code, in __redisAppendCommand(redisContext *c, const char *cmd, size_t len) |
|
Also run the process through valgrind if you haven't yet. That might give you the hints you need. Also if you post a small program with the problem I'm happy to help you track down the problem. |
|
I ran my original program with valgrind and I see the following with version0.12: ==00:00:31:47.020 4575== 82 bytes in 3 blocks are possibly lost in loss record 1,357 of 2,306 ==00:00:31:47.061 4575== 2,390 bytes in 2 blocks are possibly lost in loss record 2,179 of 2,306 |
|
A different crash that I am seeing has the following backtrace |
|
Hey, The second error looks like maybe you are double freeing the redisAsyncContext. Are you perhaps disconnecting, and then making an explicit call to redisAsyncFree? Hiredis will free your context for you when you call I'm just guessing at this point because there isn't really enough to go on without an example program to replicate the error. |
|
Hi Michael, thanks for the reply. The new crash is not happening while cleanup, it is during normal operation. I am running a standalone program trying to reproduce the crash. I do have a question about using hiredis in multi-threaded program. I have multiple threads that are generating the data that needs to go into redis and I am using a global redisAsyncContext and all the threads are doing redisAsyncCommand using the same context. As long as the context is protected using a global lock, do you see any issues? Should I have only one thread using one redisAsyncContext? Ram |
|
I have a sample program that shows memleak. I have attached it. There are 2 glib contexts, one for doing async writes and other for subscription. |
|
All those "possibly lost" messages are likely false positives. The used string library, sds, does some fancy pointer shuffling to make it look like normal char pointers by pointing right after the actual header of the data, which means it's pointing somewhere in the middle of an allocated block. valgrind can't detect this. As the example does not lead to a crash, I still have no idea what's causing the crash in your application. Regarding a single globally-locked context used from multiple threads: I don't know glib's internals. It might be that it is not all to happy to get the write events from multiple threads, even if those events are mutually exclusive. |
|
(EDIT: This may be a false alarm. I see in the code that hiredis grows a read buffer to 1024 bytes, and so in our small tests of sending a few commands it looked like a leak but maybe isn't. Leaving this comment here in case it helps another person.) We're seeing similar "possibly lost" indications from valgrind, with a process that continues to grow in size (to hundreds of MB, until our process manager restarts it). It is a relatively small program so I think there is possibly a real leak here. It's only possible to see the "possibly lost" blocks if we abort the process uncleanly. Normally our program cleans up on termination, and if we terminate cleanly then there are no lost blocks reported (not even possibly lost). Any chance the I should note this is with hiredis 0.13.3, from the Ubuntu 16.04 package. |
|
FYI: This is the same issue as #493 |
In my program, I am seeing an intermittent crash:
From the realloc documentation:
if size is equal to zero, and ptr is not NULL, then the call is equivalent to free(ptr)
I am sending in a string like "hmset aa bb cc" (a longer one). I will try to write a smaller program that can reproduce it, but I am not sure if I will be able to consistently reporoduce it. I am running with version 12 on CentOS 7 platform. I could not find a dbg package on CentOS platform. If you can give me instructions on creating debug symbols I can load the coredump into GDB and gather more information.
Thanks,
Ramkumar
The text was updated successfully, but these errors were encountered: