Segmentation fault after large table insert #3422
Last updated: 2014-10-31 14:13:42 +0100
Date: 2014-01-20 12:44:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36
mserver5 receives sigsegv after a big insert into a table.
Program received signal SIGSEGV, Segmentation fault.
(gdb) print *t
The problem seems to be caused not by the table being updated, but by a different table 'wave'.
Table wave was created as follows.
I've dropped table wave and re-created it again. The problem has gone.
Date: 2014-01-21 11:22:21 +0100
What did you do to this table "wave" before you got the crash?
Also, if you can reproduce this, please try to do so while the server is running with the extra argument -d10. I would expect this to cause an assertion failure (i.e. abort) or warning message (depending on how the server was built). I'd like to see the messages produced.
Date: 2014-01-21 12:17:43 +0100
I've just created table wave as shown above and inserted data into it using
After I've dropped and re-created the table the problem has gone. I can't reproduce it.
Date: 2014-01-24 10:28:29 +0100
It started happening again for no obvious reason. Now not only on inserts. I was doing a delete from a different table and it crashed.
[Switching to Thread 0x7f6ad8129700 (LWP 27642)]
I was running mserver5 with -d10 option. It didn't complain on any settings.
The only thing it printed after the initial startup message was the following when I connected to it with SQuirrel SQL (jdbc).
Bulk operator required for str.stringleft
Date: 2014-07-25 12:55:39 +0200
I've had a SIGSEGV that looks sufficiently similar to this that I'm going to put it here rather than creating a new bug:
This happened once only, with a load pattern that hasn't changed before or since. Our system runs with exactly one process (having one connection) doing all writes (mostly bulk inserts, with some updates sprinkled in), and a few processes (2 or 3) doing SELECTs. My speculation (based on pretty much zero evidence) is that one of the SELECTs required an index rebuild and raced with a concurrent COPY or UPDATE. Maybe. Good luck!
I'll keep the core file for a few weeks, if anybody wants me to ask it any more questions.
Date: 2014-07-30 15:07:14 +0200
Another SIGSEGV that looks similar, v11.17.17 "Jan2014-SP2" (same binary as my last comment)
The statement being run at the time was
Can somebody please advise me what debugging code I can add in order to help track this down?
Date: 2014-08-01 11:26:14 +0200
Freshly upgraded to Jan2014SP3 (11.17.21), same backtrace as comment 4.
The statements that had recently executed related to sys.timerangecache were:
delete from timerangecache;
Date: 2014-09-17 16:45:21 +0200
Possibly fixed by Sjoerd's changeset: fe0b3b84c297
Date: 2014-10-31 14:13:42 +0100
Oct2014 has been released.
The text was updated successfully, but these errors were encountered: