[win32] Cut object pasted as bitmap when running inkscape.exe through gdb

Ok, it happened again and this time I saved the file before, after and the created .png image file.
I can repeat this only if running inkscape through gdb. If do the exact same things under inkscapec it doesn't happen.

- open the file boh.svg;
- maximize the window;
- shift-ctrl-L to open layers panel;
- select Layer 2;
- select the rectangle with C2 inside (drag-select);
- ctrl-x;
- ctrl-alt-v and you get boh after.svg and inkscape_pasted_image_20081111_151856.png in your current directory.
Also note that the copy position is not the original (compare boh.svg and boh after.svg).

Inkscape 0.46+devel, revision 20168, built Nov 10 2008
Windows XP SP3, Pentium 4 3,2 GHz, 2GB RAM
GNU gdb 6.8 configured as "i686-pc-mingw32"

Still happening with Inkscape 0.46+devel, revision 20342, built Dec 10 2008 (compiled under WXP SP3 with mingw).
Still happening only when running under gdb, not under inkscapec.

I just tried it again with SVN 21645: running under gdb (and only in this case) the problem is still there
The only news is that the png is at a higher resolution, so you don't see the difference on screen untill you zoom in (or try to edit).

Don't even need to open "boh.svg": just run inkgdb, draw a square, ctrl-c, ctrl-alt-v: the paste is done as raster and under the cursor (as if a "normal" ctrl-v was issued).

just a sample from a superficial (short of time, have to go now) googling after "debugger bug clipboard"... does this make sense in relation to your bug? AFAIU it says there's an interaction between the debugger - clipboard - application... it's an old blog post but maybe a hint to those who think in code?

<http://blogs.msdn.com/stevejs/archive/2005/12/08/501939.aspx>
"Not rendering the UI is only one problem that can happen due to the debugger stopping a process. A really bad problem that lack of message pumping can cause is clipboard deadlock. The real problem is due to delayed rendering, which requires the app that copied to the clipboard to be live. You can read about delayed rendering on the MSDN Clipboard Operations page. The basic problem is that the application you are debugging owns the clipboard, and other apps need it to respond to messages to get the contents of the clipboard."

If I correctly understood, this seems to deal with breakpoints: if you set a breakpoint, a copy operation not ended before you paste could result in a deadlock, i.e. everything freezes. This if Inkscape (GTK) uses delayed rendering.
This is not our case as the paste operation is "correctly" performed (but for what is pasted) and no breakpoints are being set in gdb.

(finally making my first steps toward learning how to use gdb) I cannot reproduce the 'copied object pasted as bitmap' issue when running

  Inkscape 0.46+devel r21714
  GNU gdb 6.3.50-20050815 (Apple version gdb-768). This GDB was configured as "i386-apple-darwin".
  OS X 10.5.7.

(there is no separate symbol-file 'inkscape.dbg' though - Inkscape.app was built with 'Debug info' enabled <http://inkscape.modevia.com/macosx-snap/Inkscape-21714-10.5-i386-info.txt> - don't know yet if it's needed it on osx)

This is happening in inkscape 0.47pre1 with Intel Tiger. Steps to reproduce:
Draw a circle
Copy the circle (ctl-c)
Paste.

Sometimes it will pull out a dialogue with PDF settings!

If I draw an object and add the pattern-along-path effect, then click on the Edit-on-canvas button, then exit the object, pasting works again as expected. BUT, I can never paste a path into the pattern-along-path effect. It always claims the 'clipboard is empty' and then copy/paste pastes only bitmaps.

@g2010a - related bug report (on Leopard)?
'Paste randomly invokes PDF import'
<https://bugs.launchpad.net/bugs/381540>

This happens also with Leopard 10.5.7, latest XQuartz, with the Inkscape 0.47pre0, 0.47pre1.

Steps to reproduce:
Draw a circle (line)
Copy the circle (line) (ctl-c)
Paste.

The pasted image is a bitmap. In order to "copy" I have to use the clone feature (which is not the same as copy, I know).

This does not happens with 0.46 release.

On 22/7/09 16:38, gglanzani wrote:
> This happens also with Leopard 10.5.7, latest XQuartz, with the Inkscape
> 0.47pre0, 0.47pre1.

This is a known issue with the new clipboard syncing features of
X11/XQuartz. Please see bug #307005,and for a workaround
<http://wiki.inkscape.org/wiki/index.php/FAQ#Copying_and_pasting_in_Inkscape_creates_pixellated_images_instead_of_copying_the_vector_objects>.

Confirmed using today's SVN version 22207. It happened indeed when running through gdb!

Hello Peter,

While trying to debug some Inkscape clipboard weirdness, I stumbled across
your patch:

http://mail.gnome.org/archives/gtk-devel-list/2009-June/msg00062.html

Have you ever received any feedback? It looks like the exact same thing
I'm running into, and might be the root cause of quite some bugs in our
Launchpad tracker. Specifically, I'm trying to solve this bug:

https://bugs.launchpad.net/inkscape/+bug/296778

This one only occurs when running Inkscape through gdb, but that makes it
easier to trace. There's some debugging code in Inkscape which should spit
out this:

** (inkscape.exe:3948): DEBUG: Begin clipboard targets
** (inkscape.exe:3948): DEBUG: Clipboard target: TIMESTAMP
** (inkscape.exe:3948): DEBUG: Clipboard target: TARGETS
** (inkscape.exe:3948): DEBUG: Clipboard target: MULTIPLE
** (inkscape.exe:3948): DEBUG: Clipboard target: image/x-inkscape-svg **
(inkscape.exe:3948): DEBUG: Clipboard target: image/svg+xml
** (inkscape.exe:3948): DEBUG: Clipboard target:
image/x-inkscape-svg-compressed
** (inkscape.exe:3948): DEBUG: Clipboard target: image/svg+xml-compressed
** (inkscape.exe:3948): DEBUG: End clipboard targets

<cut>

But when ran through gdb I get this:

** (inkscape.exe:932): DEBUG: Begin clipboard targets
** (inkscape.exe:932): DEBUG: Clipboard target:
\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe
\u000b
** (inkscape.exe:932): DEBUG: Clipboard target:
\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe
\xee\xfe\xee\xfe\xee\xfe\xee\xfe\u0006
** (inkscape.exe:932): DEBUG: Clipboard target:
\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe
\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\xee\xfe\u0017

<cut>

Looks indeed like some memory corruption, thanks for hunting this one
down! I would never have found this, because although you mention in your
post to the gtk-devel list that you're not a c++ programmer, I'm a
mechanical engineer ;-)

