I found a pretty annoying and serious problem in iTextSharp's zlib implementation. Very hard to reproduce because it depends on the actual data going into the PDF but in some circumstances, the following exception occurs:
System.IndexOutOfRangeException: Index was outside the bounds of the array.
at System.util.zlib.Tree.d_code(Int32 dist)
at System.util.zlib.Deflate.compress_block(Int16[] ltree, Int16[] dtree)
In System.util.zlib.Tree.cs, there is obviously no range check, only an assumption of things never going wrong. Adding the following (byte) cast seems to be a solution:
internal static int d_code(int dist){
return ((dist) < 256 ? _dist_code[dist] : _dist_code[256+(byte)((dist)>>7)]);
}
Related
Diclaimer
In the first place this is a recap on recent development activities.
I am writing this down for lost souls - as I could not find any post containing this error except:
RSA encryption/decryption implementing in Swift from Android Java code
The Problem
During decryption of a cyphertext with a given private key, iOS throws this error:
Optional(Swift.Unmanaged<__C.CFErrorRef>(_value: Error Domain=NSOSStatusErrorDomain Code=-50 "RSAdecrypt wrong input (err -27)" UserInfo={numberOfErrorsDeep=0, NSDescription=RSAdecrypt wrong input (err -27)}))
For the sake of readability and search engine optimization the same error is given in a style which is more easy to be read:
Optional(
Swift.Unmanaged<__C.CFErrorRef>(
_value: Error
Domain=NSOSStatusErrorDomain
Code=-50 "RSAdecrypt wrong input (err -27)"
UserInfo={
numberOfErrorsDeep=0,
NSDescription=RSAdecrypt wrong input (err -27)
}
)
)
The Question
What are likely reasons for receiving this error?
However
My knowledge so far is given in one of the answers below ;-)
As mentioned by #not2savvy, I better answer as far as known here instead of 'within the question part' ... .. .
The good news
You probaply solved several problems already, such as:
Base64 decoding error
-> In case your ciphertext/private key had to be transformed back to binary
Algorithm error
-> Mismatch of PrivateKey in regards of the needed algorithm (e.g.: RSA)
Size error
-> Mismatch of Ciphertext- and Keysize
... .. . you are not far from the solution ;-)
The bad news
You probaply have the wrong private key to decrypt the given cyphertext.
Something else is wrong with your key, which I do know nothing about.
I have the following line of code that sets a String.Index to a certain value using the index offset function in the swift standard library
index = str.(index, offsetBy: -length)
it functions for short str, but as soon as it, or the length value get above some arbitrary (and changing!) threshold, I get a variety of crashes. Most consistently, and from a break point is
Swift/UnsafeBufferPointer.swift:913: Fatal error
I have done a little research plus my own testing and have not found anything conclusive so far. The most helpful test I ran was trying to offset this index in smaller increments with a loop such as with the following code
for _ in 0...Int(totalLength) {
let newIndex = str(index, offsetBy: -1)
index = newIndex
}
however, the let newIndex line still crashed even with the offset value at 1, so I imagine that it is the cause of the long string. However, with this test I was more consistently getting BAD ACCESS errors instead of the UnsafeBufferPointer.
I have not found anyone online who has run into a similar problem, and am wondering if this is a documented issue with the function, or if there is some other thing at fault. Any help is appreciated, thank you !
I have a register map which has 16 bit wide registers. I have a field with is greater than 16 bits wide, so it must span two addresses. How do I define the backdoor access to this field?
This is what I tried for my field test_pattern[23:0]:
register_a.add_hdl_path_slice("path.to.regmap.test_pattern[15:0]", 0, 16);
register_b.add_hdl_path_slice("path.to.regmap.test_pattern[23:16]", 0, 8);
This fails with this error:
ERROR: VPI TYPERR
vpi_handle_by_name() cannot get a handle to a part select.
It is not clear if this is a constraint of my tool, or of how the UVM code uses the VPI. After poking around inside the UVM code I see the code that should handle part-selects, but it is inside #ifdef QUESTA directives so I think this is a tool constraint.
Is there a good work around for this?
According to the UVM Class Reference:
function void add_hdl_path_slice(string name,
int offset,
int size,
bit first = 0,
string kind = "RTL")
I'm guessing the solution should use the offset to select the starting index.
register_a.add_hdl_path_slice("path.to.regmap.test_pattern", 0, 16);
register_b.add_hdl_path_slice("path.to.regmap.test_pattern", 16, 8);
Possible alternative, bit select in a for-loop:
for (int i=0; i<16; i++) begin
string tmp_path_s;
tmp_path_s = $sformatf("path.to.regmap.test_pattern[%0d]", i);
register_a.add_hdl_path_slice(tmp_path_s, i, 1);
end
for (int i=0; i<8; i++) begin
string tmp_path_s;
tmp_path_s = $sformatf("path.to.regmap.test_pattern[%0d]", i+16);
register_a.add_hdl_path_slice(tmp_path_s, i, 1);
end
It's a great pity that whoever contributed this code (presumably Mentor?) felt it necessary to add a useful feature to a Universal library wrapped in ifdefs. In fact it's even worse on the UVM_1_2 branch where the whole DPI/PLI interface file is split into simulator specific implementations!
Looking at distrib/src/dpi/uvm_hdl.c on master branch of git://git.code.sf.net/p/uvm/code it looks like the only QUESTA specific code is this function:
static int uvm_hdl_set_vlog_partsel(char *path, p_vpi_vecval value, PLI_INT32 flag);
static int uvm_hdl_get_vlog_partsel(char *path, p_vpi_vecval value, PLI_INT32 flag);
Which uses the following DPI defined values:
svLogic logic_bit;
svGetBitselLogic(&bit_value,0);
svLogicVecVal bit_value;
svGetPartselLogic(&bit_value,value,i,1);
svPutPartselLogic(value,bit_value,i,1);
In theory if both your simulator and the Mentor code are compliant to the standard you could remove the ifdefs and it should still work.
You could also do this by detecting the part select in the path and use vpi_handle_by_index to read the individual bits, which should also be supported in any simulator.
NB my original answer was wrong about the code being Mentor specific - thanks to #dave_59 for setting me straight and apologies to Mentor.
Is there some reason why you aren't splitting this into 2 registers. Since your register size is 16 bits it doesn't make sense to declare a register that is larger than this.
The way I've seen large fields like this defined is to declare 2 registers with a separate field in each. For example, if you needed a 32-bit pointer you'd have:
addr_high with a 16 bit field
addr_low with a 16 bit field
For convenience, you could add a task that would access both in sequence.
I, recently I use fopen_s:
errno_t err = fopen_s( &fp, filename, mode );
and I get errno_t as zero, which means no error occured, but I didn't get a valid fp, actually, it is unchanged.
What possible is this situation?
Apparently, it encounter a NULL file pointer, which is not as expected, for why it encounter such a problem, please refer to this: Bad Pointer error when using File* object
I'm using Apple's SecKeyWrapper class from the CryptoExercise sample code in the Apple docs to do some symmetric encryption with AES128. For some reason, when I encrypt 1-15 characters or 17 characters, it encrypts and decrypts correctly. With 16 characters, I can encrypt, but on decrypt it throws an exception after the CCCryptorFinal call with ccStatus == -4304, which indicates a decode error. (Go figure.)
I understand that AES128 uses 16 bytes per encrypted block, so I get the impression that the error has something to do with the plaintext length falling on the block boundary. Has anyone run into this issue using CommonCryptor or SecKeyWrapper?
The following lines...
// We don't want to toss padding on if we don't need to
if (*pkcs7 != kCCOptionECBMode) {
if ((plainTextBufferSize % kChosenCipherBlockSize) == 0) {
*pkcs7 = 0x0000;
} else {
*pkcs7 = kCCOptionPKCS7Padding;
}
}
... are the culprits of my issue. To solve it, I simply had to comment them out.
As far as I can tell, the encryption process was not padding on the encryption side, but was then still expecting padding on the decryption side, causing the decryption process to fail (which is generally what I was experiencing).
Always using kCCOptionPKCS7Padding to encrypt/decrypt is working for me so far, for strings that satisfy length % 16 == 0 and those that don't. And, again, this is a modification to the SecKeyWrapper class of the CryptoExercise example code. Not sure how this impacts those of you using CommonCrypto with home-rolled wrappers.
I too have encountered this issue using the CommonCrypto class but for ANY string with a length that was a multiple of 16.
My solution is a total hack since I have not yet found a real solution to the problem.
I pad my string with a space at the end if it is a multiple of 16. It works for my particular scenario since the extra space on the data does not affect the receipt of the data on the other side but I doubt it would work for anyone else's scenario.
Hopefully somebody smarter can point us in the right direction to a real solution.