Summary: | Paste image from clipboard to another app | ||
---|---|---|---|
Product: | [Unmaintained] kdelibs | Reporter: | Daniel Feiglin <dilogsys> |
Component: | kimgio | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | gauchy, joexray5, l.lunak |
Priority: | NOR | ||
Version: | 3.5 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | dilogsys.vcf |
Description
Daniel Feiglin
2007-02-14 08:28:58 UTC
Does it happen with that software only? Can you do the same pasting to e.g. kolourpaint? And, the backtrace is completely useless. Hello Pino! _Environment: _P4, openSUSE Linux 10.2, KDE. Standard install, CmapTools 4.09_ __Problem:_ Attempting to paste an image from kpfd into a Cmap annotation causes kpdf to crash _Additional checks:_ I checked it with the following: - kolourpaint - OpenOffice Draw - The GIMP - Krita - MS Word under CrossoverOffice (Wine+) Each of these programs was OK. What puzzles me is that once it gets into the KDE clipboard, why should the paste target affect kpdf? _Further testing:_ I ran a few more tests: 1. Run CmapTools & load the target document 2. Load the pdf document into kpdf 3. Copy the image to the clipboard 4. Close kpdf 5. Paste the clipboard to the target Cmap document - and get a few numbers, but no image. I suspect that it tries to treat the clipboard image as text. Next: 1.-3. as above 4. Run kolourpaint and paste the image - OK. 5. Select and recopy the image from the kolourpaint canvas 6. Paste the clipboard to the target Cmap document - and again get a few numbers, but no image 7. This time kolourpaint crashes! _Summary:_ I think that there are several problems here: 1. It seems ridiculous that a paste from the KDE clipboard should affect the task from which it was copied - no matter how badly behaved the receiving task happens to be. 2. It is not a specifically kpdf issue (You're off the hook!) 3. The CmapTools program is written in Java and uses JRE 1.6.0. I suspect that the place to which I wanted to paste the image may be a text-only window, in which case I should have got nothing at all or perhaps an error. There is definitely something amiss here. _What next:_ 1. Perhaps you could forward this material to the relevant KDE folks. 2. Once they have some idea of what's going on, either they or I can co-ordinate with the CmapTools people. 3. In any event, I'm Cc-ing cmapsupport. 4. I'll need a bit of guidance to set up for proper backtraces. Regards, _Daniel_ Pino Toscano wrote: [bugs.kde.org quoted mail] <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hello Pino!<br> <br> <u>Environment:<br> </u>P4, openSUSE Linux 10.2, KDE. Standard install, CmapTools 4.09<u><br> <br> </u><u>Problem:</u><br> Attempting to paste an image from kpfd into a Cmap annotation causes kpdf to crash<br> <br> <u>Additional checks:</u><br> I checked it with the following:<br> - kolourpaint<br> - OpenOffice Draw<br> - The GIMP<br> - Krita<br> - MS Word under CrossoverOffice (Wine+)<br> Each of these programs was OK.<br> <br> What puzzles me is that once it gets into the KDE clipboard, why should the paste target affect kpdf?<br> <br> <u>Further testing:</u><br> I ran a few more tests:<br> <br> 1. Run CmapTools & load the target document<br> 2. Load the pdf document into kpdf<br> 3. Copy the image to the clipboard<br> 4. Close kpdf<br> 5. Paste the clipboard to the target Cmap document - and get a few numbers, but no image. I suspect that it tries to treat the clipboard image as text.<br> <br> Next:<br> 1.-3. as above<br> 4. Run kolourpaint and paste the image - OK.<br> 5. Select and recopy the image from the kolourpaint canvas<br> 6. Paste the clipboard to the target Cmap document - and again get a few numbers, but no image<br> 7. This time kolourpaint crashes!<br> <br> <u>Summary:</u><br> I think that there are several problems here:<br> 1. It seems ridiculous that a paste from the KDE clipboard should affect the task from which it was copied - no matter how badly behaved the receiving task happens to be.<br> 2. It is not a specifically kpdf issue (You're off the hook!)<br> 3. The CmapTools program is written in Java and uses JRE 1.6.0. I suspect that the place to which I wanted to paste the image may be a text-only window, in which case I should have got nothing at all or perhaps an error. There is definitely something amiss here.<br> <br> <u>What next:</u><br> 1. Perhaps you could forward this material to the relevant KDE folks.<br> 2. Once they have some idea of what's going on, either they or I can co-ordinate with the CmapTools people.<br> 3. In any event, I'm Cc-ing cmapsupport.<br> 4. I'll need a bit of guidance to set up for proper backtraces.<br> <br> Regards,<br> <br> <u>Daniel</u><br> <br> <br> <br> <br> <br> Pino Toscano wrote: <blockquote cite="mid20070214142002.15067.qmail@ktown.kde.org" type="cite"> <pre wrap="">------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. <a class="moz-txt-link-freetext" href="http://bugs.kde.org/show_bug.cgi?id=141670">http://bugs.kde.org/show_bug.cgi?id=141670</a> ------- Additional Comments From toscano.pino tiscali it 2007-02-14 15:20 ------- Does it happen with that software only? Can you do the same pasting to e.g. kolourpaint? And, the backtrace is completely useless. </pre> </blockquote> </body> </html> Created an attachment (id=19697) dilogsys.vcf SVN commit 634159 by lunakl: Fix buffer overflow during writing. BUG: 141670 M +2 -1 xview.cpp --- branches/KDE/3.5/kdelibs/kimgio/xview.cpp #634158:634159 @@ -134,7 +134,7 @@ image.convertDepth( 8 ); } - uchar buffer[ 128 ]; + uchar* buffer = new uchar[ w ]; for ( int py = 0; py < h; py++ ) { @@ -162,6 +162,7 @@ } f.writeBlock( (const char*)buffer, w ); } + delete[] buffer; imageio->setStatus( 0 ); } Please verify that removing /opt/kde3/share/services/xv.kimgio avoids the problem. *** Bug 149246 has been marked as a duplicate of this bug. *** *** Bug 156621 has been marked as a duplicate of this bug. *** |