Hello, On Thu, Jan 10, 2013 at 1:03 AM, Joerg Sonnenberger <jo...@britannica.bec.de> wrote: > On Wed, Jan 09, 2013 at 05:02:14PM +0000, Michai Ramakers wrote: >> apart from the question whether cloning from localhost makes sense or >> not (I use this from a script to make work from localhost or remote >> transparent), I experienced very slow network traffic - but no hang - >> while cloning like thus: > > Can you run "echo 'analyze;' | fossil sqlite ori.fossil" first and see if > that helps?
I didn't know the 'analyze' sqlite command, thank you. When trying (I am assuming you meant with '-R' option to point to repo), I got slightly more than I bargained for: --- michai@lime:/tmp$ uname -a NetBSD lime 6.0.1 NetBSD 6.0.1 (GENERIC) amd64 michai@lime:/tmp$ /tmp/fossil ver This is fossil version 1.25 [baa1ebb7d9] 2013-01-07 18:58:30 UTC michai@lime:/tmp$ echo 'analyze;' | /tmp/fossil sqlite -R 100MB.fossil michai@lime:/tmp$ echo 'analyze;' | /tmp/fossil sqlite -R 100MB.fossil Segmentation fault (core dumped) michai@lime:/tmp$ mkdir try michai@lime:/tmp$ cd try/ michai@lime:/tmp/try$ /tmp/fossil open ../100MB.fossil Segmentation fault (core dumped) michai@lime:/tmp/try$ gdb /tmp/fossil GNU gdb (GDB) 7.3.1 Copyright (C) 2011 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 "x86_64--netbsd". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /tmp/fossil...done. (gdb) run open ../100MB.fossil Starting program: /tmp/fossil open ../100MB.fossil Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00000000004b8fa2 in sqlite3VdbeExec (p=<optimized out>) at ./src/sqlite3.c:65390 #2 0x00000000004a91e7 in sqlite3Step (p=0x7f7ff7e3b048) at ./src/sqlite3.c:62231 #3 sqlite3_step (pStmt=0x7f7ff7e3b048) at ./src/sqlite3.c:62305 #4 0x00000000004aa17f in loadStat3 (zDb=0x6974df "main", db=0x7f7ff7e03408) at ./src/sqlite3.c:79808 #5 sqlite3AnalysisLoad (db=0x7f7ff7e03408, iDb=<optimized out>) at ./src/sqlite3.c:14435 #6 0x00000000004aa7c7 in sqlite3InitOne (db=0x7f7ff7e03408, iDb=0, pzErrMsg=0x7f7ff7e03c10) at ./src/sqlite3.c:93962 #7 0x00000000004aa977 in sqlite3Init (db=0x7f7ff7e03408, pzErrMsg=0x7f7ff7e03c10) at ./src/sqlite3.c:94019 #8 0x00000000004aa9ee in sqlite3ReadSchema (pParse=0x7f7ff7e03c08) at ./src/sqlite3.c:94056 #9 0x00000000004ab23d in sqlite3LocateTable (pParse=0x7f7ff7e03c08, isView=0, zName=0x7f7ff7e2ed88 "config", zDbase=0x0) at ./src/sqlite3.c:81103 #10 0x00000000004ab3d5 in selectExpander (pWalker=0x7f7fffffd350, p=0x7f7ff7e2eb88) at ./src/sqlite3.c:97832 #11 0x00000000004681f9 in sqlite3WalkSelect (pWalker=0x7f7fffffd350, p=0x7f7ff7e2eb88) at ./src/sqlite3.c:72494 #12 0x00000000004684ce in sqlite3SelectExpand (pSelect=0x7f7ff7e2eb88, pParse=0x7f7ff7e03c08) at ./src/sqlite3.c:98063 #13 sqlite3SelectPrep (pParse=0x7f7ff7e03c08, p=0x7f7ff7e2eb88, pOuterNC=<optimized out>) at ./src/sqlite3.c:32611 #14 0x000000000048d8ac in sqlite3Select (pParse=0x7f7ff7e03c08, p=0x7f7ff7e2eb88, pDest=0x7f7fffffd6c0) at ./src/sqlite3.c:98412 #15 0x00000000004a455a in yy_reduce (yyruleno=112, yypParser=0x7f7ff7e30008) at ./src/sqlite3.c:110655 #16 sqlite3Parser (yyp=<optimized out>, yymajor=1, yyminor=..., pParse=<optimized out>) at ./src/sqlite3.c:46121#17 0x00000000004a6d6c in sqlite3RunParser (pParse=0x7f7ff7e03c08, zSql=<optimized out>, pzErrMsg=0x7f7fffffd7b0) at ./src/sqlite3.c:112494 #18 0x00000000004a8a58 in sqlite3Prepare (db=0x7f7ff7e03408, zSql=0x7f7ff7e0b300 "SELECT value FROM config WHERE name='allow-symlinks'", nBytes=-1, saveSqlFlag=1, pReprepare=0x0, ppStmt=0x7f7fffffd8d0, pzTail=0x0) at ./src/sqlite3.c:94233 #19 0x00000000004a8d2c in sqlite3LockAndPrepare (db=0x7f7ff7e03408, zSql=0x7f7ff7e0b300 "SELECT value FROM config WHERE name='allow-symlinks'", nBytes=-1, saveSqlFlag=1, pOld=0x0, ppStmt=0x7f7fffffd8d0, pzTail=0x0) at ./src/sqlite3.c:94325 #20 0x00000000004a8ec8 in sqlite3_prepare_v2 (db=<optimized out>, zSql=<optimized out>, nBytes=<optimized out>, ppStmt=<optimized out>, pzTail=<optimized out>) at ./src/sqlite3.c:94401 #21 0x00000000004113a5 in db_vprepare (pStmt=0x7f7fffffd8b0, errOk=0, zFormat=<optimized out>, ap=0x7f7fffffd8f0) at ./src/db.c:256 #22 0x0000000000411492 in db_text (zDefault=0x0, zSql=<optimized out>) at ./src/db.c:620 #23 0x00000000004123ac in db_get (zName=0x60553d "allow-symlinks", zDefault=0x6bb4bf "off") at ./src/db.c:1769 #24 0x0000000000412ab9 in db_get_boolean (zName=<optimized out>, dflt=0) at ./src/db.c:1860 #25 0x0000000000412b95 in db_open_repository (zDbName=0x7f7ff7e01060 "/tmp/100MB.fossil") at ./src/db.c:1006 #26 0x00000000004132d5 in cmd_open () at ./src/db.c:1963 #27 0x000000000042e90b in main (argc=<optimized out>, argv=<optimized out>) at ./src/main.c:561 (gdb) --- (note that sqlite analyze did work on the 1st attempt). Retrying on a P4 host with the same fossil version and an older one: --- michai@multi:/tmp/try$ uname -a NetBSD multi 5.1 NetBSD 5.1 (GENERIC) #0: Sun Nov 7 14:39:56 UTC 2010 bui...@b6.netbsd.org:/home/builds/ab/netbsd-5-1-RELEASE/i386/201011061943Z-obj/home/builds/ab/netbsd-5-1-RELEASE/src/sys/arch/i386/compile/GENERIC i386 michai@multi:/tmp/try$ /tmp/fossil ver This is fossil version 1.25 [baa1ebb7d9] 2013-01-07 18:58:30 UTC michai@multi:/tmp/try$ rm -rf * michai@multi:/tmp/try$ /tmp/fossil open ../100MB.fossil Segmentation fault (core dumped) michai@multi:/tmp/try$ f ver This is fossil version 1.22 [5dd5d39e7c] 2012-03-19 12:45:47 UTC michai@multi:/tmp/try$ rm -rf * michai@multi:/tmp/try$ f open ../100MB.fossil dir1/bigfile dir1/smallfile1 dir1/smallfile10 ... dir9/smallfile8 dir9/smallfile9 project-name: <unnamed> repository: /tmp/try/../100MB.fossil local-root: /tmp/try/ project-code: 2dd4d71f9110af7d28deb2f8bbbc88cd225a03cc checkout: 55dc6fd7396924aa38a79ec2477017d202b98a5e 2013-01-10 09:48:27 UTC parent: 1f8bdb74b8a12d879b3840b3db8469cf184bde0f 2013-01-10 09:47:28 UTC tags: trunk comment: 100 MB of random (user: michai) michai@multi:/tmp/try$ --- (i.e. the older version seems to work). I'm not sure if the 'new' fossil version used on host 'multi' reproduces the issue 100% - I *think* I saw it succeed once in opening the repo. Anyway... I'm not sure what to do now; I can isolate this further on request, or make the faulty repo available somewhere (what's the prefered way of doing this..?), or start a new thread here with this (new) issue, if it's indeed unrelated to the 'slow clone' thing. Or just file a bug report. Michai _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
