[MDEV-16002] Crash in table_cache code Created: 2018-04-24 Updated: 2020-08-25 Resolved: 2018-04-27 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - Spider |
| Affects Version/s: | 10.2.14 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Hartmut Holzgraefe | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 2 |
| Labels: | need_feedback | ||
| Issue Links: |
|
||||||||
| Description |
|
Error log output:
Unmangled backtrace:
|
| Comments |
| Comment by Hartmut Holzgraefe [ 2018-04-24 ] |
|
Looking again the actual table being used in SELECT may not be a Spider table after all ... I will update ticket information as soon as I get information feedback on this ... |
| Comment by Hartmut Holzgraefe [ 2018-04-24 ] |
|
Removed "Spider" from the title, the crashing instance is using Spider tables, but the crash is on an InnoDB table. |
| Comment by Jacob Mathew (Inactive) [ 2018-04-25 ] |
|
Kentoku and I have analyzed the information for this bug. It looks to us that this problem is not a Spider problem. It may also not be a storage engine problem. Marko should be able to determine whether or not it is an InnoDB problem. We think it is not. We think the problem is elsewhere in the MariaDB server code. |
| Comment by Vladislav Vaintroub [ 2018-04-26 ] |
|
That stack trace is broken (sometimes they are not very great, depending on where memory is overriden). It makes sense in such cases to add core-file to the my.ini options, so mysqld.dmp is produced, and then attach the dmp file to the report- the dumps are reasonably small, especially when compressed. |
| Comment by Marko Mäkelä [ 2018-04-26 ] |
|
I agree with the analysis that this does not look like a storage engine problem, but rather a problem with the table cache, which would be svoj’s area of responsibility. In any case, we need a better stack trace or a core dump. |
| Comment by Hartmut Holzgraefe [ 2018-04-27 ] |
|
We can close this one as duplicate of |