Re: [sqlite] sqlite 3.31.1 crashes in SVN on OpenBSD/sparc64
On Wed, Mar 11, 2020 at 08:20:01AM -0400, Richard Hipp wrote: > On 3/11/20, Stefan Sperling wrote: > > > > Does this help? > > > > Studying the trace output makes me think this is the same problem that > came up on the s390 hardware and was fixed here: > https://www.sqlite.org/src/info/04885763c4cd00cb Yes, this fixes it. Thank you! I will get this patch merged into the OpenBSD port of sqlite. I suppose once the next sqlite release comes around we will be able to drop the patch again since it will already be included in the release. Thanks a lot for your help :) ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite 3.31.1 crashes in SVN on OpenBSD/sparc64
On Tue, Mar 10, 2020 at 06:42:18PM +0100, Stefan Sperling wrote: > On Tue, Mar 10, 2020 at 01:21:34PM -0400, Richard Hipp wrote: > > Set a breakpoint on the sqlite3VdbeExec() function that fires when the > > statement that is crashing is first executed. (You can determine that > > it is the correct statement by looking at the value of p->zSql.) Then > > do: > > > > set p->db->flags = p->db->flags | ((0x060)<<32) > > > > That will turn on bytecode listing and tracing, and might provide > > further clues. Please record and send in the trace. > > I will look into this. Thanks! Does this help? $ egdb --args svn up< GNU gdb (GDB) 7.12.1 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "sparc64-unknown-openbsd6.6". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from svn...done. (gdb) br sqlite3.c:83210 if p->zSql && strncmp(p->zSql, "INSERT OR REPLACE INTO", 22) == 0 No source file named sqlite3.c. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (sqlite3.c:83210 if p->zSql && strncmp(p->zSql, "INSERT OR REPLACE INTO", 22) == 0) pending. (gdb) run Starting program: /usr/local/bin/svn up Updating '.': Breakpoint 1, sqlite3Step (p=0xd69cb26608) at sqlite3.c:83210 83210 rc = sqlite3VdbeExec(p); (gdb) set p->db->flags = p->db->flags | (((unsigned long long)0x060)<<32) (gdb) p /x p->db->flags $1 = 0x60e004a0e0 (gdb) c Continuing. SQL: [INSERT OR REPLACE INTO nodes ( wc_id, local_relpath, op_depth, parent_relpath, repos_id, repos_path, revision, presence, depth, kind, changed_revision, changed_date, changed_author, checksum, properties, translated_size, last_mod_time, dav_cache, symlink_target, file_external, moved_to, moved_here, inherited_props) VALUES (?1, ?2, ?3, ?4, ?5, ?6, ?7, ?8, ?9, ?10, ?11, ?12, ?13, ?14, ?15, ?16, ?17, ?18, ?19, ?20, ?21, ?22, ?23) ] VDBE Program Listing: 0 Init 0 1400 00 Start at 140 1 OpenWrite0 160 2300 root=16 iDb=0; NODES 2 OpenWrite1 290 k(4) 00 root=29 iDb=0; I_NODES_MOVED 3 OpenWrite2 270 k(5,) 00 root=27 iDb=0; I_NODES_PARENT 4 OpenWrite3 170 k(3,,,) 00 root=17 iDb=0; sqlite_autoindex_NODES_1 5 Variable 120 ?100 r[2]=parameter(1,?1) 6 Variable 230 ?200 r[3]=parameter(2,?2) 7 Variable 340 ?300 r[4]=parameter(3,?3) 8 Variable 450 ?400 r[5]=parameter(4,?4) 9 Variable 560 ?500 r[6]=parameter(5,?5) 10 Variable 670 ?600 r[7]=parameter(6,?6) 11 Variable 780 ?700 r[8]=parameter(7,?7) 12 Variable 890 ?800 r[9]=parameter(8,?8) 13 Variable22 100 ?22 00 r[10]=parameter(22,?22) 14 Variable21 110 ?21 00 r[11]=parameter(21,?21) 15 Variable10 120 ?10 00 r[12]=parameter(10,?10) 16 Variable15 130 ?15 00 r[13]=parameter(15,?15) 17 Variable 9 140 ?900 r[14]=parameter(9,?9) 18 Variable14 150 ?14 00 r[15]=parameter(14,?14) 19 Variable19 160 ?19 00 r[16]=parameter(19,?19) 20 Variable11 170 ?11 00 r[17]=parameter(11,?11) 21 Variable12 180 ?12 00 r[18]=parameter(12,?12) 22 Variable13 190 ?13 00 r[19]=parameter(13,?13) 23 Variable16 200 ?16 00 r[20]=parameter(16,?16) 24 Variable17 210 ?17 00 r[21]=parameter(17,?17) 25 Variable18 220 ?18 00 r[22]=parameter(18,?18) 26 Variable20 230 ?20 00 r[23]=parameter(20,?20) 27 Variable23 240 ?23 00 r[24]=parameter(23,?23) 28 NewRowid 010 00 r[1]=rowid 29 HaltIfNull129922 NODES.wc_id 01 if r[2]=null halt
Re: [sqlite] sqlite 3.31.1 crashes in SVN on OpenBSD/sparc64
On Tue, Mar 10, 2020 at 01:21:34PM -0400, Richard Hipp wrote: > On 3/10/20, Stefan Sperling wrote: > > The query being executed is "STMT_INSERT_NODE": > > -- STMT_INSERT_NODE > > INSERT OR REPLACE INTO nodes ( > > wc_id, local_relpath, op_depth, parent_relpath, repos_id, repos_path, > > revision, presence, depth, kind, changed_revision, changed_date, > > changed_author, checksum, properties, translated_size, last_mod_time, > > dav_cache, symlink_target, file_external, moved_to, moved_here, > > inherited_props) > > VALUES (?1, ?2, ?3, ?4, ?5, ?6, ?7, ?8, ?9, ?10, ?11, ?12, ?13, ?14, > > ?15, ?16, ?17, ?18, ?19, ?20, ?21, ?22, ?23) > > It would be great if you could send us the database schema - or even > the whole database if it isn't too big. > > Probably if I have the schema I will be able to repro the problem. The schema is public: https://svn.apache.org/repos/asf/subversion/branches/1.13.x/subversion/libsvn_wc/wc-metadata.sql > Is this only happening on Sparc, and not on x64 or ARM or PPC, etc? It looks like it is specific to sparc64 so far. I cannot reproduce it on amd64 with the same software versions. I do not have access to arm/ppc machines at present. > Does valgrind give any clues? Valgrind does not run on the OpenBSD/sparc64 platform, unfortunately. > Something else that might be helpful, if you have time: > > Set a breakpoint on the sqlite3VdbeExec() function that fires when the > statement that is crashing is first executed. (You can determine that > it is the correct statement by looking at the value of p->zSql.) Then > do: > > set p->db->flags = p->db->flags | ((0x060)<<32) > > That will turn on bytecode listing and tracing, and might provide > further clues. Please record and send in the trace. I will look into this. Thanks! ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite 3.31.1 crashes in SVN on OpenBSD/sparc64
Hi, We have seen sqlite segfault on OpenBSD/sparc64 in the context of running Subversion's regression test suite: https://ci.apache.org/builders/svn-bb-openbsd/builds/498 The log files show that a simple 'svn update' triggers the problem: https://ci.apache.org/builders/svn-bb-openbsd/builds/498/steps/Cleanup/logs/stdio https://ci.apache.org/builders/svn-bb-openbsd/builds/498/steps/svn/logs/stdio The trace within sqlite for this crash looks like : Reading symbols from svn...(no debugging symbols found)...done. [New process 486437] Core was generated by `svn'. Program terminated with signal SIGSEGV, Segmentation fault. #0 sqlite3VdbeRecordUnpack (pKeyInfo=0x4868586788, nKey=-538976289, pKey=0xdfdfdfdfdfdfdfdf, p=0x48d0b05008) at sqlite3.c:81298 81298 idx = getVarint32(aKey, szHdr); (gdb) bt #0 sqlite3VdbeRecordUnpack (pKeyInfo=0x4868586788, nKey=-538976289, pKey=0xdfdfdfdfdfdfdfdf, p=0x48d0b05008) at sqlite3.c:81298 #1 0x004951fca230 in sqlite3VdbeExec (p=0x48a9ed9208) at sqlite3.c:89382 #2 0x004951fcda40 in sqlite3Step (p=) at sqlite3.c:83210 #3 sqlite3_step (pStmt=0x48a9ed9208) at sqlite3.c:17739 Note that on OpenBSD 0xdfdfdfdfdfdfdfdf is written to memory which has been freed. With sqlite compiled with debugging enabled the problem triggers a few lines f code earlier and manifests itself as an assertion failure: #1 0x00e27e089f48 in *_libc___assert2 (file=0xe2eb9d90e0 "sqlite3.c", line=89376, func=0xe2eb9ec9d8 <__func__.59513> "sqlite3VdbeExec", failedexpr=0xe2eb9ee570 "pIn3->flags & MEM_Blob") at /usr/src/lib/libc/gen/assert.c:52 #2 0x00e2eb72d42c in sqlite3VdbeExec (p=0xe2a3d0a408) at sqlite3.c:89376 I have been trying to isolate the problem for a couple of hours and don't believe I'll get much further without help. What's going on in Subversion is that a 'base node' row is being inserted into the NODES table in the working copy database. The query being executed is "STMT_INSERT_NODE": -- STMT_INSERT_NODE INSERT OR REPLACE INTO nodes ( wc_id, local_relpath, op_depth, parent_relpath, repos_id, repos_path, revision, presence, depth, kind, changed_revision, changed_date, changed_author, checksum, properties, translated_size, last_mod_time, dav_cache, symlink_target, file_external, moved_to, moved_here, inherited_props) VALUES (?1, ?2, ?3, ?4, ?5, ?6, ?7, ?8, ?9, ?10, ?11, ?12, ?13, ?14, ?15, ?16, ?17, ?18, ?19, ?20, ?21, ?22, ?23) The input values bound to this query by Subversion all seem fine. I also know that Subversion was working fine before I upgraded this sparc64 machine to a newer OpenBSD -current snapshot on March 8, at which point among many unrelated updates the sqlite package on the system was upgraded from 3.30.1 to 3.31.1. As you can see on this page, builds were green before I upgraded the system: https://ci.apache.org/builders/svn-bb-openbsd Below is a full back trace with debug symbols, compiled from the sqlite-autoconf-3310100 release. At the end I've included values from some data structures that seem relevant. Is this enough information? I can reproduce the problem reliably, so if you need more information just let me know what you want to see. Cheers, Stefan This trace is from 'svn up' in a working copy of svn.apache.org's "repos/asf/apr/trunk" folder, which I happened to have available. (gdb) bt #0 *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:57 #1 0x00e27e089f48 in *_libc___assert2 (file=0xe2eb9d90e0 "sqlite3.c", line=89376, func=0xe2eb9ec9d8 <__func__.59513> "sqlite3VdbeExec", failedexpr=0xe2eb9ee570 "pIn3->flags & MEM_Blob") at /usr/src/lib/libc/gen/assert.c:52 #2 0x00e2eb72d42c in sqlite3VdbeExec (p=0xe2a3d0a408) at sqlite3.c:89376 #3 0x00e2eb71a370 in sqlite3Step (p=0xe2a3d0a408) at sqlite3.c:83210 #4 0x00e2eb71a894 in sqlite3_step (pStmt=0xe2a3d0a408) at sqlite3.c:83275 #5 0x00e30cfff5fc in svn_sqlite__step (got_row=0xfffeb734, stmt=0xe332deb910) at subversion/libsvn_subr/sqlite.c:347 #6 0x00e30cfff6d8 in svn_sqlite__insert (row_id=0x0, stmt=0xe332deb910) at subversion/libsvn_subr/sqlite.c:371 #7 0x00e2896d9034 in insert_base_node (pibb=0xfffeb9a0, wcroot=0xe2754a2d60, local_relpath=0xe27a8481a1 "file_io/os2", scratch_pool=0xe27a848028) at subversion/libsvn_wc/wc_db.c:812 #8 0x00e2896dd1a4 in svn_wc__db_base_add_directory (db=, local_abspath=0xe27a848188 "/home/stsp/src/apr-trunk/file_io/os2", wri_abspath=, repos_relpath=0xe27a8482d8 "apr/apr/trunk/file_io/os2", repos_root_url=0xe2754a7628 "https://svn.apache.org/repos/asf;, repos_uuid=0xe2754a7650 "13f79535-47bb-0310-9956-ffa450edef68", revision=1875042, props=0xe27a848890, changed_rev=1866019, changed_date=1566976038342098, changed_author=0xe27a848ba8 "jorton", children=0x0, depth=svn_depth_empty, dav_cache=0x0, update_actual_props=1, new_actual_props=0xe27a848988, new_iprops=0x0, conflict=0x0, work_items=0x0,
