I am getting the following exceptions while accessing Redis. Can anyone help me to resolve this?
ERR Protocol error: invalid multibulk length; nested exception is redis.clients.jedis.exceptions.JedisConnectionException: ERR Protocol error: invalid multibulk length
the length of args of the API command MSET can't be bigger than 1024 * 1024, so the length of the array KeyValuePair<RedisKey, RedisValue>[] values cant be bigger than 524288, so I limit it to 524287, then it works.
LINK: https://github.com/StackExchange/StackExchange.Redis/issues/201
Related
If we have a reducedTxBytes as String form. How can we sign it via appkit? (I found that we can use
ctx.parseReducedTransaction
, however i'm getting this
requirement failed: Not enough bytes in the buffer
I'm doing:
{
(Address.create(tx._1),
client.getContext.parseReducedTransaction(tx._2.getBytes))
}
Where tx = (String, String) representing (WalletAddress, ReducedTxBytes)
For a sample tx like this:
3QIB_1JG5qTPntBexsiCikbQ_VE1uhtoBG5TyWttASKOkosAAAADg2FcoBCWIDoj4kbTFy2D_mMHmGvdRZRldiDJ0oWk0Dd85dhG5-wa8gfLDadilJjVz2_6zXtNKNCNzZXYicp3OvZjSvkKhjvNecY0PlaLGyzdPOvyMDYaEu87_luDcOdgA4CJegAIzQPULJZ0Jd77AX3zyVjLnTHR3SrYxe50EA_yE0yvp85wP62ZNAABBRTAhD0QBQQABAAONhACBKALCM0Ceb5mfvncu6xVoGKVzocLBwKb_NstzijZWfKBWxb4F5jqAtGSo5qMx6cBcwBzARABAgQC0ZaDAwGTo4zHsqVzAAABk8KypXMBAHRzAnMDgwEIze6sk7GlcwStmTQAAMC71dUEAAjNA9QslnQl3vsBffPJWMudMdHdKtjF7nQQD_ITTK-nznA_rZk0AwABAb_ckOgBAgEAzQPULJZ0Jd77AX3zyVjLnTHR3SrYxe50EA_yE0yvp85wP51P8Gw=
While trying to debug I found that the reason why it failed is due to decoding. As its a string that was encoded from an array bytes, it has to be decoded the same way.
Here is the way it was encoded:
reducedTx = Base64.getUrlEncoder.encodeToString(reducedTx.toBytes)
Where reducedTx is a ReducedTransaction
Answer below
The problem happens due to a failure of decoding it to the right bytes. Because it is being encoded via Base64.GetUrlEncoder, it has to be decoded the same way. Therefore this line down here works:
val result = (Address.create(tx._1),
client.getContext.parseReducedTransaction(
Base64.getUrlDecoder.decode(tx._2)))
Note that we're using Base64.getUrlDecoded rather than getBytes.
I got many 'Invalid read of size N' while running my program written in C++ with Valgrind-3.11.0 on Ubuntu 64-bit.
The error messages are like following with different N where N is varying among 1, 4, 8.
Invalid read of size N.
Address 0xblahblah is 88 bytes inside a block of size 176 alloc'd
The block of size 176 is a C++ class object allocated with new operator and the size of N is small enough so that it's not out-of-bounds case.
Then why the Valgrind doesn't tell me the reason like 'not stacked', 'not malloced', 'recently freed'?
Does anyone know why Valgrind decided this as an invalid read when there are no messages like 'not stacked', 'not malloced', 'recently freed'?
N corresponds to the size of the underlying primitive data type. Roughly speaking, 1 would be a char or a bool, 4 would be and int or float and 8 would be a long int, double or pointer.
XX bytes inside a block of size YY alloc'd
First of all this means that the memory is dynamic (~on the heap) rather than automatic (~on the stack). Secondly, you know the size of the object(s) allocated. If you know the size per object (you can use sizeof to get that), then you can work out how many objects were allocated.
Are there any other serious errors before this?
Do you use any Valgrind client requests in your code?
Simple enough, I am using Redis INCR to ensure atomic increments of a counter, the counter has an indeterminate start value less than Int64.MaxValue.
Does Redis reset the value when it reaches Int64.MaxValue or throw an error?
I read the documentation but it does not say what happens, and I really do want to maintain the atomic nature at rollover
It will throw an error. I did a small experiment for your use case
127.0.0.1:6379> set value 9223372036854775807 (2 power 63 -1)
OK
127.0.0.1:6379> incr value
(error) ERR increment or decrement would overflow
127.0.0.1:6379>
Redis can hold upto 2 power 63. and throws error if it exceeds that limit. It might be either "out of range" error or "overflow" error
Upon error you can catch that exception and reset the value in your application logic.
I am using MsgSendv and server sends MSgReply like this:
char desc_buf_out[MAX_CHARS_IN_A_LINE];
MsgReply(rcvid, EOK, desc_buf_out, sizeof(desc_buf_out));
My client is looking like this:
iov_t *iovrcv=calloc(1,sizeof(iov_t));
char rcv[1024]={0}
if (MsgSendv(server_coid, iovin_render, 3 , iovrcv, 1 ) == -1)
{
printf("error sending message to server\n");
fprintf( stderr,
"%s: %s\n",
__func__,
strerror( errno ) );
return EXIT_FAILURE;
}
SETIOV (iovrcv + 0, rcv, sizeof(rcv));
printf("iovrcv=%s\n", rcv);
But I get nothing in my rcv buffer?
Can you tell me why and what is the correct way of doing it so I receive my data correctly? I expect to receive string.
You are using the iovrcv uninitialized (well, ok, it's initialized with zeros via calloc, but it's not initialized to point to anything).
An iov_t is a pair of values, a pointer and a length.
It's given to the MsgSendv() function to tell it where the data should go. By leaving it uninitialized, you're telling MsgSendv() that the pointer is zero and the length is zero -- not a whole lot of data! :-)
Move your SETIOV to above the MsgSendv() function.
Also, be sure to initialize the iovin_render (which you show as having three parts, that is, three pairs of ptr/length values).
I am porting a game engine that works perfectly on different platforms (Windows, iOS, Playbook, BB10, Android) to NaCl
2d renders correctly but some 3d Objects don't show or are rendered really strange and i get the following con
[.PPAPIContext]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : BackTexture::AllocateStorage: <- error from previous GL command (index):1
[.PPAPIContext]GL ERROR :GL_INVALID_OPERATION : glVertexAttribPointer: stride not valid for type (index):1
[.PPAPIContext]GL ERROR :GL_INVALID_OPERATION : glVertexAttribPointer: offset not valid for type (index):1
[.PPAPIContext]GL ERROR :GL_INVALID_OPERATION : glDrawElements: attempt to access out of range vertices in attribute 0 (index):1
[.PPAPIContext]GL ERROR :GL_INVALID_OPERATION : glVertexAttribPointer: stride not valid for type (index):1
[.PPAPIContext]GL ERROR :GL_INVALID_OPERATION : glVertexAttribPointer: offset not valid for type (index):1
[.PPAPIContext]GL ERROR :GL_INVALID_OPERATION : glVertexAttribPointer: stride not valid for type (index):1
[.PPAPIContext]GL ERROR :GL_INVALID_OPERATION : glVertexAttribPointer: offset not valid for type (index):1
[.PPAPIContext]GL ERROR :GL_INVALID_OPERATION : glVertexAttribPointer: stride not valid for type
And it repeats indefinitely.
Again, the same render code is used for different platforms and it works just fine. Is there a special consideration to be taken into account when porting to NaCl? Any ideas about what i should focus on to try find the issue?
As far as i can understand, there's a problem with the shader 0 (the vertex shader) and indeed the vertices of some objects are all over the place.
Thanks! :)
For security reasons, Chrome validates many GL operations that other drivers may not. It's a bit of work, but you might try searching the Chromium codebase using http://cs.chromium.org to find the error messages.
Here's what I found:
BackTexture::AllocateStorage: <- error from previous GL command
This one is tricky to follow. As it says, some previous GL command failed before BackTexture::AllocateStorage was called. I looked through the rest of the file, and it's not clear to me what command is failing here, but from the error value it is framebuffer related.
glVertexAttribPointer: stride not valid for type and glVertexAttribPointer: offset not valid for type
These are pretty clear -- the stride and offset values are not divisible by the component size. It would be useful to see your calls to glVertexAttribPointer.
glDrawElements: attempt to access out of range vertices in attribute 0
VertexAttrib::CanAccess is failing, which checks whether the attrib is enabled, not deleted, and if the vertex index that you're trying to access is valid. As the error says, you are likely referencing a vertex outside of the valid range.
To debug this, I'd narrow down the calls to glDrawElements and glVertexAttribPointer and try to find which one is failing, then I'd add some printf calls to see what values are being passed.
Good luck!