-
Notifications
You must be signed in to change notification settings - Fork 711
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to solve the error when compiling #42
Comments
spetrunia
added a commit
that referenced
this issue
Jan 5, 2016
Summary: Fix issue #42. Also issue #43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Test Plan: mtr t/rocksdb_range.test, used gcov to check the new code is covered Reviewers: maykov, hermanlee4, jonahcohen, jtolmer, yoshinorim Reviewed By: yoshinorim Differential Revision: https://reviews.facebook.net/D35103
Determine if this is still an issue and if something needs to be done about it. |
This may have been the same issue I fixed with 95257cb. |
Yep. See #6 (comment) that complains of the same compilation errors. |
Thanks, you saved me some time :-) |
hermanlee
pushed a commit
that referenced
this issue
Jan 31, 2017
Summary: Fix issue #42. Also issue #43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Test Plan: mtr t/rocksdb_range.test, used gcov to check the new code is covered Reviewers: maykov, hermanlee4, jonahcohen, jtolmer, yoshinorim Reviewed By: yoshinorim Differential Revision: https://reviews.facebook.net/D35103
VitaliyLi
pushed a commit
to VitaliyLi/mysql-5.6
that referenced
this issue
Feb 9, 2017
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Test Plan: mtr t/rocksdb_range.test, used gcov to check the new code is covered Reviewers: maykov, hermanlee4, jonahcohen, jtolmer, yoshinorim Reviewed By: yoshinorim Differential Revision: https://reviews.facebook.net/D35103
facebook-github-bot
pushed a commit
that referenced
this issue
Dec 23, 2019
Summary: Fix issue #42. Also issue #43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 48004e0
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this issue
Aug 12, 2020
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 48004e0
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this issue
Sep 9, 2020
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 48004e0
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this issue
Sep 16, 2020
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 48004e0
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this issue
Oct 5, 2020
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 48004e0
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this issue
Nov 11, 2020
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 48004e0
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this issue
Mar 11, 2021
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 7ed432226c3
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this issue
Aug 16, 2021
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 7ed432226c3
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this issue
Aug 30, 2021
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 7ed432226c3
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this issue
Sep 1, 2021
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 7ed432226c3
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this issue
Sep 2, 2021
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 7ed432226c3
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this issue
Jan 17, 2022
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this issue
Apr 26, 2022
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103
laurynas-biveinis
pushed a commit
to laurynas-biveinis/mysql-5.6
that referenced
this issue
Aug 11, 2022
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this issue
Jun 1, 2023
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this issue
Jun 14, 2023
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103
facebook-github-bot
pushed a commit
that referenced
this issue
Nov 13, 2023
Summary: After bumping the thread stack size to 10MB for ASAN, this test started failing because the Bison parser ran out of stack before the thread did. This test deliberately tries to cause a thread stack overflow by generating an arbitrarily deeply nested SQL query to exercise the `check_stack_overrun` logic. Because our thread stack is so large in ASAN, we hit the Bison "stack" instead first. From the error log: ``` CURRENT_TEST: main.execution_constants mysqltest: At line 42: Query '$query_head 0 $query_tail' failed with wrong error 3950: 'Out of memory', should have failed with any of '0,1436' errors. ``` Parser OOM Stack: ``` (lldb) bt * thread #42, name = 'connection', stop reason = breakpoint 1.1 * frame #0: 0x000000000a33ea53 mysqld`my_error(nr=<unavailable>, MyFlags=<unavailable>) at my_error.cc:217:3 frame #1: 0x0000000008065a21 mysqld`MYSQLerror(location=<unavailable>, thd=<unavailable>, (null)=<unavailable>, s=<unavailable>) (.__uniq.242601085889238811981650692569837157750) at sql_yacc.yy:302:5 [artificial] frame #2: 0x0000000008034304 mysqld`MYSQLparse(YYTHD=<unavailable>, parse_tree=<unavailable>) at sql_yacc.cc:25323:9 frame #3: 0x0000000008009085 mysqld`THD::sql_parser(this=<unavailable>) at sql_class.cc:3811:7 frame #4: 0x00000000082b1f4c mysqld`parse_sql(thd=0x0000628000300100, parser_state=<unavailable>, creation_ctx=<unavailable>) at sql_parse.cc:7963:34 frame #5: 0x00000000082a060d mysqld`dispatch_sql_command(thd=<unavailable>, parser_state=<unavailable>, last_timer=<unavailable>) at sql_parse.cc:5993:11 frame #6: 0x000000000829bd7b mysqld`dispatch_command(thd=<unavailable>, com_data=<unavailable>, command=<unavailable>) at sql_parse.cc:2445:7 frame #7: 0x000000000829e5e9 mysqld`do_command(thd=<unavailable>) at sql_parse.cc:1636:18 frame #8: 0x00000000086c5e34 mysqld`handle_connection(arg=0x00006030001e0940) (.__uniq.188644437719200549207133117087266310382) at connection_handler_per_thread.cc:307:13 frame #9: 0x000000000b3e123b mysqld`pfs_spawn_thread(arg=0x000061600044f4a0) (.__uniq.322994040891040637281203315118403052672) at pfs.cc:2983:3 frame #10: 0x00007ffff7c9abaf libc.so.6`start_thread(arg=<unavailable>) at pthread_create.c:434:8 frame #11: 0x00007ffff7d2d17c libc.so.6`__clone3 at clone3.S:81 ``` sql/sql_yacc.yy: ``` static void MYSQLerror(YYLTYPE *location, THD *thd, Parse_tree_root **, const char *s) { if (strcmp(s, "syntax error") == 0) { thd->syntax_error_at(*location); } else if (strcmp(s, "memory exhausted") == 0) { my_error(ER_DA_OOM, MYF(0)); ... ``` mysql-fork/_build-8.0-ASanDebug/sql/sql_yacc.cc: ``` yyoverflow (YY_("memory exhausted"), &yyss1, yysize * YYSIZEOF (*yyssp), &yyvs1, yysize * YYSIZEOF (*yyvsp), &yyls1, yysize * YYSIZEOF (*yylsp), &yystacksize); ``` Differential Revision: D51233935 fbshipit-source-id: 04391603e7baef0c6e6fa4f308de0aad545474c2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue by MrDimension
Thursday May 28, 2015 at 03:00 GMT
Originally opened as MySQLOnRocksDB#73
The error occurred during "make" process. And I got the error message below:
// ==========================================================
/u01/weidu.lww/myrocks/vio/viosslfactories.c: In function ‘new_VioSSLFd’:
/u01/weidu.lww/myrocks/vio/viosslfactories.c:266:3: warning: implicit declaration of function ‘ERR_clear_error’ [-Wimplicit-function-declaration]
ERR_clear_error();
^
/u01/weidu.lww/myrocks/vio/viosslfactories.c:307:5: error: unknown type name ‘EC_KEY’
EC_KEY ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
^
/u01/weidu.lww/myrocks/vio/viosslfactories.c:307:5: warning: implicit declaration of function ‘EC_KEY_new_by_curve_name’ [-Wimplicit-function-declaration]
/u01/weidu.lww/myrocks/vio/viosslfactories.c:307:45: error: ‘NID_X9_62_prime256v1’ undeclared (first use in this function)
EC_KEY *ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
^
/u01/weidu.lww/myrocks/vio/viosslfactories.c:307:45: note: each undeclared identifier is reported only once for each function it appears in
/u01/weidu.lww/myrocks/vio/viosslfactories.c:309:7: warning: implicit declaration of function ‘SSL_CTX_set_tmp_ecdh’ [-Wimplicit-function-declaration]
SSL_CTX_set_tmp_ecdh(ssl_fd->ssl_context, ecdh);
^
/u01/weidu.lww/myrocks/vio/viosslfactories.c:310:7: warning: implicit declaration of function ‘EC_KEY_free’ [-Wimplicit-function-declaration]
EC_KEY_free(ecdh);
^
make[2]: ** [vio/CMakeFiles/vio.dir/viosslfactories.c.o] Error 1
make[1]: *** [vio/CMakeFiles/vio.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
// ==========================================================
I found the code in vio directory is a little different from the official version of mysql 5.6. When I compile the official version of mysql 5.6, there is no error about this. After a lot of trying, I guess the reason may be about openssl. Did someone meet the same problem? What can I do to solve the problem?
(ps: my gcc version is gcc-4.9.2)
The text was updated successfully, but these errors were encountered: