If PHP hits the memory limit then mysqlnd loses all control, because Zend takes it.
Can you show more information about the crash? Just the bt, without line numbers doesn't help. valgrind output will be even better.

==22090== Memcheck, a memory error detector
==22090== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==22090== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==22090== Command: /root/php-5.3.3/sapi/cli/php -dmemory_limit=3900000 crash2.php
==22090==

Fatal error: Allowed memory size of 3900000 bytes exhausted (tried to allocate 20 bytes) in /var/www/test2/crash2.php on line 12
==22090== Invalid read of size 4
==22090==    at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103)
==22090==    by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208)
==22090==    by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253)
==22090==    by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285)
==22090==    by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302)
==22090==    by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336)
==22090==    by 0x8178D46: _free_mysql_result (php_mysql.c:417)
==22090==    by 0x83236F1: list_entry_destructor (zend_list.c:184)
==22090==    by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611)
==22090==    by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646)
==22090==    by 0x8315475: zend_deactivate (zend.c:896)
==22090==    by 0x82C5D29: php_request_shutdown (main.c:1633)
==22090==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==22090==
==22090==
==22090== Process terminating with default action of signal 11 (SIGSEGV)
==22090==  Access not within mapped region at address 0x8
==22090==    at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103)
==22090==    by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208)
==22090==    by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253)
==22090==    by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285)
==22090==    by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302)
==22090==    by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336)
==22090==    by 0x8178D46: _free_mysql_result (php_mysql.c:417)
==22090==    by 0x83236F1: list_entry_destructor (zend_list.c:184)
==22090==    by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611)
==22090==    by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646)
==22090==    by 0x8315475: zend_deactivate (zend.c:896)
==22090==    by 0x82C5D29: php_request_shutdown (main.c:1633)
==22090==  If you believe this happened as a result of a stack
==22090==  overflow in your program's main thread (unlikely but
==22090==  possible), you can try to increase the size of the
==22090==  main thread stack using the --main-stacksize= flag.
==22090==  The main thread stack size used in this run was 8388608.
==22090==
==22090== HEAP SUMMARY:
==22090==     in use at exit: 5,336,261 bytes in 31,521 blocks
==22090==   total heap usage: 87,945 allocs, 56,424 frees, 11,136,282 bytes allocated
==22090==
==22090== LEAK SUMMARY:
==22090==    definitely lost: 0 bytes in 0 blocks
==22090==    indirectly lost: 0 bytes in 0 blocks
==22090==      possibly lost: 363,504 bytes in 3,303 blocks
==22090==    still reachable: 4,972,757 bytes in 28,218 blocks
==22090==         suppressed: 0 bytes in 0 blocks
==22090== Rerun with --leak-check=full to see details of leaked memory
==22090==
==22090== For counts of detected and suppressed errors, rerun with: -v
==22090== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 7)
Segmentation fault

This looks strange.
==22090== Invalid read of size 4
==22090==    at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103)

==22090==  Access not within mapped region at address 0x8

current_row in the calling function is NULL. Dereferencing NULL with index gives use first 0x0, then 0x4 and 0x8 - you are on 32bit system, thus 3 fields, in this case, on 64bit, this should have been the second field. But how is current_row NULL when there is explicit check just before that call.
Anyway, could you try this patch (it is against 5.3.4-dev) and tell me whether it works for you. Your sources are a bit different, put it will probably apply without problem, with some notices.
http://hristov.com/tmp/52613.patch.txt

Thanks!

Patch works. No crashes anymore. Although I have to say that I added a check for current_row[col] myself and got some very weird memory corruptions on one webserver (out of ~40) after executing a simple mysql query. Don't know why they occured after adding that check..

Applying your patch to 5.3.3 didn't work, so I added your changes by hand and rediffed: http://pastie.org/private/lu8ajelnwwijjiebzzrrta

Can you test on the server, which exposed this memory problem?
If it is ok, then I will commit the patch to the repository.

Thanks!

Did that already. No memory corruption for now. If it happens again I'll tell you.

alrighty, then I will commit it. If something happens feel free to reopen or create a new report with reference to this one.