Hi Mark, A quick google suggests this is a use after free error, as OpenBSD's allocator apparently fills freed memory pages with the pattern 0xdfdfdfdfdf.
The stack trace reads like it is crashing while finalizing an sqlite_stmt, as part of some automatic perl destructor logic. Every sqlite_stmt you use *must* be finalized via sqlite3_finalize. I'm not exactly sure what that looks like from the other side of DBD, but I would be checking your perl code for a statement/resultset object which outlives the database connection itself. -Rowan On 28 October 2016 at 18:10, <[email protected]> wrote: > I am seeing a Bus Error at the end of a program that to my > inexperienced eye appears to have something to do with SQLite: > > This GDB was configured as "amd64-unknown-openbsd6.0"... > Core was generated by `bif'. > Program terminated with signal 10, Bus error. > Loaded symbols for /mark/src/bif/static/bif > Reading symbols from /usr/lib/libm.so.9.0...done. > Loaded symbols for /usr/lib/libm.so.9.0 > Reading symbols from /usr/lib/libc.so.88.0...done. > Loaded symbols for /usr/lib/libc.so.88.0 > Reading symbols from /usr/libexec/ld.so...done. > Loaded symbols for /usr/libexec/ld.so > #0 releaseMemArray (p=0xdfdfdfdfdfdfdfdf, N=286555) at sqlite3.c:71943 > 71943 sqlite3 *db = p->db; > > (gdb) backtrace > #0 releaseMemArray (p=0xdfdfdfdfdfdfdfdf, N=286555) at sqlite3.c:71943 > #1 0x00001285167d22e4 in sqlite3VdbeClearObject > (db=0xdfdfdfdfdfdfdfdf, p=0x12873d135408) at sqlite3.c:73412 > #2 0x00001285167d23d2 in sqlite3VdbeDelete (p=0x12873d135408) at > sqlite3.c:73444 > #3 0x0000128516815191 in sqlite3VdbeFinalize (p=0x12873d135408) at > sqlite3.c:73362 > #4 0x00001285168152bd in sqlite3_finalize (pStmt=0x12873d135408) at > sqlite3.c:75209 > #5 0x00001285167b5ef5 in sqlite_st_destroy (sth=0x1287bf19a198, > imp_sth=0x128791361b00) at dbdimp.c:1256 > #6 0x00001285167ab7b3 in XS_DBD__SQLite__st_DESTROY (cv=Variable "cv" > is not available.) at SQLite.xsi:799 > #7 0x000012851685e60a in XS_DBI_dispatch (cv=0x12878d7123c8) at > DBI.xs:3781 > #8 0x00001285168e8ab7 in Perl_pp_entersub () at pp_hot.c:2794 > #9 0x0000128516884036 in Perl_call_sv (sv=0x12878d7123c8, flags=45) > at perl.c:2775 > #10 0x00001285168f0c21 in S_curse (sv=0x1287b8a0f1a8, > check_refcnt=true) at sv.c:6704 > #11 0x00001285168f0e07 in Perl_sv_clear (orig_sv=0x1287b8a0f1a8) at > sv.c:6326 > #12 0x00001285168f15b9 in Perl_sv_free2 (sv=0x1287b8a0f1a8, > rc=Variable "rc" is not available.) at sv.c:6805 > #13 0x00001285168e8bc3 in S_visit (f=0x1285168f181c <do_clean_objs>, > flags=2048, mask=2048) at sv.c:485 > #14 0x00001285168f1ab0 in Perl_sv_clean_objs () at sv.c:640 > #15 0x0000128516886bc3 in perl_destruct (my_perl=Variable "my_perl" is > not available.) at perl.c:804 > #16 0x0000128516742a66 in main (argc=5, argv=0x7f7ffffbef58) at > bundle.c:15988 > > I find the pointer address 0xdfdfdfdfdfdfdfdf to be a little > suspicious. > > The program is a static build of Perl that embeds DBD::SQLite which > embeds sqlite. I have seen the error with sqlite version 3.10.2 and > 3.15.0. I have only seen the error on OpenBSD - my Linux builds seem to > have no problem. > > Any ideas how I could debug this further? > > Mark > -- > Mark Lawrence > _______________________________________________ > sqlite-users mailing list > [email protected] > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
