Date: 2016-10-28 12:39:18 +0200
From: Richard Hughes <<richard.monetdb>>
To: SQL devs <>
Version: 11.23.13 (Jun2016-SP2)
CC: @njnes
Last updated: 2017-03-03 10:24:05 +0100
Comment 24640
Date: 2016-10-28 12:39:18 +0200
From: Richard Hughes <<richard.monetdb>>
This only happened for one of my databases - many others upgraded fine.
Log says:
2016-10-28 10:40:50 MSG testdb[26405]: insert into sys.systemfunctions (select id from sys.functions where name = 'storage' a
2016-10-28 10:40:51 ERR testdb[26405]: !ParseException:SQLparser:DROP FUNCTION: no such function 'isauuid' (uuid)
2016-10-28 10:40:55 MSG merovingian[25817]: database 'testdb' (26405) has crashed (dumped core)
I guess the absence of isauuid(uuid) in this particular database is because it was created after f30d4f669802
The backtrace is:
Thread 5 "mserver5" received signal SIGSEGV, Segmentation fault.
0x00007ffff0dbfca8 in sql_update_median (sql=,
c=) at sql_upgrades.c:1502
1502 in sql_upgrades.c
(gdb) bt
0 0x00007ffff0dbfca8 in sql_update_median (sql=,
c=) at sql_upgrades.c:1502
1 SQLupgrades (c=0x0, c@entry=0x7ffff136d330, m=0x7fffe00103d0)
at sql_upgrades.c:1985
2 0x00007ffff0db8c5b in SQLinitClient (c=0x7ffff136d330)
at sql_scenario.c:581
3 0x00007ffff7a08106 in runPhase (phase=5, c=0x7ffff136d330)
at mal_scenario.c:531
4 runScenarioBody (c=c@entry=0x7ffff136d330) at mal_scenario.c:558
5 0x00007ffff7a08d9d in runScenario (c=c@entry=0x7ffff136d330)
at mal_scenario.c:595
6 0x00007ffff7a092e0 in MSserveClient (dummy=dummy@entry=0x7ffff136d330)
at mal_session.c:457
7 0x00007ffff7a09946 in MSscheduleClient (
command=command@entry=0x7fffe00008d0 "0",
challenge=challenge@entry=0x7fffebffee80 "9JhRYk6qx", fin=0x7fffe0002980,
fout=fout@entry=0x7fffe4002b60) at mal_session.c:342
8 0x00007ffff7a8ab96 in doChallenge (data=) at mal_mapi.c:205
9 0x00007ffff74dde4f in thread_starter (arg=)
at gdk_system.c:485
10 0x00007ffff61420a4 in start_thread (arg=0x7fffebfff700)
at pthread_create.c:309
11 0x00007ffff5e7762d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
The sequence of events is that the DROP FUNCTION error has left m->session->status non-zero, so the next statement which executes after that aborts immediately after parsing (at sql_execute.c:145) but does not set 'msg'. SQLstatementIntern() therefore returns NULL (success) but also leaves '*result' as NULL. sql_update_median() crashes shortly afterwards, being unable to cope with this contradiction.
There are two requests in this bug, therefore:
Fix upgrades from post-f30d4f669802 builds of Jul2015.
Make it easier to diagnose this and/or possible to continue with the upgrade in case of small glitches. As it stands, I have an unusable database until I apply a fix for (1), and it took me about an hour to figure out why.
Comment 24641
Date: 2016-10-28 15:33:52 +0200
From: Richard Hughes <<richard.monetdb>>
Date: 2016-10-28 12:39:18 +0200
From: Richard Hughes <<richard.monetdb>>
To: SQL devs <>
Version: 11.23.13 (Jun2016-SP2)
CC: @njnes
Last updated: 2017-03-03 10:24:05 +0100
Comment 24640
Date: 2016-10-28 12:39:18 +0200
From: Richard Hughes <<richard.monetdb>>
This only happened for one of my databases - many others upgraded fine.
Log says:
2016-10-28 10:40:50 MSG testdb[26405]: insert into sys.systemfunctions (select id from sys.functions where name = 'storage' a
2016-10-28 10:40:51 ERR testdb[26405]: !ParseException:SQLparser:DROP FUNCTION: no such function 'isauuid' (uuid)
2016-10-28 10:40:55 MSG merovingian[25817]: database 'testdb' (26405) has crashed (dumped core)
I guess the absence of isauuid(uuid) in this particular database is because it was created after f30d4f669802
The backtrace is:
Thread 5 "mserver5" received signal SIGSEGV, Segmentation fault.
0x00007ffff0dbfca8 in sql_update_median (sql=,
c=) at sql_upgrades.c:1502
1502 in sql_upgrades.c
(gdb) bt
0 0x00007ffff0dbfca8 in sql_update_median (sql=,
c=) at sql_upgrades.c:1502
1 SQLupgrades (c=0x0, c@entry=0x7ffff136d330, m=0x7fffe00103d0)
at sql_upgrades.c:1985
2 0x00007ffff0db8c5b in SQLinitClient (c=0x7ffff136d330)
at sql_scenario.c:581
3 0x00007ffff7a08106 in runPhase (phase=5, c=0x7ffff136d330)
at mal_scenario.c:531
4 runScenarioBody (c=c@entry=0x7ffff136d330) at mal_scenario.c:558
5 0x00007ffff7a08d9d in runScenario (c=c@entry=0x7ffff136d330)
at mal_scenario.c:595
6 0x00007ffff7a092e0 in MSserveClient (dummy=dummy@entry=0x7ffff136d330)
at mal_session.c:457
7 0x00007ffff7a09946 in MSscheduleClient (
command=command@entry=0x7fffe00008d0 "0",
challenge=challenge@entry=0x7fffebffee80 "9JhRYk6qx", fin=0x7fffe0002980,
fout=fout@entry=0x7fffe4002b60) at mal_session.c:342
8 0x00007ffff7a8ab96 in doChallenge (data=) at mal_mapi.c:205
9 0x00007ffff74dde4f in thread_starter (arg=)
at gdk_system.c:485
10 0x00007ffff61420a4 in start_thread (arg=0x7fffebfff700)
at pthread_create.c:309
11 0x00007ffff5e7762d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
The sequence of events is that the DROP FUNCTION error has left m->session->status non-zero, so the next statement which executes after that aborts immediately after parsing (at sql_execute.c:145) but does not set 'msg'. SQLstatementIntern() therefore returns NULL (success) but also leaves '*result' as NULL. sql_update_median() crashes shortly afterwards, being unable to cope with this contradiction.
There are two requests in this bug, therefore:
Fix upgrades from post-f30d4f669802 builds of Jul2015.
Make it easier to diagnose this and/or possible to continue with the upgrade in case of small glitches. As it stands, I have an unusable database until I apply a fix for (1), and it took me about an hour to figure out why.
Comment 24641
Date: 2016-10-28 15:33:52 +0200
From: Richard Hughes <<richard.monetdb>>
Created attachment 490
Proposed fix
This works for me.
Comment 25027
Date: 2017-02-15 20:22:17 +0100
From: @njnes
patch was merged
Comment 25104
Date: 2017-03-03 10:24:05 +0100
From: @sjoerdmullender
Dec2016-SP2 has been released, incorporating the fix.
The text was updated successfully, but these errors were encountered: