Skip to content
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

Closed
hermanlee opened this issue Sep 28, 2015 · 4 comments
Closed

How to solve the error when compiling #42

hermanlee opened this issue Sep 28, 2015 · 4 comments
Assignees

Comments

@hermanlee
Copy link
Contributor

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)

@yoshinorim yoshinorim removed the myrocks label Oct 7, 2015
@yoshinorim yoshinorim reopened this Oct 7, 2015
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
@gunnarku gunnarku self-assigned this Feb 22, 2016
@gunnarku
Copy link

Determine if this is still an issue and if something needs to be done about it.

@jtolmer
Copy link
Contributor

jtolmer commented Feb 22, 2016

This may have been the same issue I fixed with 95257cb.

@jtolmer
Copy link
Contributor

jtolmer commented Feb 22, 2016

Yep. See #6 (comment) that complains of the same compilation errors.

@jtolmer jtolmer closed this as completed Feb 22, 2016
@gunnarku
Copy link

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants