Cloning a DBI database handle results in segfault

[HaraldJoerg]

This may be related to #14 and #17, as all circle around the topic of "don't clone database handles".
The attached script segfaults on Linux (Debian stretch, Perl 5.28).
I don't mind if Clone::clone dies if it detects a database handle, but it should somehow safeguard against segfaults.
dbhclone.txt

[atoomic]

I agree with you if this is unsupported we should try to detect and croak when someone clones a dbh... this would protects against such errors in the future

[garu]

I agree, but I think Cloning database handles should be supported if at all possible. The original author considered this a bug, so I think we should too, unless it's really not something anyone should do.

[atoomic]

Having on our roadmap a plan to support forking Database Handlers, does not block us to detect such a clone and trap this with an error like Forking DBH is currently not supported and prevent a SegFault.

Of course if we can come with a patch to support it in a short time, than that warning message becomes unnecessary.

[Koan-Bot]

Draft PR #61 addresses this by skipping PERL_MAGIC_ext ('~') magic in the cloning loop.

Root cause: DBI uses ext magic to attach opaque C-level data structures (containing raw pointers) to its handle SVs. Clone's magic loop was recursively copying these, creating SVs with dangling pointers → segfault on use or cleanup.

Fix: One-line change — add case '~' to the existing magic skip list (alongside taint, backref, arylen_p). The cloned handle won't be usable, but DBI raises a clean error instead of crashing:

handle 0 is owned by thread X not current thread Y

18 new tests in t/13-io-handle.t cover filehandles, IO::Handle, IO::File, IO::Socket, and the original DBI crash scenario.