MySQL Bugs: #15715: crash signal 11 after select on a view with my-large.cnf

Bug #15715	crash signal 11 after select on a view with my-large.cnf
Submitted:	13 Dec 2005 15:37	Modified:	16 Dec 2005 12:54
Reporter:	Rik Druten	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server	Severity:	S1 (Critical)
Version:	5.0.16	OS:	FreeBSD (freebsd 6 /windows xp 2000)
Assigned to:		CPU Architecture:	Any

Description:
I have a 2gb server, OS FREEBSD 6.0.

Everthing works normal with my-medium.cnf.

When using my-large.cnf.
Everthing seems te work normal.

But after creating a view on a table and using a select on that view. The server crashes with a signal 11 and restarts because of mysql_safe.

I have already changed the ulimit.

How to repeat:
When using my-large.cnf.
Everthing seems te work normal.

But after creating a view on a table and using a select on that view. The server crashes with a signal 11 and restarts because of mysql_safe.

Thank you for a problem report. Please, send the content of your error log. There should be some information about the crash in it.

The error log:

051213 20:19:36  mysqld restarted
051213 20:19:36  InnoDB: Started; log sequence number 0 43655
051213 20:19:36 [Note] Recovering after a crash using mysql-bin
051213 20:19:36 [Note] Starting crash recovery...
051213 20:19:36 [Note] Crash recovery finished.
051213 20:19:37 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '5.0.16-log'  socket: '/tmp/mysql.sock'  port: 3306  FreeBSD port: mysql-server-5.0.16
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=268435456
read_buffer_size=1044480
max_used_connections=1
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 466543 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

051213 20:19:43  mysqld restarted

I have also rebuild mysqld from ports with linuxthreads. This does not solve the problem.

This is the output of limit
>> limit

cputime      unlimited
filesize     unlimited
datasize     1048576 kbytes
stacksize    262144 kbytes
coredumpsize unlimited
memoryuse    unlimited
vmemoryuse   unlimited
descriptors  11095
memorylocked unlimited
maxproc      5547
sbsize       unlimited

behavior in mysql-client:

zoekie is (the view).

create view zoekie as select * from groep limit 10;  OR
create view zoekie as select * from groep order by name;

mysql> select * from zoekie;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql> select * from zoekie;

it then displays the results......

WHEN:
create view zoekie as select * from groep;
There's no lost connection!? The table groep is a very small table consisting of 25 records. So the problem seems to be in the LIMIT clause or ORDER clause in combination with the view AND the configuration file my-large.cnf

Under windows2000 same problem (als tried different engines). Example:

create table t1 ( k int(11));
create view v1 AS select * from t1 limit 5;
select * from v1;

[mysqld-nt.exe] stops..........

Under 5.0.15-nt version of server, It didn't crash.
But after upgrading from .15 to .16 the prolem still exists. 
Output of 5.0.15-nt...

mysql> use test
Database changed
mysql> create table t1 ( k int(11));
Query OK, 0 rows affected (1.95 sec)

mysql> create view v1 as select * from t1 limit 5;
Query OK, 0 rows affected (0.30 sec)

mysql> select * from v1;
Empty set (0.19 sec)

mysql> select * from v1;
Empty set (0.00 sec)

mysql> select * from v1;
Empty set (0.00 sec)

mysql> select version();
+-----------+
| version() |
+-----------+
| 5.0.15-nt |
+-----------+
1 row in set (0.06 sec)

mysql>

I was able to repeat the crash just as you described on 5.0.16-nt on Windows. This bug looks like a duplicate of bug #15543, really. It is 5.0.16-specific. So, please, wait for 5.0.17 to be released.