PS: Posting this to launchpad too, hope you don't mind.

Diederik van Lierop

This might not be fixed upstream in GTKmm before our upcoming v0.47 release, and if it would be then we might run into other issues when switching the the lastest GTKmm release. Therefore I've prepared a work around, by simply copying the code from GTKmm and making some minor modifications.

Could you guys please test the attached patch and see if this bug is indeed gone? I cannot reproduce this any longer on XP, and didn't notice any regressions on Linux.

Maybe we're lucky: does this happen to fix any of the other clipboard bugs too?

Diederik

PS: I haven't been able to get into contact with Peter Clifton yet.

Could you explain (to a non-developer ;-) what this patch will fix?
Is it only related to the clipboard issue when running inkscape through gdb on XP?
If I manage to compile it on OS X 10..5.8 what should I look for when testing?

On 09/12/2009 10:00 PM, ~suv wrote:
> Could you explain (to a non-developer ;-) what this patch will fix?
> Is it only related to the clipboard issue when running inkscape through gdb on XP?
> If I manage to compile it on OS X 10..5.8 what should I look for when testing?
Well, basically the call to GTKmm should return a list of clipboard
targets, but in some cases it simply returns rubbish. It's hard to
predict what effect this rubbish might have on Inscape's behaviour, but
this specific bug report is one example of what might happen. But this
same bug might rear its ugly head in more places. All the bugs you've
mentioned before in this post

https://bugs.launchpad.net/inkscape/+bug/389262/comments/14

might have been caused by this! But maybe I'm getting a bit too
optimistic now ;-).

Diederik

Thanks for the explanation! In the meantime, new question ;-)

In your patch you say:
> as copied from /gtkmm-2.16.0/gtk/gtkmm/clipboard.cc

on OS X, MacPorts already provides gtkmm 2.16.0:
| LeWitt:~ suv$ port installed | grep gtkmm
| gtkmm @2.16.0_0 (active)

Is it correct to assume the patch doesn't change the gtkmm clipboard target handling for OS X builds?

On 09/12/2009 10:46 PM, ~suv wrote:
> Is it correct to assume the patch doesn't change the gtkmm clipboard
> target handling for OS X builds?
>
In the cases where the target handling was working perfectly, it should
still work that way. In the cases were target handling showed strange
behavior, it might now work properly. That holds for all platforms (Win
/ Linux / OS X). Please note that GTKmm 2.16 still has the memory
corruption bug, but this is worked around by my patch.

Patch tested with Inkscape r22221 on OS X 10.5.8 - "and didn't notice any regressions ..." so far.

Committed in rev 22229

Upstream fix is being worked on, see

https://bugzilla.gnome.org/show_bug.cgi?id=586626

This is broken in the official release 47-1 (built. 24. Nov 2009) on Darwin/OSX Leopard. It is 100% reproducible when using Ctrl+C/Ctrl+X and Ctrl-V inside a single or across multiple documents. The copies always end up as bitmaps.

On that note: how is it possible that such an important feature is broken in an official milestone release on OSX?

@mauritius - this report is about a different issue that occured on win32 platforms when running inkscape under gdb and fixed in the current release.

You are looking for Bug #307005 “[OS X] copy & paste inserts a bitmap copy instead of the vector object” <https://bugs.launchpad.net/inkscape/+bug/307005>, a known conflict with recent X11/Quartz versions, mentioned in the FAQ along with the workaround.