[MDEV-5891] Assertion `! ((size_t)orig == (size_t)-1 && (size_t)dest == (size_t)-1)' failed in open_query::edges_cursor::fetch_row(..) with InnoDB backing table Created: 2014-03-17  Updated: 2014-05-26  Resolved: 2014-05-26

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.9
Fix Version/s: 10.0.11

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Andrew McDonnell
Resolution: Fixed Votes: 0
Labels: oqgraph

Issue Links:
Blocks
blocks MDEV-5988 Running mysqlcheck -A --auto-repair o... Open
Duplicate
is duplicated by MDEV-5810 OQGRAPH causes MariaDB 100% CPU usage Closed
Relates
relates to MDEV-6014 Merge fixed OQGRAPH into 10.0 tree Closed

 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



 Comments   
Comment by Elena Stepanova [ 2014-03-17 ]

The release version falls into a seemingly endless 100%-CPU-consuming loop.

Comment by Arjen Lentz [ 2014-03-18 ]

Curious - pretty sure this worked before and isn't it part of the test suite also?
Hmm. assigning to Andrew.

Comment by Elena Stepanova [ 2014-03-18 ]

I peeked into the test suite while filing, it looked like it only uses MyISAM, but I did not dig deep.

Comment by Arjen Lentz [ 2014-03-19 ]

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

Comment by Elena Stepanova [ 2014-03-19 ]

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.

Comment by Andrew McDonnell [ 2014-04-02 ]

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

Comment by Andrew McDonnell [ 2014-04-02 ]

I have repeated the infinite loop against innodb

Comment by Andrew McDonnell [ 2014-04-02 ]

MyISAM and ariadb seem to work fine in release though

Comment by Andrew McDonnell [ 2014-04-02 ]

(BTW I have an updated test suite that uses your method above and also repeats the tests for MyISAM and aria)

Comment by Andrew McDonnell [ 2014-04-02 ]

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)

Comment by Elena Stepanova [ 2014-04-02 ]

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).

Comment by Heinz Wiesinger [ 2014-04-02 ]

There's also MDEV-5810, which looks similar to the error here

Comment by Andrew McDonnell [ 2014-05-26 ]

This was merged in 10.0.11 and tests currently pass, so I hope I can take the liberty of resolving it...

Generated at Thu Feb 08 07:07:49 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.