INSERT into a OQGRAPH table having no attributes crashes mysqld
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| OQGRAPH |
Fix Committed
|
Undecided
|
Andrew McDonnell | ||
Bug Description
(I assume this is different to https:/
When a OQGRAPH table was created with empty DATA_TABLE attribute it caused a null pointer dereference inside table.cc
Thread pointer: 0x0x21e5098
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 = 0x7fb96497be88 thread_stack 0x30000
addr2line: 'sql/mysqld': No such file
sql/mysqld(
sql/mysqld(
/lib/libpthread
/lib/libc.
sql/mysqld(
/home/andrew/
sql/mysqld(
sql/mysqld(
sql/mysqld(
sql/mysqld(
sql/mysqld(
sql/mysqld[
sql/mysqld(
sql/mysqld(
sql/mysqld(
sql/mysqld(
sql/mysqld(
/lib/libpthread
/lib/libc.
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7fb940004b80): INSERT INTO tol_tree (origid,destid) SELECT parent,id FROM tol WHERE parent IS NOT NULL
Connection ID (thread ID): 4
Status: NOT_KILLED
Rerunning mysqld inside gdb yields:
(gdb) bt
#0 __strlen_sse2 () at ../sysdeps/
#1 0x0000000000601e97 in init_tmp_
#2 0x00007fffda1a0de3 in ha_oqgraph::open (this=0x21e16f0, name=0x20a0e50 "./test/tol_tree", mode=<value optimized out>, test_if_
#3 0x00000000006a30ad in handler::ha_open (this=0x0, table_arg=<value optimized out>, name=0x20a0e50 "./test/tol_tree", mode=2, test_if_locked=0) at /home/andrew/
#4 0x0000000000604398 in open_table_
#5 0x00000000005427d0 in open_table (thd=0x21d1058, table_list=
#6 0x0000000000543247 in open_and_
#7 open_tables (thd=0x21d1058, start=<value optimized out>, counter=<value optimized out>, flags=<value optimized out>, prelocking_
#8 0x0000000000543db7 in open_and_
#9 0x000000000057466b in open_and_
#10 0x000000000057bfac in mysql_execute_
#11 0x000000000057e19d in mysql_parse (thd=0x21d1058, rawbuf=<value optimized out>, length=89, parser_
#12 0x000000000057f5f0 in dispatch_command (command=COM_QUERY, thd=0x21d1058, packet=<value optimized out>, packet_
#13 0x000000000062a874 in do_handle_
#14 0x000000000062a900 in handle_
#15 0x00007ffff7bc98ca in start_thread (arg=<value optimized out>) at pthread_
#16 0x00007ffff706b92d in clone () at ../sysdeps/
#17 0x0000000000000000 in ?? ()
This should also be checked at table creation, given that a HQ_OQGRAPH table should have constraints checked similarly to a view, but ha_oqgraph::open() should also check for NULL pointer conditions - this might occur in a plugin upgrade situation for example.
Similar situation applies to ORIGID and DESTID attributes.
Related branches
| Andrew McDonnell (andymc73) wrote | #1 |
| Changed in oqgraph: | |
| status: | New → Fix Committed |
| Andrew McDonnell (andymc73) wrote | #2 |
Note, bug 1134305 would probably make this redundant.
But, as noted in http://
<blockquote>
Alterations that modify only table metadata and not table data can be made immediately by altering the table's .frm file and not touching table contents. The following changes are fast alterations that can be made this way:
Renaming a column, except for the InnoDB storage engine.
Changing the default value of a column (except for NDB tables; see Limitations of NDBCLUSTER online operations).
Changing the definition of an ENUM or SET column by adding new enumeration or set members to the end of the list of valid member values, as long as the storage side of the data type does not change. For example, adding a member to a SET column that has 8 members changes the required storage per value from 1 byte to 2 bytes; this will require a table copy. Adding members in the middle of the list causes renumbering of existing members, which requires a table copy.
</blockquote>
Also the example of a VIEW - if a referenced table is ALTER RENAME'd then the VIEW needs an return an error, it does not show a dependency.