[parrot/parrot] d56c94: [pmc] add missing fields to StringHandle.clone

[GitHub]

  Branch: refs/heads/smoke-me/gcdebug-ms-gh1196
  Home:   https://github.com/parrot/parrot
  Commit: d56c94296ca148163538be3856418444c4bdd083
      https://github.com/parrot/parrot/commit/d56c94296ca148163538be3856418444c4bdd083
  Author: Reini Urban <rurban at cpanel.net>
  Date:   2015-02-01 (Sun, 01 Feb 2015)

  Changed paths:
    M src/pmc/handle.pmc
    M src/pmc/stringhandle.pmc

  Log Message:
  -----------
  [pmc] add missing fields to StringHandle.clone

read_offset, filename, read_buffer, write_buffer, record_separator
also need to get cloned.
Probably related to GH #1196


  Commit: a88abb9c2d212731511bcc387cb0c3a0a64da3b4
      https://github.com/parrot/parrot/commit/a88abb9c2d212731511bcc387cb0c3a0a64da3b4
  Author: Reini Urban <rurban at cpanel.net>
  Date:   2015-02-01 (Sun, 01 Feb 2015)

  Changed paths:
    M src/gc/string_gc.c
    M src/io/api.c

  Log Message:
  -----------
  [gc] fix a MS segv in Parrot_io_write_s

When certain functions cause a GC, the local string buffers may get
moved away, but local STRING* variables or worse, strings inside a
StringHandle may still point to the old location.

Lock the GC then for this section, mostly during IO writing to string handles,
when the handle needs to realloc its buffer (the stringhandle).
But reading into a buffer is also problematic. we really should know the
size beforehand.

One way to fix GH #1196, lock the GC sweep in those cases.
The other variants would be:
- lock the whole GC via Parrot_block_GC_mark
- unset the PObj_is_movable flag in the STRING that it may not be moved,
  as it is still locally referenced.

Remaining ms test failure: t/pmc/fixedstringarray.t


Compare: https://github.com/parrot/parrot/compare/882c18973268...a88abb9c2d21