Some things I noticed:
- Disabling the sqlite.so module will "solve" the problem. 
- when using phpinfo() on a website, there is NO segfault on from the command line

Extra note: a build created an ran on RHEL 4 will NOT segfault when using -i

Debug Build => yes

First output:

Program received signal SIGSEGV, Segmentation fault.
0x00b14820 in ?? () from /usr/lib/php/modules/pdo_sqlite.so

Backtrace:
(gdb) bt                                                              
#0  0x00b14820 in ?? () from /usr/lib/php/modules/pdo_sqlite.so       
#1  0x65646e75 in ?? ()                                               
#2  0x656e6966 in ?? ()                                               
.
.
.
.
#67 0x6576206b in ?? ()
#68 0x6f697372 in ?? ()
#69 0x0060206e in ?? () from /usr/lib/libxml2.so.2
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

What was the configure line you used?

Configure Command =>  './configure'  '--host=i686-redhat-linux-gnu' '--build=i686-redhat-linux-gnu' '--target=i386-redhat-linux' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--syscon
fdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../confi
g.cache' '--with-libdir=lib' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-curl' '--with-exec-dir=/usr/bin' '--with-freetype-
dir=/usr' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png-dir=/usr' '--with-pspell' '--with-expat-dir=/usr' '--with-pcre-regex=/usr' '--with-zlib'
 '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--with-kerberos' '--enable-ucd
-snmp-hack' '--with-unixODBC=shared,/usr' '--enable-memory-limit' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--with-mime-magic=/etc/httpd/conf/magic' '--without-sqlite' '--with-libxml-dir=/usr' '--with-xml' '--en
able-force-cgi-redirect' '--enable-pcntl' '--with-imap=shared' '--with-imap-ssl' '--enable-mbstring=shared' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-gd=shared' '--enable-bcmath=shared' '--enable-dba=shared' '--with-db4=/usr'
 '--with-xmlrpc=shared' '--with-ldap=shared' '--with-mysql=shared,/usr' '--with-mysqli=shared,/usr/bin/mysql_config' '--enable-dom=shared' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-pgsql=shared' '--with-snmp=shared,/usr' '--
enable-soap=shared' '--with-xsl=shared,/usr' '--enable-xmlreader=shared' '--enable-xmlwriter=shared' '--enable-fastcgi' '--with-mcrypt=shared,/usr' '--enable-sockets' '--enable-pdo=shared' '--with-pdo-odbc=shared,unixODBC,/usr' '--with-p
do-mysql=shared,/usr' '--with-pdo-pgsql=shared,/usr' '--with-pdo-sqlite=shared'

Have you set date.timezone in your php.ini?

It is indeed set:
date.timezone => Europe/Amsterdam => Europe/Amsterdam

Actually, since you're not even building sqlite (just pdo sqlite), where did that sqlite.so come from? 

that was a typo actually ... it was indeed disabling pdo_sqlite.so

Please try and shorten your configure line to shortest possible with --enable-debug and --disable-all included which still causes the issue.

Hmm don't want to be go offtopic, but when doing a minimal build. Im getting an error when loading the pdo_sqlite modules with:

undefined symbol: sqlite3_libversion

Build line:
'./configure'  '--enable-pdo=shared' '--with-sqlite=shared' '--with-pdo-sqlite=shared' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--with-libdir=lib' '--enable-debug'

If you have some "offtopic" questions not directly related to the initial problem you can reach me on the above email addy ...

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

And if that didn't fix the issue, try exactly this configure line:

# ./configure --disable-all  --enable-pdo=shared --with-sqlite=shared
--with-pdo-sqlite=shared --enable-debug

And make sure the modules you build are the actual modules loaded!

# ./configure --disable-all  --enable-pdo=shared --with-sqlite=shared
--with-pdo-sqlite=shared --enable-debug (as you said)

Results in:
configure: error:
You've configured extension pdo_sqlite, which depends on extension sqlite3,
but you've either not enabled sqlite3, or have disabled it.

#./configure --disable-all  --enable-pdo=shared --with-pdo-sqlite=shared --enable-debug  --without-sqlite --with-sqlite3

Does work with configure and building but still hitting:
http://bugs.php.net/bug.php?id=48614

But does THIS bug still exist?

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I have pretty similiar behaviour in 5.3.2 too. I get segfault if a db_file from PDO command exists (new PDO("sqlite:db_file");). php -i (-m too) also shows segfault:

# php -i
...
pdo_sqlite

PDO Driver for SQLite 3.x => enabled
Segmentation fault



Here is the backtrace:
root@c300:/home/dev# gdb php
GNU gdb 6.8
...
This GDB was configured as "i486-slackware-linux"...
(gdb) run -i
Starting program: /usr/bin/php -i
[Thread debugging using libthread_db enabled]
Error while reading shared library symbols:
Cannot find new threads: generic error
Cannot find new threads: generic error
(gdb) bt
#0  0xb8006351 in _dl_debug_state () from /lib/ld-linux.so.2
#1  0xb8009f0b in dl_open_worker () from /lib/ld-linux.so.2
#2  0xb8005596 in _dl_catch_error () from /lib/ld-linux.so.2
#3  0xb800973e in _dl_open () from /lib/ld-linux.so.2
#4  0xb7dd6bec in dlopen_doit () from /lib/libdl.so.2
#5  0xb8005596 in _dl_catch_error () from /lib/ld-linux.so.2
#6  0xb7dd700c in _dlerror_run () from /lib/libdl.so.2
#7  0xb7dd6b1c in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2
#8  0x081d01e6 in php_load_extension (filename=0xb7c35eb4 "curl.so", type=1, start_now=0) at /home/dev/php-5.3.2/ext/standard/dl.c:147
#9  0x082609fc in php_load_php_extension_cb (arg=0x864af88) at /home/dev/php-5.3.2/main/php_ini.c:349
#10 0x082c3ed2 in zend_llist_apply (l=0x863ecbc, func=0x82609cd <php_load_php_extension_cb>) at /home/dev/php-5.3.2/Zend/zend_llist.c:193
#11 0x0826195f in php_ini_register_extensions () at /home/dev/php-5.3.2/main/php_ini.c:722
#12 0x082598d6 in php_module_startup (sf=0x862cb20, additional_modules=0x0, num_additional_modules=0) at /home/dev/php-5.3.2/main/main.c:2021
#13 0x083a550f in php_cli_startup (sapi_module=0x862cb20) at /home/dev/php-5.3.2/sapi/cli/php_cli.c:401
#14 0x083a62f8 in main (argc=2, argv=0xbf87c6d4) at /home/dev/php-5.3.2/sapi/cli/php_cli.c:775

I was having the same problem.  Apparently it is due to the sqlite3 extension 
being threaded, but php not being compiled with the pthread library.  I was able 
to fix it in FreeBSD by recompiling php with the following option:

LINKTHR    Link thread lib (for threaded extensions)