Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0.9
-
None
Description
DROP TABLE IF EXISTS oq_backing, t_oqg; |
CREATE TABLE oq_backing ( |
origid INT UNSIGNED NOT NULL, |
destid INT UNSIGNED NOT NULL, |
PRIMARY KEY (origid, destid), |
KEY (destid) |
) ENGINE=InnoDB;
|
CREATE TABLE t_oqg ( |
latch VARCHAR(32) NULL, |
origid BIGINT UNSIGNED NULL, |
destid BIGINT UNSIGNED NULL, |
weight DOUBLE NULL, |
seq BIGINT UNSIGNED NULL, |
linkid BIGINT UNSIGNED NULL, |
KEY (latch, origid, destid) USING HASH, |
KEY (latch, destid, origid) USING HASH |
)
|
ENGINE=OQGRAPH data_table='oq_backing' origid='origid' destid='destid'; |
SELECT * FROM t_oqg; |
10.0/storage/oqgraph/graphcore.cc:1125: virtual int open_query::edges_cursor::fetch_row(const open_query::row&, open_query::row&, const open_query::reference&): Assertion `! ((size_t)orig == (size_t)-1 && (size_t)dest == (size_t)-1)' failed.
|
140317 23:15:22 [ERROR] mysqld got signal 6 ;
|
#5 0x00007f5207ba96f0 in *__GI_abort () at abort.c:92
|
#6 0x00007f5207b9f621 in *__GI___assert_fail (assertion=0x7f520795d650 "! ((size_t)orig == (size_t)-1 && (size_t)dest == (size_t)-1)", file=<optimized out>, line=1125, function=0x7f520795d760 "virtual int open_query::edges_cursor::fetch_row(const open_query::row&, open_query::row&, const open_query::reference&)") at assert.c:81
|
#7 0x00007f520794249f in open_query::edges_cursor::fetch_row (this=0x7f51db4254b0, row_info=..., result=..., ref=...) at 10.0/storage/oqgraph/graphcore.cc:1125
|
#8 0x00007f52079421e2 in open_query::edges_cursor::fetch_row (this=0x7f51db4254b0, row_info=..., result=...) at 10.0/storage/oqgraph/graphcore.cc:1103
|
#9 0x00007f520794141f in open_query::oqgraph::fetch_row (this=0x7f51db521250, result=...) at 10.0/storage/oqgraph/graphcore.cc:957
|
#10 0x00007f520793c43b in ha_oqgraph::rnd_next (this=0x7f51db54c088, buf=0x7f51db4bd388 "\377") at 10.0/storage/oqgraph/ha_oqgraph.cc:1075
|
#11 0x000000000085fd8a in handler::ha_rnd_next (this=0x7f51db54c088, buf=0x7f51db4bd388 "\377") at 10.0/sql/handler.cc:2505
|
#12 0x000000000098c939 in rr_sequential (info=0x7f51db530130) at 10.0/sql/records.cc:467
|
#13 0x00000000006d345a in join_init_read_record (tab=0x7f51db530088) at 10.0/sql/sql_select.cc:18306
|
#14 0x00000000006d13d0 in sub_select (join=0x7f51db413918, join_tab=0x7f51db530088, end_of_records=false) at 10.0/sql/sql_select.cc:17413
|
#15 0x00000000006d0c97 in do_select (join=0x7f51db413918, fields=0x7f51e9bc4578, table=0x0, procedure=0x0) at 10.0/sql/sql_select.cc:17078
|
#16 0x00000000006ae86e in JOIN::exec_inner (this=0x7f51db413918) at 10.0/sql/sql_select.cc:3065
|
#17 0x00000000006abd80 in JOIN::exec (this=0x7f51db413918) at 10.0/sql/sql_select.cc:2355
|
#18 0x00000000006af0ff in mysql_select (thd=0x7f51e9bc0070, rref_pointer_array=0x7f51e9bc46d8, tables=0x7f51db413270, wild_num=1, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f51db4138f8, unit=0x7f51e9bc3d78, select_lex=0x7f51e9bc4460) at 10.0/sql/sql_select.cc:3292
|
#19 0x00000000006a582f in handle_select (thd=0x7f51e9bc0070, lex=0x7f51e9bc3cb0, result=0x7f51db4138f8, setup_tables_done_option=0) at 10.0/sql/sql_select.cc:372
|
#20 0x000000000067a794 in execute_sqlcom_select (thd=0x7f51e9bc0070, all_tables=0x7f51db413270) at 10.0/sql/sql_parse.cc:5301
|
#21 0x0000000000672b3f in mysql_execute_command (thd=0x7f51e9bc0070) at 10.0/sql/sql_parse.cc:2587
|
#22 0x000000000067cf1f in mysql_parse (thd=0x7f51e9bc0070, rawbuf=0x7f51db413088 "SELECT * FROM t_oqg", length=19, parser_state=0x7f5209a65610) at 10.0/sql/sql_parse.cc:6447
|
#23 0x000000000066fcec in dispatch_command (command=COM_QUERY, thd=0x7f51e9bc0070, packet=0x7f51e9e99071 "", packet_length=19) at 10.0/sql/sql_parse.cc:1308
|
#24 0x000000000066f08e in do_command (thd=0x7f51e9bc0070) at 10.0/sql/sql_parse.cc:1005
|
#25 0x0000000000788ed6 in do_handle_one_connection (thd_arg=0x7f51e9bc0070) at 10.0/sql/sql_connect.cc:1379
|
#26 0x0000000000788c29 in handle_one_connection (arg=0x7f51e9bc0070) at 10.0/sql/sql_connect.cc:1293
|
#27 0x0000000000a2da80 in pfs_spawn_thread (arg=0x7f51e2e9b350) at 10.0/storage/perfschema/pfs.cc:1853
|
#28 0x00007f5209743b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
|
#29 0x00007f5207c4ea7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0x7f51db413088): SELECT * FROM t_oqg
|
Connection ID (thread ID): 3
|
Status: NOT_KILLED
|
revision-id: elenst@wheezy-64.home-20140315125635-4mv83huc3dntadur
|
date: 2014-03-15 16:56:35 +0400
|
build-date: 2014-03-17 23:21:20 +0400
|
revno: 4055
|
branch-nick: 10.0
|
Attachments
Issue Links
Activity
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Arjen Lentz [ arjen ] | Andrew McDonnell [ andymc73 ] |
Curious - pretty sure this worked before and isn't it part of the test suite also?
Hmm. assigning to Andrew.
I peeked into the test suite while filing, it looked like it only uses MyISAM, but I did not dig deep.
You are correct, so far it only uses MyISAM for tests - we weren't sure if we could rely on InnoDB being present.
Can you please advise whether a plugin can rely on another plugin being present, and what else to add to make sure it's all set up to use?
thanks
In case of InnoDB, it is fairly simple, you can add
--source include/have_innodb.inc
at the beginning of your test file, and MTR will make sure that InnoDB is loaded.
Please note however that it will make your test be executed twice – once with InnoDB plugin and once with XtraDB.
If you only want XtraDB, you can instead add --source include/have_xtradb.inc
There are similar include files for some other plugins.
For plugins which don't have the include files, you can do it in the same fashion as you load oqgraph itself – by adding --plugin-load-add=... and a switch for the plugin to your opt file.
| Fix Version/s | 10.0.11 [ 15200 ] | |
| Fix Version/s | 10.0.10 [ 14500 ] |
Believe it or not, in every single one of our test cases, we always insert at least one prior to doing a select!
I suspect that assert should be removed and replaced with
if (orig == ((oqgraph3::vertex_id)-1) && (dest == ((oqgraph3::vertex_id)-1))
|
return oqgraph::NO_MORE_DATA;
|
I will try and test that soon
(BTW I have an updated test suite that uses your method above and also repeats the tests for MyISAM and aria)
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
This is now fixed in my maintenance branch, http://bazaar.launchpad.net/~andymc73/maria/oqgraph-maintenance
If you merge the current head of this branch, you will also get my update tetsing archicture - I am using a common test suite for the core function with dollar-variables to repeat the test for innodb, aria and myisam
I am unsure of the workflow here - I seem to have the ablity to CLOSE FIXED, but I would have thought it cant be resolved until merged into the trunk (which I cant do)
I have created a merge task https://mariadb.atlassian.net/browse/MDEV-6014 .
However, we have other open bugs for OQGRAPH, it makes sense to fix them all first (or decide that they cannot/should not be fixed), and only then do the merge.
MDEV-5988
MDEV-5996
(possibly there are more).
| Fix Version/s | 10.0.12 [ 15201 ] | |
| Fix Version/s | 10.0.11 [ 15200 ] |
This was merged in 10.0.11 and tests currently pass, so I hope I can take the liberty of resolving it...
| Fix Version/s | 10.0.11 [ 15200 ] | |
| Fix Version/s | 10.0.12 [ 15201 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |
| Workflow | defaullt [ 36915 ] | MariaDB v2 [ 42876 ] |
| Workflow | MariaDB v2 [ 42876 ] | MariaDB v3 [ 61896 ] |
| Workflow | MariaDB v3 [ 61896 ] | MariaDB v4 [ 147654 ] |
The release version falls into a seemingly endless 100%-CPU-consuming loop.