In the past, I have tried to decrypt PDFs using PDFBox using the following code:
if (doc.isEncrypted()){
doc.openProtection(new StandardDecryptionMaterial(password));
doc.setAllSecurityToBeRemoved(true);
}
(Note that I don't use doc.decrypt(password) because the Javadoc for decrypt() says that openProtection() should be used instead, although why it's not just deprecated is beyond me).
Anyway, this has worked fine for quite a while. However, lately I seem to be getting the following exception:
java.io.IOException: javax.crypto.BadPaddingException: Given final block not properly padded
at javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:118)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:236)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:212)
at org.apache.pdfbox.pdmodel.encryption.SecurityHandler.encryptData(SecurityHandler.java:316)
at org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptStream(SecurityHandler.java:421)
at org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decrypt(SecurityHandler.java:390)
at org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptObject(SecurityHandler.java:365)
at org.apache.pdfbox.pdmodel.encryption.SecurityHandler.proceedDecryption(SecurityHandler.java:196)
at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.decryptDocument(StandardSecurityHandler.java:158)
at org.apache.pdfbox.pdmodel.PDDocument.openProtection(PDDocument.java:1598)
<Stack trace continues with my call to openProtection()>
How can I fix this problem?
This is a known issue, which appears to have been introduced as a result of a Java update. At the time of this writing, a fix for this is in review to be included in version 1.8.8, so just upgrade to version 1.8.8 or later and this problem will go away.
Related
I have some code comments like this:
/**
How to use this method.
#discussion To use it, do something like the following
id hook = [[STDeallocHook alloc] initWithBlock:^{
// Do something when 'hook' is dealloced
}];
*/
So the code example is indented with 4 spaces. When I compile the docset with appledoc, it compiles correctly and shows the code as code in the API reference I generate. However back in XCode (Where I have appledoc creating warnings for issues in the doco) I get the warning:
Invalid [[STDeallocHook alloc] reference found hear STDeallocHook.h#16, unknown object: [STDeallocHook !
I think what's happening is that appledoc is looking for markdown links inside the code block.
How can I stop this warning from appearing?
I've been unable to stop it as well. It looks like it's been a known bug since 2011, but it's still broken.
Interestingly enough, I don't get it for everything. In a large code example, I'll only get a few of them... still haven't figured out how it determines to cause me grief or not...
Workarounds
This works around the warning, and looks fine in the generated documentation, but looks like crap in plain text: substitute the leading [ with the HTML escape code [
Future Fix
Supposedly, the mythical version 3 has addressed it, but I can't find any mention of an ETA for it. There is a "3.0exp1" branch from March 2012, and a "3.0dev" branch from October 2014.
If you have both the time and inclination, maybe you can see how it was fixed and patch it yourself (though the codebase has apparently changed a ton since then).
My Attempt
I felt unsatisfied with that answer, so, I went back and looked at the source code. First time in that code. It's not exactly easy to navigate... and none of the classes are documented, which I find quite strange, especially for a documentation tool.
Anyway, I think I know why I only get the warning sometimes. The parser treats all underscores as formatting markers. Thus, if it finds two of them in the same "block" of text, it splits them up. Since the code I tested on had category documentation, only the last one encountered in each "block" caused a warning... because all the others were treated as italics... and then ignored.
Also, it seems that I may be able to coerce it into skipping source-code blocks if they are marked as either...
#code
[self wjh_doSomething];
#endcode
or
```
[self wjh_doSomething];
```
or
~~~
[self wjh_doSomething];
~~~
The first is common in documentation blocks, the latter two in markdown.
It's a hack, but it seems to work. I sent a PR, which can be found here. Who knows if it will get accepted, but feel free to try it out yourself if you are so inclined.
I think I'll at least use it locally, as it cleans up a ton of warnings for me... and I may just go try to regenerate all my documented stuff to boot.
Edit
Well, I guess I should have gone and looked at the open PRs first. There seems to be a PR already sitting there that deals with the same issue, that has been there since May. It would have saved me time... but it was a little fun experimenting with it a bit ;-)
You may want to use that one... it seems to be simpler. Simpler is better, but I have not used that one and I'm not sure it completely ignores the blocks, but he seems to have quieted the warnings with his patch.
That one does not support #code/#endcode, which I'm glad to have.
I keep getting this error:
Jan 31 13:56:51 Michaels-MacBook-Air.local CocoaDrawing[2129] <Error>: The function 'CGContextErase' is obsolete and will be removed in an upcoming update. Unfortunately, this application, or a library it uses, is using this obsolete function, and is thereby contributing to an overall degradation of system performance.
My program doesn't call that method directly, and frustratingly, I can't find any documentation on this function.
This happens even with a blank (Cocoa) Xcode project. Why am I getting this error?
I had this problem. It was caused by an outdated Wacom Tablet driver. If you have such a driver installed I'd recommend removing it, then reinstalling a more recent driver. That did the trick for me.
Hellow I have one project and while running it I got some warnings:
DEPRECATED: dojo.moduleUrl() use require.toUrl -- will be removed in
version: 2.0
but where is no "moduleUrl" uses in my project, does anybody know how to fix it ? Thanx
You don't say what version of Dojo you are using, but I assume it is 1.9. According to a quick scan dojo.moduleUrl() is used in the dojox section about 40 times. dojo.moduleUrl itself is reporting that it is deprecated.
I would expect that when Dojo 2.0 comes out all the dojox widjets will be upgraded accordingly and your worries will be at an end.
Update: Just noticed a similar answer has been posted while I've been thinking of mine :-)
Some code in the dojox package still uses this function. Are you using anything from the dojox package?
If you want to find out what code is calling it, use the uncompressed dojo files and put a breakpoint in dojo/_base/kernal on ~line 282 (depending on version). When the breakpoint is hit, look at the call stack.
This message is only a warning and not an error, so your code isn't broken.
I've got an app that gets information from a SOAP web service and I want to display the results in a UITableView.
I had a previous version of this app and I'm creating a new version to basically clean things up and get rid of a bunch of legacy code that's deprecated and no longer used.
In the previous version, this worked well. In the new version, not so much.
Basically, the current scenario is returning 3 strings that I'm trying to use as the basis for the data in my UITableView.
I'm struggling with this issue because it's so stinkin' hard to track down EXC_BAD_ACCESS errors!
(Parenthetically, if someone has a way to make the debug experience more like Visual Studio, I'd love to hear it! It's so frustrating to not have any idea which line caused the error, and also to not be able to look through my local variables at the time of the crash to see what's what. I've already added in the exception breakpoint, but that doesn't seem to do much.)
Anyway, the line that's causing the error APPEARS to be:
return [[self Libraries] count];
It occurs in tableView:numberOfRowsInSection:.
The error message I get APPEARS to reference a string that should be stored in the NSMutableArray [self Libraries].
What's going on here?
I'm using ARC, so shouldn't all of my memory management be correctly handled?
I don't have any manual release statements in my code ANYWHERE!
Please help me fix this!
Set NSZombieEnabled, MallocStackLogging, and guard malloc in the debugger. Then, when your App crashes, type this in the gdb console:
(gdb) info malloc-history 0x543216
Replace 0x543216 with the address of the object that caused the crash, and you will get a much more useful stack trace and it should help you pinpoint the exact line in your code that is causing the problem.
See this article for more detailed instructions.
ARC relies on the Apple standard/recommended naming practices. Check that you are not violating any of them.
Just for starters, if "Libraries" is an instance there are are naming issues.
OK, so I feel a little bit silly, but I've got two production machines. On one of them, I had installed a copy of Xcode 4.2 beta alongside the final, production copy. I forgot to uninstall the beta copy and was using it to run my code. As soon as I cleared that up and ran my code against the final, released Xcode 4.2, all works fine again.
As I mentioned to Jonathan Grynspan above, I DO understand Obj-C memory management. For some reason, I was getting a retain/release/release (performed by ARC), and that bug is remedied in the final version.
Thanks for the help in tracking this down! At least I got a definitive answer to WHY the problem existed!
I'm very keen to update a number of our servers to PHP 5.3. This would be in readiness for Zend Framework 2 and also for the apparent performance updates. Unfortunately, i have large amounts of legacy code on these servers which in time will be fixed, but cannot all be fixed before the migration. I'm considering updating but disabling the deprecated function error on all but a few development sites where i can begin to work through updating old code.
error_reporting(E_ALL ^ E_DEPRECATED);
Is there any fundamental reason why this would be a bad idea?
Well, you could forget that you set the flag and wonder why your application breaks in a next PHP update. It can be very frustrating to debug an application without proper error reporting. That's one reason I can think of.
However, if you do it, document it somewhere. It can save you a couple of hours before you remember setting the flag at all.
If you haven't already you should read the migration guide with particular focus on Backward Incompatible Changes and Removed Extensions.
You have bigger issues than deprecation. Ignoring E_DEPRECATED will not suffice. Because of the incompatible changes there will also be other type of errors or, maybe, even worse, unexpected behaviors.
Here's a simple example:
<?php
function goto($line){
echo $line;
}
goto(7);
?>
This code will work fine and output 7 in PHP 5.2.x but will give you a parse error in PHP 5.3.x.
What you need to do is take each item in that guide and check your code and update where needed. To make this faster you could ignore the deprecated functionality in a first phase and just disable error reporting for E_DEPRECATED, but you can't assume that you will only get some harmless warnings when porting to another major PHP branch.
Also don't forget about your hack and fix the deprecated issues as soon as possible.
Regards,
Alin
Note: I tried to answer the question from a practical point of view, so please don't tell me that ignoring warnings is bad. I know that, but I also know that time is not an infinite resource.
I presume you have some kind of test server? If not, you really should set one up and test your code in PHP 5.3. If your code is thoroughly Unit Tested, testing it will take seconds, and fixing it will be fairly quick too, as the unit tests will tell you exactly where to look. If not, then consider making Unit Testing it all a priority before the next release, and in the meantime go through it all, first with E_DEPRECATED warnings disabled and fix anything which comes up, then with it re-enabled once you have time. You could also run a global find-and-replace for easier to fix errors.