Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Won't Fix
-
Affects Version/s: 10.0.9
-
Fix Version/s: 10.0.12
-
Component/s: None
-
Labels:
Description
Not critical because it is obvious misuse of the concept, but is worth fixing eventually to avoid the crash
CREATE TABLE t1 (c TINYINT) ENGINE=CONNECT TABLE_TYPE=VEC FILE_NAME='t1.vec';
INSERT INTO t1
VALUES (0),(0),(1),(0),(2),(1),(0),(-1),(0),(0),(0),(0);
DROP TABLE t1;
CREATE TABLE t1 (d DATE) ENGINE=CONNECT TABLE_TYPE=VEC FILE_NAME='t1.vec';
INSERT INTO t1 VALUES ('1999-11-30');
DROP TABLE IF EXISTS t1;
CREATE TABLE t1 (c FLOAT) ENGINE=CONNECT TABLE_TYPE=VEC FILE_NAME='t1.vec';
SELECT * FROM t1;
#1 0x00007f2b66fb93bc in _Unwind_Backtrace () from /lib/x86_64-linux-gnu/libgcc_s.so.1 #2 0x00007f2b66d0e40e in *__GI___backtrace (array=<optimized out>, size=128) at ../sysdeps/x86_64/../ia64/backtrace.c:91 #3 0x0000000000e2b392 in my_print_stacktrace (stack_bottom=0x7f2b658c6dd8 "pлH+\177", thread_stack=294912) at 10.0/mysys/stacktrace.c:246 #4 0x000000000085b5e5 in handle_fatal_signal (sig=11) at 10.0/sql/signal_handler.cc:153 #5 <signal handler called> #6 0x00007f2b6593c730 in Field::set_notnull (this=0x3538373438383639, row_offset=0) at 10.0/sql/field.h:634 #7 0x00007f2b65931874 in ha_connect::MakeRecord (this=0x7f2b39ccac88, buf=0x7f2b48e1a488 "") at 10.0/storage/connect/ha_connect.cc:1427 #8 0x00007f0030303030 in ?? () #9 0x0000000000fdccd0 in ?? () #10 0x0000000000000040 in ?? () #11 0x00007f2b48e1a488 in ?? () #12 0x00007f2b39ccac88 in ?? () #13 0x0000000000fdd880 in ?? () #14 0x0000000000fdccd0 in ?? () #15 0x000000008000000b in ?? () #16 0x00007f2b658c5200 in ?? () #17 0x00007f2b6480a880 in ?? () #18 0x000bd368861fc87d in ?? () #19 0x000000000100ff55 in ?? () #20 0x00007f2b39cde910 in ?? () #21 0x00007f2b658c5270 in ?? () #22 0x000000000086137a in handler::ha_rnd_next (this=<error reading variable: Cannot access memory at address 0x3030303030302db8>, this@entry=<error reading variable: Cannot access memory at address 0x3030303030302e38>, buf=<error reading variable: Cannot access memory at address 0x3030303030302db0>) at 10.0/sql/handler.cc:2505
revision-id: psergey@askmonty.org-20140320205341-um5vxqsh6ljoer4r date: 2014-03-21 00:53:41 +0400 build-date: 2014-03-21 14:04:47 +0400 revno: 4072 branch-nick: 10.0
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
It is true that because, when users create table on existing files, CONNECT cannot check the validity of the definition, many things can happen including crashes.
However, there are so many different cases that it seems difficult to always avoid this. Even if the example above is fixed, this will not be a fix for all cases.
One solution could be to make the whole system "crash proof" by intercepting in a try block the offending interrupts but this is another story (and I don't even know whether this possible on Linux)