A reproduce script and details about the repository would help, what version it is and how you are accessing it etc.

The server is on an Ubuntu box.  The repository is accessed 
via HTTP through Apache with mod_dav_svn.  These are the 
relevant Ubuntu packages and their versions:

apache2/hardy 2.2.8-1ubuntu0.3
libsvn1/intrepid 1.5.1dfsg1-1ubuntu2
libapache2-svn/intrepid 1.5.1dfsg1-1ubuntu2
subversion/intrepid 1.5.1dfsg1-1ubuntu2

I'll work on whittling down the code to a manageable 
reproduce script.

Can you compile a debug build of PHP and the extension? It sounds like the string was NULL.

Now based on the function called its svn_commit and either username or date was NULL.

Here's the backtrace w/ a debug build of PHP.

Program received signal EXC_BAD_ACCESS, Could not access 
memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x00235c68 in add_next_index_string (arg=0x1028f58, str=0x0, 
duplicate=1) at 
/opt/local/var/macports/build/_opt_local_var_macports_source
s_rsync.macports.org_release_ports_www_php5/work/p
hp-5.2.6/Zend/zend_API.c:1202
1202            ZVAL_STRING(tmp, str, duplicate);
(gdb) bt
#0  0x00235c68 in add_next_index_string (arg=0x1028f58, 
str=0x0, duplicate=1) at 
/opt/local/var/macports/build/_opt_local_var_macports_source
s_rsync.macports.org_release_ports_www_php5/work/p
hp-5.2.6/Zend/zend_API.c:1202
#1  0x006e4f88 in zif_svn_commit ()
#2  0x0025a5be in zend_do_fcall_common_helper_SPEC 
(execute_data=0xbfffcc00) at zend_vm_execute.h:200
#3  0x002609b0 in ZEND_DO_FCALL_SPEC_CONST_HANDLER 
(execute_data=0xbfffcc00) at zend_vm_execute.h:1679
#4  0x0025a091 in execute (op_array=0x1023b20) at 
zend_vm_execute.h:92
#5  0x0025a79c in zend_do_fcall_common_helper_SPEC 
(execute_data=0xbfffcd50) at zend_vm_execute.h:234
#6  0x0025b3ee in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(execute_data=0xbfffcd50) at zend_vm_execute.h:322
#7  0x0025a091 in execute (op_array=0x1011cd0) at 
zend_vm_execute.h:92
#8  0x00231773 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at 
/opt/local/var/macports/build/_opt_local_var_macports_source
s_rsync.macports.org_release_ports_www_php5/work/p
hp-5.2.6/Zend/zend.c:1134
#9  0x001d438a in php_execute_script 
(primary_file=0xbfffd470) at 
/opt/local/var/macports/build/_opt_local_var_macports_source
s_rsync.macports.org_release_ports_www_php5/work/p
hp-5.2.6/main/main.c:2005
#10 0x002b7a0b in main (argc=3, argv=0xbfffd54c) at 
/opt/local/var/macports/build/_opt_local_var_macports_source
s_rsync.macports.org_release_ports_www_php5/work/p
hp-5.2.6/sapi/cli/php_cli.c:1140

can you rebuild the svn extension has a debug build as well, 
i'm curious what line in svn.c that is calling 
add_next_index_string() as there are two right next to each 
other in svn_commit.

I realized I never mentioned what version of your extension I was using.  It was 0.4.1 beta.  While recompiling the 
extension with debug symbols I realized I should make sure it's not already fixed in CVS.  It doesn't appear to be.

Here's a backtrace of the crash occurring in HEAD.  Looks like it's the first of those two calls to add_next_index_string():

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x0034640c in add_next_index_string (arg=0x1bc1784, str=0x0, duplicate=1) at 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_php5/work/php-
5.2.6/Zend/zend_API.c:1202
1202            ZVAL_STRING(tmp, str, duplicate);
(gdb) bt
#0  0x0034640c in add_next_index_string (arg=0x1bc1784, str=0x0, duplicate=1) at 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_php5/work/php-
5.2.6/Zend/zend_API.c:1202
#1  0x01bf2f60 in zif_svn_commit (ht=3, return_value=0x1bc1784, return_value_ptr=0x0, this_ptr=0x0, 
return_value_used=0) at /Users/rick/pecl/svn/svn.c:2654
#2  0x0036ad62 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffcc00) at zend_vm_execute.h:200
#3  0x00371154 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbfffcc00) at zend_vm_execute.h:1679
#4  0x0036a835 in execute (op_array=0x1bb9c9c) at zend_vm_execute.h:92
#5  0x0036af40 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffcd50) at zend_vm_execute.h:234
#6  0x0036bb92 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfffcd50) at zend_vm_execute.h:322
#7  0x0036a835 in execute (op_array=0x1ba7e4c) at zend_vm_execute.h:92
#8  0x00341f17 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_php5/work/php-
5.2.6/Zend/zend.c:1134
#9  0x002e4406 in php_execute_script (primary_file=0xbfffd470) at 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_php5/work/php-
5.2.6/main/main.c:2005
#10 0x003c81af in main (argc=3, argv=0xbfffd54c) at 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_php5/work/php-
5.2.6/sapi/cli/php_cli.c:1140
(gdb) 

I'm also still planning on getting you some reproduce code, but that has to wait until I get home later tonight.

Can you comment out the two add_next_index_string lines there 
within svn_commit.

I have a feeling that the revision returned from svn_commit is 
going to be "-1" though I'm not sure why this is the case. 
Have you been able to work out a reproduce case?

Perhaps its a commit hook?

I spent some time with this tonight and finally found a simple test case.  
Here's some reproduce code:

<?php
    $versioned_dir = '/path/to/working/copy';

    // make a new file in the versioned dir
    $new_file = $versioned_dir . '/' . uniqid();
    touch( $new_file );

    // schedule it for addition
    svn_add( $new_file );

    // commit it
    svn_commit( 'testing for php bug', $new_file );
    
    // commit it again, triggering the bus error
    svn_commit( 'testing for php bug', $new_file );
?>

The larger script that I first had problems with processes a large set of xml 
files, commits them, rinse, repeat.  I guess I have some work to do to make sure 
the files are actually modified first. :)

Fixed this now in CVS.