redisCommand not blocking when expected

[Southclaws]

I have a thread (thread owns its own redisContext*, can't use event libs because reasons) and that thread is in a while loop with a redisCommand calling BLPOP.

Now I expected this thread to just wait there for a LPUSH, grab the data, do my thing and go back to waiting. It pops one value then context->errstr complains about a "bad file descriptor".

So I'm guessing somehow the context has lost the fd at some point while blocking but I can't figure out if this is a bug with hiredis or something I'm missing. I've looked at pretty much every example available. Does the context need a keepalive mechanism or something along those lines? I had a quick look at #168 but my connected_clients doesn't appear to be going down so it seems my threaded context is still connected...

Here's the wait loop code https://github.com/Southclaws/samp-redis/blob/master/src/impl.cpp#L432-L451

[badboy]

Did you try with enabling keepalive? It might very well that the server closes the connection.
You should also check the server's log and the server's tcp-keepalive setting.

[Southclaws]

It's the default tcp-keepalive 300 I should add that this problem I'm having happens within seconds of connecting (during unit tests). The redisCommand call blocks at first, pops the first element and then on the next iteration, returns a NULL reply.

[badboy]

That sounds weird indeed. I don't have time this week to look into it, but I put it on my list for the following week

[Southclaws]

Alright, thanks! I'm going to do some investigation too - I'm going to implement an auto-reconnect into my application anyway so with some more logging and pushing it onto my test server I should have some more information on why this is happening. Strangely I can't reproduce it consistently either, which is annoying...

[michael-grunder]

Hi,

I haven't done any real C++ work in years, but this is almost certainly a memory corruption bug due to threading. I wrote a very simple C program to run BLPOP in a worker thread and hiredis is just fine with it:
https://gist.github.com/michael-grunder/edb0a438a6e923c3cf375038be73c7c9

If you place a continue statement above this line here, does the bug go away?:
https://github.com/Southclaws/samp-redis/blob/master/src/impl.cpp#L460

The fact that it works sometimes, and other times fails makes me almost certain that this is a threading issue.

Cheers!
Mike

[badboy]

While I am always the first one pointing out issues in multi-threaded programs, I don't see a problem with the current usage.
The context is created and used in a single function and thus not across threads. processMessages iterates over the returned elements, processMessage copies out the string.
None of the hiredis values is moved across thread boundaries as far as I can see.

It might still be possible for further memory corruption, but a closed socket would probably cause similar problems.

[Southclaws]

Just in case you were still thinking about this issue, I've solved it now. You'll be pleased to know that Hiredis is fine! It was some memory corruption on the host app caused by some dodgy SQLite library (the main reason for my implementing Hiredis was to get the SQL code out of the host and into a Go app to do it concurrently via a message queue anyway).

Thanks for the replies on the topic anyway, apologies for wasting an issue :)

[badboy]

:) Thanks for reporting back.