OpenSuse 11.2 64-bit

p mutex_own(&buf_pool->LRU_list_mutex)
$9 = 0

In order to reproduce the crash, it is sufficient to run only this reduced statement:

ALTER TABLE lineitem_small ADD PRIMARY KEY (l_orderkey, l_linenumber);

I haven't got the crash so far. Here is what I did in my latest (cleanest) attempt:

• start server with innodb-file-per-table=1 and innodb-file-format=Barracuda, tmpdir pointing at a disk with more space, the rest is default;
• feed mariadb-tools/dbt3_benchmark/dbt3_mysql/make-dbt3-db_pre_create_PK.sql to the server. No modifications were done to the script, apart from pointing it to SF10 data;
• stop server (to backup the database);
• start server with the same exact parameters as before;
• run create statements table t_ps_partkey, alter table t_ps_partkey, create table lineitem_small as given in the description;
• run ALTER TABLE lineitem_small ADD PRIMARY KEY as given in the comment;

The last ALTER TABLE finished fairly fast (in ~30 seconds), no problems or errors in the log file.
After that I tried to drop the PK and run the big ALTER TABLE lineitem_small from the description, adding many indexes, which also went all right.

I was running it on perro, which is openSUSE 11.3 x86_64 8 Gb.

A couple observations:

First, despite what was discussed on IRC, it seems to depend on tmpdir after all. In previous dirty attempts I had been having a problem with disk space on alter table until I switched tmpdir from /tmp (which had about 2 Gb of free space) to the main storage which had about 17 Gb.
Second, when I was having the disk problems, I was getting an error "wrong key", which was preceded by the server complaining into the error log about not enough disk space (error 28). I'm wondering if in certain cases it asserts instead of aborting the operation.

Timour, you were going to check the tmpdir when you were reproducing the issue. Did you have enough space in there?
Also, could you please provide the entire command line for the server startup (or your cnf config if you are using one). I am wondering if it behaves differently for me because I'm using a different set of parameters.

I changed the temporary directory to my home dir, where there was ~25 GB free space.
Still, just executing the statement that adds a PK results in a crash.

The server is a debug build, built with ./BUILD/compile-amd64-debug-max-no-ndb

The server was started from the source tree with the following command line:

./sql/mysqld --no-defaults --skip-networking --datadir=/home/<user>/dbdata/dbt3s10-mdb-5.5-a --tmpdir=/home/<user>/tmp/db --socket=/home/<user>/dbdata/dbt3s10-mdb-5.5-a/mysql.sock --lc-messages-dir=/home/<user>/mprog/src/5.5/sql/share --character-sets-dir=/home/<user>/mprog/src/5.5/sql/share/charsets --lower-case-table-names=1 --key_buffer_size=64M --table_cache=256 --sort_buffer_size=64M --join_buffer_size=512M --read_buffer_size=16M --innodb_buffer_pool_size=1024M --innodb_additional_mem_pool_size=128M --innodb_log_buffer_size=64M --innodb_log_file_size=256M --innodb_file_per_table --innodb_data_file_path=ibdata1:128M:autoextend

Attached mdev-444.data – the load file for the provided test case. ~12 Mb uncompressed, contains 100K rows.

Reproducible on the current MariaDB 5.5 revno 3492 with XtraDB, percona-server revno 288.
Not reproducible on MariaDB 5.5 with InnoDB plugin, current MySQL 5.5, 5.6, MariaDB 5.3.
No crash on a release build.

1. Test case
2. (please note that you need to download and extract
3. the attached file mdev-444.data, put it in <basedir>/mysql-test).
4. run as
5. perl ./mtr -mysqld=innodb_log_buffer_size=64M --mysqld=innodb_log_file_size=64M --mysqld=-innodb_buffer_pool_size=128M main.mdev-444
6. where t/mdev-444.test is the test file

--source include/have_innodb.inc

SET GLOBAL innodb_file_per_table=ON;

USE test;
DROP TABLE IF EXISTS t1;

CREATE TABLE t1 (
`l_orderkey` int(11) NOT NULL DEFAULT '0',
`l_partkey` int(11) DEFAULT NULL,
`l_suppkey` int(11) DEFAULT NULL,
`l_linenumber` int(11) NOT NULL DEFAULT '0',
`l_quantity` double DEFAULT NULL,
`l_extendedprice` double DEFAULT NULL,
`l_discount` double DEFAULT NULL,
`l_tax` double DEFAULT NULL,
`l_returnflag` char(1) DEFAULT NULL,
`l_linestatus` char(1) DEFAULT NULL,
`l_shipDATE` date DEFAULT NULL,
`l_commitDATE` date DEFAULT NULL,
`l_receiptDATE` date DEFAULT NULL,
`l_shipinstruct` char(25) DEFAULT NULL,
`l_shipmode` char(10) DEFAULT NULL,
`l_comment` varchar(44) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

LOAD DATA LOCAL INFILE 'mdev-444.data' INTO TABLE t1;

--enable_reconnect
--append_file $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
restart
EOF
--shutdown_server 60
--source include/wait_until_connected_again.inc

ALTER TABLE t1 ADD PRIMARY KEY (l_orderkey, l_linenumber);

1. Cleanup
   DROP TABLE t1;

1. End of test case

Also filed for Percona Server as https://bugs.launchpad.net/percona-server/+bug/1038225

After conversation with Laurinas on IRC, found out that fix for the bug will be included into the next Percona Server, which should be released ASAP. It could make sense to wait and merge the new XtraDB before MariaDB release, since it has at least one more critical bugfix

merged with XtraDB from Percona-Server-5.5.27-rel28.1