seg faults in sqlite3 program

[Kevin O'Gorman]

A small Python program that uses sqlite3 frequently gives me segmentation faults, but I'm not sure it's consistent. Thus I'm a bit baffled about what to include, or how to help narrow down the problem. The inputs and the database are both quite large. The core file is large enough at 12 MB, though I'll xz it for transport.

However, I'll try to attach the core file and the program ( which is pretty simple ). I'm hoping the core file gives you enough of a clue right off.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: libpython3.5-stdlib 3.5.2-2~16.01
ProcVersionSignature: Ubuntu 4.4.0-34.53-generic 4.4.15
Uname: Linux 4.4.0-34-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CurrentDesktop: XFCE
Date: Thu Oct 6 17:40:55 2016
InstallationDate: Installed on 2016-08-08 (59 days ago)
InstallationMedia: Xubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
SourcePackage: python3.5
UpgradeStatus: No upgrade log present (probably fresh install)

[Kevin O'Gorman (kogorman-pacbell)]

here's the program it was running.

Here's the database schema
CREATE TABLE base64 (
        b64char CHAR NOT NULL PRIMARY KEY,
        b64val INTEGER);
CREATE TABLE pos (
        pnum INTEGER PRIMARY KEY AUTOINCREMENT,
        ppos CHAR(64) NOT NULL,
        pcensus INTEGER NOT NULL,
        pscore INTEGER,
        pstate CHAR DEFAULT "N" NOT NULL,
        pmin INTEGER DEFAULT -99 NOT NULL,
        pmax INTEGER DEFAULT 99 NOT NULL,
        pmain CHAR(64));
CREATE UNIQUE INDEX pipos ON pos (ppos);
CREATE TABLE move (
        mfrom INTEGER NOT NULL,
        mto INTEGER NOT NULL,
        mtype CHAR NOT NULL,
        mcell INTEGER NOT NULL,
        mvalue INTEGER,
        ma INTEGER DEFAULT -99,
        mb INTEGER DEFAULT 99,
        PRIMARY KEY (mfrom, mto, mcell));
CREATE UNIQUE INDEX mrev ON move (mto, mfrom, mcell);
CREATE TABLE expanded (
        census INTEGER NOT NULL,
        number INTEGER NOT NULL,
        pos CHAR(64),
        PRIMARY KEY (census, number));
CREATE INDEX exin ON expanded (number);
CREATE INDEX exis ON expanded (pos);

[Kevin O'Gorman (kogorman-pacbell)]

I'm now confident it's consistent. I've rebuilt the database from scratch several times, and it always seg faults at the same stage (there are several stages).

I've tried VACUUM just before that stage, to no effect other than making the failed DB a bit smaller.

I'll be continuing attempts to find a cause or workaround, because I really need this to work. I'd just wish it gave an error message instead of a seg fault.