Yes, here are the daemon logs from when it restarts:
Oct 10 15:04:09 ngvm1725 mysqld: 13:04:09 UTC - mysqld got signal 11 ; 
Oct 10 15:04:09 ngvm1725 mysqld: This could be because you hit a bug. It is also possible that this binary 
Oct 10 15:04:09 ngvm1725 mysqld: or one of the libraries it was linked against is corrupt, improperly built, 
Oct 10 15:04:09 ngvm1725 mysqld: or misconfigured. This error can also be caused by malfunctioning hardware. 
Oct 10 15:04:09 ngvm1725 mysqld: We will try our best to scrape up some info that will hopefully help 
Oct 10 15:04:09 ngvm1725 mysqld: diagnose the problem, but since we have already crashed, 
Oct 10 15:04:09 ngvm1725 mysqld: something is definitely wrong and this may fail. 
Oct 10 15:04:09 ngvm1725 mysqld: Please help us make Percona Server better by reporting any 
Oct 10 15:04:09 ngvm1725 mysqld: bugs at http://bugs.percona.com/ 
Oct 10 15:04:09 ngvm1725 mysqld: 
Oct 10 15:04:09 ngvm1725 mysqld: key_buffer_size=33554432 
Oct 10 15:04:09 ngvm1725 mysqld: read_buffer_size=4194304 
Oct 10 15:04:09 ngvm1725 mysqld: max_used_connections=0 
Oct 10 15:04:09 ngvm1725 mysqld: max_threads=1002 
Oct 10 15:04:09 ngvm1725 mysqld: thread_count=2 
Oct 10 15:04:09 ngvm1725 mysqld: connection_count=0 
Oct 10 15:04:09 ngvm1725 mysqld: It is possible that mysqld could use up to 
Oct 10 15:04:09 ngvm1725 mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6203781 K bytes of memory 
Oct 10 15:04:09 ngvm1725 mysqld: Hope that's ok; if not, decrease some variables in the equation. 
Oct 10 15:04:09 ngvm1725 mysqld: 
Oct 10 15:04:09 ngvm1725 mysqld: Thread pointer: 0x29f7af0 
Oct 10 15:04:09 ngvm1725 mysqld: Attempting backtrace. You can use the following information to find out 
Oct 10 15:04:09 ngvm1725 mysqld: where mysqld died. If you see no messages after this, something went 
Oct 10 15:04:09 ngvm1725 mysqld: terribly wrong... 
Oct 10 15:04:09 ngvm1725 mysqld: stack_bottom = 7f4832c319b0 thread_stack 0x30000 
Oct 10 15:04:09 ngvm1725 mysqld: /usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x8adbfe] 
Oct 10 15:04:09 ngvm1725 mysqld: /usr/sbin/mysqld(handle_fatal_signal+0x36c)[0x667e7c] 
Oct 10 15:04:09 ngvm1725 mysqld: /lib/x86_64-linux-gnu/libpthread.so.0(+0xf030)[0x7f4ca76d8030] 
Oct 10 15:04:09 ngvm1725 mysqld: /usr/sbin/mysqld(_Z10unpack_rowPK14Relay_log_infoP5TABLEjPKhPK9st_bitmapPS5_PmS5_+0x192)[0x86eb32] 
Oct 10 15:04:09 ngvm1725 mysqld: /usr/sbin/mysqld(_ZN14Rows_log_event24do_index_scan_and_updateEPK14Relay_log_info+0x1a7)[0x852337] 
Oct 10 15:04:09 ngvm1725 mysqld: /usr/sbin/mysqld(_ZN14Rows_log_event14do_apply_eventEPK14Relay_log_info+0x37f)[0x85188f] 
Oct 10 15:04:09 ngvm1725 mysqld: /usr/sbin/mysqld(_ZN9Log_event11apply_eventEP14Relay_log_info+0x67)[0x84abf7] 
Oct 10 15:04:09 ngvm1725 mysqld: /usr/sbin/mysqld(_Z26apply_event_and_update_posPP9Log_eventP3THDP14Relay_log_info+0x1a3)[0x87dc53] 
Oct 10 15:04:09 ngvm1725 mysqld: /usr/sbin/mysqld(handle_slave_sql+0x8e0)[0x880330] 
Oct 10 15:04:09 ngvm1725 mysqld: /usr/sbin/mysqld(pfs_spawn_thread+0x140)[0xaf3e00] 
Oct 10 15:04:09 ngvm1725 mysqld: /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50)[0x7f4ca76cfb50] 
Oct 10 15:04:09 ngvm1725 mysqld: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f4ca59bbe6d] 
Oct 10 15:04:09 ngvm1725 mysqld: 
Oct 10 15:04:09 ngvm1725 mysqld: Trying to get some variables. 
Oct 10 15:04:09 ngvm1725 mysqld: Some pointers may be invalid and cause the dump to abort. 
Oct 10 15:04:09 ngvm1725 mysqld: Query (0): is an invalid pointer 
Oct 10 15:04:09 ngvm1725 mysqld: Connection ID (thread ID): 2 
Oct 10 15:04:09 ngvm1725 mysqld: Status: NOT_KILLED 
Oct 10 15:04:09 ngvm1725 mysqld: 
Oct 10 15:04:09 ngvm1725 mysqld: You may download the Percona Server operations manual by visiting 
Oct 10 15:04:09 ngvm1725 mysqld: http://www.percona.com/software/percona-server/. You may find information 
Oct 10 15:04:09 ngvm1725 mysqld: in the manual which will help you identify the cause of the crash. 
Oct 10 15:04:09 ngvm1725 mysqld_safe: Number of processes running now: 0 
Oct 10 15:04:09 ngvm1725 mysqld_safe: mysqld restarted

This happens frequently during replication, the replication picks up where it left off thought.

Right now I am running mysqld under gdb so that I could catch the segmentation fault, and that's why it's not restarting this time, it's still running in the debugger and I am currently dumping a core file.