こんにちは。池田です。

32bitOSだからではとの指摘がありましたが、ログに、

> thd: 0xc7064b8
> stack_bottom = 0x24c513b8 thread_stack 0x30000

とでていることから32bitOSであることは間違いないですね。

key_buffer_size=2147483648　←2GB

このkey_buffer_sizeを1.5GBあるいは1GBくらいに減らして
見てはどうでしょう。

2009/05/26 17:16 浅山雄三 <ALCYONE@xxxxxxxxxx>:
>  浅山と申します。いつもお世話になります。
>
>  約20万件のデータをバッチ処理でUPDATEしている途中でmysqld got
> signal 11となり、コネクションが切れてしまいます。同じデータで何回か実行
> してみましたが、ある時は数千件目、またある時は10数万件目と、実行する度
> にsignal 11が発生するレコードが違っています。
>  signal 11を回避する何かいい手立てがありましたらお教えください。
>
> 【環境】
> REDHAT 5.1
> MySQL 5.1.32
> PHP 5.2.8
>
> 【エラー・ログ】
> 090526  6:13:28 - mysqld got signal 11 ;
> This could be because you hit a bug. It is also possible that this
> binary
> or one of the libraries it was linked against is corrupt, improperly
> built,
> or misconfigured. This error can also be caused by malfunctioning
> hardware.
> We will try our best to scrape up some info that will hopefully help
> diagnose
> the problem, but since we have already crashed, something is definitely
> wrong
> and this may fail.
>
> key_buffer_size=2147483648
> read_buffer_size=2097152
> max_used_connections=2
> max_threads=200
> threads_connected=2
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
> 2917622 K
> bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> thd: 0xc7064b8
> Attempting backtrace. You can use the following information to find out
> where mysqld died. If you see no messages after this, something went
> terribly wrong...
> stack_bottom = 0x24c513b8 thread_stack 0x30000
> Trying to get some variables.
> Some pointers may be invalid and cause the dump to abort...
> thd->query at 0xa0bf070 = update tp_catalog set ngram = '〜〜'
> thd->thread_id=669
> thd->killed=NOT_KILLED
> The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html
> contains
> information that should help you find out what is causing the crash.
> 090526 06:13:28 mysqld_safe Number of processes running now: 0
> 090526 06:13:28 mysqld_safe mysqld restarted
> InnoDB: The log sequence number in ibdata files does not match
> InnoDB: the log sequence number in the ib_logfiles!
> 090526  6:13:29  InnoDB: Database was not shut down normally!
> InnoDB: Starting crash recovery.
> InnoDB: Reading tablespace information from the .ibd files...
> InnoDB: Restoring possible half-written data pages from the doublewrite
> InnoDB: buffer...
> 090526  6:13:29  InnoDB: Started; log sequence number 0 468460067
> 090526  6:13:29 [Note] Event Scheduler: Loaded 0 events
> 090526  6:13:29 [Note] /opac/pp/mysql/bin/bin/mysqld: ready for
> connections.
> Version: '5.1.32'  socket: '/tmp/mysql.sock'  port: 3306  MySQL
> Community Server (GPL)
>
>
>
>  2009年5月26日 17:11:29 (^o^)浅山雄三
>
>
>