Created attachment 132697 [details] [review] call procs of annot class only when object not destroyed by Page::removeAnnot Page::removeAnnot (https://cgit.freedesktop.org/poppler/poppler/tree/poppler/Page.cc#n465) crashes after annot is removed AND destroyed. Suggested patch tries to amend that. I am not sure if this raises other issues I must admit, since I am very much a newbie to poppler.
Do you have a pdf file and test code you're using?
Created attachment 133166 [details] Remove annots in page class Yes - attached. The code works well AFTER applying the patch. It uses page->removeAnnot(page->getAnnots()->getAnnot(i)); For reference reasons the related thread incl. sample code and the starting discussion(https://lists.freedesktop.org/archives/poppler/2017-July/012306.html) using annots->removeAnnot(annots->getAnnot(i_annot)); instead which does ultimately not remove the annots which is why I had to choose page->removeAnnot.
We don't really support people using the internal classes, can you reproduce the class using the qt4, qt5 or glib front-end s?
class -> crash on the previous comment
I am not using any front-end to avoid the relevant compilation overhead, since I am on Windows. Sorry.
what using windows has to do with anything? I don't know what part of "We don't really support people using the internal classes" you didn't understand. But if leaving this marked as NEW makes you happier, we can leave it as NEW forever :)
Wait a second - take a very deep breath. I was answering your question which is combined with a statement on support. I was ignoring this ambiguity and sloppiness in your favour and kindly came back to you regarding your info request as flagged. I even overlooked your cryptic typo correction in the comment you sent afterwards. Separately, I am a bit concerned about your tone in the above which may be read as not very friendly. But it is as it is ... And last but not least: Some comments in the code state that the package scope is rather restricted to the UNIX world. So, not very surprisingly, on Windows the package does not compile out of the box - or what exactly do you understand of effectively compiling on Windows an executable depending on poppler, but with little as possible other dependencies straight through (if this wording resembles a bit your words, look which impact this has)? I was willing to help out here, but your words read rather harsh. Please feel free to set the ticket flag to whatever you deem appropriate. And please don't feel too offended if with the flag NEEDINFO you beg for information again and a reply remains outstanding. Nevertheless, thank you for your time. ;)
I am experiencing the same bug when using EVINCE. Deleting an annotation yields about 50% chance that Evince will stop responding before anything changes and forces me to quit Evince by force. I am using poppler 0.57.0-1 and evince 3.24.1-1 on ArchLinux.
And where's the backtrace and the file? We can't magically fix bugs with "sometimes when i do something it seems to fail".
(In reply to Krzysztof Piecuch from comment #8) > I am experiencing the same bug when using EVINCE. Deleting an annotation > yields about 50% chance that Evince will stop responding before anything > changes and forces me to quit Evince by force. I am using poppler 0.57.0-1 > and evince 3.24.1-1 on ArchLinux. This bug you mention is not this bug. I am sorry... I fixed another bug in evince and an oversight of my part introduced and infinite loop that you might or not hit when removing an annotation. I already fixed in git master. But let me repeat the removing annotation freeze in evince is not poppler's fault.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/278.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.