Looking at your first snippet, and going on gut reaction, I think that the problem is that one or more elements of the code that is being loaded under the auspices of use DBI;, isn't thread-safe.

That is to say, even though each of your threads is getting it's own instance of DBI (and everything that encapsulates), somewhere in that mix, the is a piece of XS or C code that is retaining state in some internal variable. When you create multiple instances within the same process, although Perl is keeping the various perl-level state separated, the internal state at the XS or C level is being shared without any form of interlocking, and it is this that is probably causing the core dump.

Even the standard C-libraries have some standard calls which retain internal state (eg. strtok()), and unless the libraries you are using are specifically thread-enabled, allocating and accessing their internal state indexed by calling thread id, then using such calls in threaded apps is usually fatal.

XS code for modules written prior to the existance of perl's threading will be especially vulnerable to this, and unless the code has been updated very recently to accomodate threading, DBI and its dependanceies are quite lightly to suffer this problem.

You might be able to use liz's forks module as a drop-in replacement for threads and avoid these problems. It's definately worth a look.