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

virtuoso *crashed* after running a SELECT statement #1117

Closed
fuboat opened this issue Apr 10, 2023 · 2 comments
Closed

virtuoso *crashed* after running a SELECT statement #1117

fuboat opened this issue Apr 10, 2023 · 2 comments
Assignees

Comments

@fuboat
Copy link

fuboat commented Apr 10, 2023

Description

When running the following statement on an empty virtuoso-opensource database, the database just crashed:

SELECT table_name as name, 'TABLE' as type, '' as parentname FROM information_schema.tables
UNION 
SELECT column_name as name, data_type as type, table_name as parentname FROM information_schema.columns

The Way to Reproduce

Just running the following command to reproduce the crash:

docker run --name virtdb -itd --env DBA_PASSWORD=dba openlink/virtuoso-opensource-7:7.2.9 # start virtuoso through docker
sleep 10 # wait the server starting
echo "SELECT 1;" | docker exec -i virtdb isql 1111 dba # check whether the simple query works
# The command to crash virtuoso 
echo "SELECT table_name as name, 'TABLE' as type, '' as parentname FROM information_schema.tables UNION SELECT column_name as name, data_type as type, table_name as parentname FROM information_schema.columns;" | docker exec -i virtdb isql 1111 dba

the output in shell:

OpenLink Virtuoso Interactive SQL (Virtuoso)
Version 07.20.3236 as of Feb 27 2023
Type HELP; for help and EXIT; to exit.
Connected to OpenLink Virtuoso
Driver: 07.20.3236 OpenLink Virtuoso ODBC Driver
SQL> 
*** Error 08S01: [Virtuoso Driver]CL065: Lost connection to server
at line 1 of Top-Level:
SELECT table_name as name, 'TABLE' as type, '' as parentname FROM information_schema.tables UNION SELECT column_name as name, data_type as type, table_name as parentname FROM information_schema.columns

You can see the error "Lost connection to server", and the container is stopped due to the abnormal exit of the virtuoso instance.

Backtrace

The backtrace when crash is as follow. I compiled virtuoso-opensource 7.2.9 with debug mode to get it.

Thread 8 "virtuoso-t" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdfdb4700 (LWP 1440941)]
0x00000000005533b6 in mp_box_deserialize_string (mp=0x7fffc806bfc0, 
    text=0xe34ce1f37a6c3a64 <error: Cannot access memory at address 0xe34ce1f37a6c3a64>, opt_len=2147483647, offset=0) at regist.c:292
292       switch ((dtp_t)text[0])
(gdb) bt
#0  0x00000000005533b6 in mp_box_deserialize_string (mp=0x7fffc806bfc0, 
    text=0xe34ce1f37a6c3a64 <error: Cannot access memory at address 0xe34ce1f37a6c3a64>, opt_len=2147483647, offset=0) at regist.c:292
#1  0x0000000000427b34 in cha_box_col (cha=0x7fffec416108, ha=0x7fffc8025bf0, row=0x7fffec424720 "k9\241\220(\230\310\r", inx=3)
    at chash.c:2320
