Jon Thingvold <[EMAIL PROTECTED]> wrote:
>>Description:
>>From error.log:
>
> 040308 9:34:00 InnoDB: Assertion failure in thread 13835301 in file row0upd.c line
> 713
> InnoDB: Failing assertion: len == dfield_get_len(dfield)
> InnoDB: We intentionally generate a memory trap.
> InnoDB: Send a detailed bug report to [EMAIL PROTECTED]
> 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=134217728
> read_buffer_size=131072
> max_used_connections=76
> max_connections=4096
> threads_connected=36
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 655328 K
> bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> thd=0x6cac1ad8
> 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...
> Cannot determine thread, fp=0x6c8f3268, backtrace may not be correct.
> Stack range sanity check OK, backtrace follows:
> 0x80d9e30
> 0x40039f05
> 0x822cf2b
> 0x820f1ea
> 0x821573d
> 0x8215a19
> 0x822de00
> 0x822e9f5
> 0x822ec02
> 0x8217b2d
> 0x8139a1d
> 0x8110c65
> 0x80e5c34
> 0x80e83fa
> 0x80e3893
> 0x80e32ed
> 0x80e2ade
> 0x40036faf
> 0x420e790a
> New value of fp=(nil) failed sanity check, terminating stack trace!
> Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow
> instructions on how to resolve the stack trace. Resolved
> stack trace is much more helpful in diagnosing the problem, so please do
> resolve it
> Trying to get some variables.
> Some pointers may be invalid and cause the dump to abort...
> InnoDB: Thread 13269003 stopped in file ha_innodb.cc line 2843
> InnoDB: Thread 13640724 stopped in file ../../innobase/fil/../include/sync0sync.ic
> line 109
> thd->query at 0x8820228 = UPDATE nas_kundekort_traveller SET firstname='Xxxx Xxxx
> Xxxxxxxxx', addressline1='Xxxxxxxxx 34', city='Xxxxxxx', lastChanged='2004-03-08
> 09:34:00', cpmigProduced=0 WHERE travellerId='x5xx56x3-0x0x-0x34-0003-813x61x80230'
> thd->thread_id=13502
> The manual page at http://www.mysql.com/doc/en/Crashing.html contains
> information that should help you find out what is causing the crash.
>
> Number of processes running now: 23
> mysqld process hanging, pid 2416 - killed
> 040308 09:34:00 mysqld restarted
> 040308 09:34:00 mysqld ended
>
> 040308 09:41:56 mysqld started
> 040308 9:41:56 InnoDB: Database was not shut down normally.
> InnoDB: Starting recovery from log files...
> InnoDB: Starting log scan based on checkpoint at
> InnoDB: log sequence number 12 929457313
> InnoDB: Doing recovery: scanned up to log sequence number 12 930014295
> InnoDB: 1 transaction(s) which must be rolled back or cleaned up
> InnoDB: in total 1 row operations to undo
> InnoDB: Trx id counter is 0 710286080
> 040308 9:41:56 InnoDB: Starting an apply batch of log records to the database...
> InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
> 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
> 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76
> 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
> InnoDB: Apply batch completed
> InnoDB: Starting rollback of uncommitted transactions
> InnoDB: Rolling back trx with id 0 710285796, 1 rows to undo
> InnoDB: Rolling back of trx id 0 710285796 completed
> InnoDB: Rollback of uncommitted transactions completed
> InnoDB: Last MySQL binlog file position 0 11743526, file name
> /var/log/mysql/norwegian/log.2162
> 040308 9:41:58 InnoDB: Flushing modified pages from the buffer pool...
> 040308 9:41:58 InnoDB: Started
> /usr/local/mysql/bin/mysqld: ready for connections.
> Version: '4.0.15-max-log' socket: '/tmp/norwegian.sock' port: 3309
>
>
> Output from:
> ../resolve_stack_dump /tmp/mysqld.sym:
>
>
> 0x80d9e30 handle_segfault + 420
> 0x40039f05 _end + 934967345
> 0x822cf2b row_upd_build_sec_rec_difference_binary + 451
> 0x820f1ea row_ins_sec_index_entry_by_modify + 90
> 0x821573d row_ins_index_entry_low + 1545
> 0x8215a19 row_ins_index_entry + 65
> 0x822de00 row_upd_sec_index_entry + 848
> 0x822e9f5 row_upd + 197
> 0x822ec02 row_upd_step + 330
> 0x8217b2d row_update_for_mysql + 777
> 0x8139a1d update_row__11ha_innobasePCcPc + 589
> 0x8110c65
> mysql_update__FP3THDP13st_table_listRt4List1Z4ItemT2P4ItemP8st_orderUx15enum_duplicates
> + 2493
> 0x80e5c34 mysql_execute_command__Fv + 6320
> 0x80e83fa mysql_parse__FP3THDPcUi + 146
> 0x80e3893 dispatch_command__F19enum_server_commandP3THDPcUi + 1435
> 0x80e32ed do_command__FP3THD + 165
> 0x80e2ade handle_one_connection + 646
> 0x40036faf _end + 934955227
> 0x420e790a _end + 969232950
>
>
>>How-To-Repeat:
> Not able to repeat bug, but it has happend two weeks ago
>>Fix:
> Not known. Mysql works after restart
>
>>Submitter-Id: <submitter ID>
>>Originator: Jon Thingvold
>>Organization:
> Basefarm AS
>>MySQL support: none
>>Synopsis: Mysql crash
>>Severity: serious
>>Priority: high
>>Category: mysql
>>Class: sw-bug
>>Release: mysql-4.0.15-max (Official MySQL-max binary)
>
Seems it's related to the fixed bug:
Fixed a bug: if you created a column prefix secondary index and updated it so
that the last characters in the column prefix were spaces, InnoDB would assert in
row0upd.c, line 713. The same assertion failed if you updated a column in an ordinary
secondary index so that the new value was alphabetically equivalent, but had a
different length. This could happen, for example, in the utf-8 character set if you
updated a letter to its accented or umlaut form.
http://www.mysql.com/doc/en/InnoDB_news-4.0.17.html
--
For technical support contracts, goto https://order.mysql.com/?ref=ensita
This email is sponsored by Ensita.net http://www.ensita.net/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Egor Egorov
/ /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED]
/_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.net
<___/ www.mysql.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