#2  0x00000000004253f1 in chash_to_memcache (inst=0x7fffc802b2f8, tree=0x7fffc802a158, ha=0x7fffc8025bf0) at chash.c:2364
#3  0x00000000004278e4 in setp_chash_distinct (setp=0x7fffc8025970, inst=0x7fffc802b2f8) at chash.c:2292
#4  0x0000000000593df7 in setp_node_run (setp=0x7fffc8025970, inst=0x7fffc802b2f8, state=0x7fffc802b2f8, print_blobs=0) at sort.c:385
#5  0x00000000005948c7 in setp_node_input (setp=0x7fffc8025970, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sort.c:606
#6  0x00000000006bb4e3 in qn_input (xx=0x7fffc8025970, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
#7  0x00000000006bb74a in qn_send_output (src=0x7fffc8024ae0, state=0x7fffc802b2f8) at sqlrun.c:1028
#8  0x000000000042b6f8 in hash_source_chash_input (hs=0x7fffc8024ae0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at chash.c:3233
#9  0x00000000004d268c in hash_source_input (hs=0x7fffc8024ae0, qst=0x7fffc802b2f8, qst_cont=0x7fffc802b2f8) at hash.c:2613
#10 0x00000000006bb4e3 in qn_input (xx=0x7fffc8024ae0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
#11 0x00000000006bb8e6 in qn_ts_send_output (src=0x7fffc8024400, state=0x7fffc802b2f8, after_join_test=0x0) at sqlrun.c:1059
#12 0x00000000006bf39f in table_source_input (ts=0x7fffc8024400, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:1991
#13 0x00000000006bb4e3 in qn_input (xx=0x7fffc8024400, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
#14 0x00000000006bb8e6 in qn_ts_send_output (src=0x7fffc80235b0, state=0x7fffc802b2f8, after_join_test=0x0) at sqlrun.c:1059
#15 0x00000000006bf39f in table_source_input (ts=0x7fffc80235b0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:1991
#16 0x00000000006bb4e3 in qn_input (xx=0x7fffc80235b0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
#17 0x0000000000594e55 in union_node_input (un=0x7fffc800f5d0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sort.c:672
#18 0x000000000066c60f in qr_resume_pending_nodes (subq=0x7fffc8020680, inst=0x7fffc802b2f8) at sqlintrp.c:1185
#19 0x000000000066c923 in subq_next (subq=0x7fffc8020680, inst=0x7fffc802b2f8, cr_state=2) at sqlintrp.c:1243
#20 0x000000000070e52c in subq_node_vec_input (sqs=0x7fffc801dbc0, inst=0x7fffc802b2f8, state=0x0) at sqlvnode.c:702
#21 0x0000000000594a8b in subq_node_input (sqs=0x7fffc801dbc0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sort.c:691
#22 0x00000000006bb4e3 in qn_input (xx=0x7fffc801dbc0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
#23 0x00000000006bb74a in qn_send_output (src=0x7fffc80202b0, state=0x7fffc802b2f8) at sqlrun.c:1028
#24 0x0000000000439b1a in chash_fill_input (fref=0x7fffc80202b0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at chash.c:6013
#25 0x00000000004d3c05 in hash_fill_node_input (fref=0x7fffc80202b0, inst=0x7fffc802b2f8, qst=0x7fffc802b2f8) at hash.c:3253
#26 0x00000000006bb4e3 in qn_input (xx=0x7fffc80202b0, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
#27 0x00000000006bb74a in qn_send_output (src=0x7fffc8027e30, state=0x7fffc802b2f8) at sqlrun.c:1028
#28 0x000000000070e189 in set_ctr_vec_input (sctr=0x7fffc8027e30, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlvnode.c:632
#29 0x0000000000596fb4 in set_ctr_input (sctr=0x7fffc8027e30, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sort.c:1319
#30 0x00000000006bb4e3 in qn_input (xx=0x7fffc8027e30, inst=0x7fffc802b2f8, state=0x7fffc802b2f8) at sqlrun.c:982
#31 0x00000000006c791e in qr_exec (cli=0x7fffc8000e30, qr=0x7fffc801a380, caller=0x2, cr_name=0x7fffc802bdf8 "s1111_1_0", stmt=0x7fffc8018b30, 
    lc_ret=0x0, parms=0x7fffd4021de8, opts=0x7fffd4021f08, named_params=0) at sqlrun.c:4344
#32 0x00000000006d1f5b in sf_sql_execute (stmt_id=0x7fffd4021e08 "s1111_1_0", text=0x72e2658 "\320\b", cursor_name=0x7fffd4021ec8 "s1111_1_0", 
    params=0x7fffd4021ea8, current_ofs=0x7fffd4021dc8, options=0x7fffd4021f08) at sqlsrv.c:2006
#33 0x00000000006d26fe in sf_sql_execute_w (stmt_id=0x7fffd4021e08 "s1111_1_0", text=0x72e2658 "\320\b", 
    cursor_name=0x7fffd4021ec8 "s1111_1_0", params=0x7fffd4021ea8, current_ofs=0x7fffd4021dc8, options=0x7fffd4021f08) at sqlsrv.c:2049
#34 0x00000000006d9620 in sf_sql_execute_wrapper (args=0x7fffdfdb3e30) at sqlsrv.c:3995
#35 0x0000000000b777f6 in future_wrapper (ignore=0x0) at Dkernel.c:1171
#36 0x0000000000b7da94 in _thread_boot (arg=0x7fffd4011370) at sched_pthread.c:296
#37 0x00007ffff7c3a609 in start_thread (arg=<optimized out>) at pthread_create.c:477
--Type <RET> for more, q to quit, c to continue without paging--
#38 0x00007ffff7a0a133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
@HughWilliams
Copy link
Collaborator

We are looking into this issue ...

@pkleef pkleef self-assigned this Apr 12, 2023
@TallTed
Copy link
Collaborator

TallTed commented Apr 14, 2023

So it doesn't go unsaid --

@fuboat, THANK YOU for all these bug reports! The detailed recreation guidance is particularly helpful!

@pkleef pkleef closed this as completed in 7c488ae Apr 17, 2023
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