[Bug 215730] databases/kyototycoon: coredump when forking to write snapshot using in-memory hash db

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215730

            Bug ID: 215730
           Summary: databases/kyototycoon: coredump when forking to write
                    snapshot using in-memory hash db
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: sunpoet at FreeBSD.org
          Reporter: dch at skunkwerks.at
          Assignee: sunpoet at FreeBSD.org
             Flags: maintainer-feedback?(sunpoet at FreeBSD.org)

We're using replication to push in a bunch of records from a Debian system,
running via spiped tunnel, to the in-memory hash db. 

Each time KT forks to create the snapshot, it coredumps, & the snap is missing.

If a physical file backing db is used, snapshots are created as expected,
using: /var/db/kyototycoon/db.kch#opts=l#bnum=200000#ktcapsiz=512m
however the db format is also different so the performance is not equivalent.

```
sudo -u kyototycoon /usr/local/bin/ktserver -sid 2 -dmn -host 127.0.0.1 -port
1978 -li -log /var/log/kyototycoon/kyoto.log -bgs /var/db/kyototycoon/snapshots
-ulog /var/db/kyototycoon/updates -rts /var/db/kyototycoon/timestamp.rts -mhost
127.0.0.1  -bgsi 30 -bgsc zlib  -mport 11979 :#opts=l#bnum=200000#ktcapsiz=512m

tail -F /var/log/kyototycoon/kyoto.log

2017-01-03T13:27:26.840894Z: [SYSTEM]: ================ [START]: pid=89116
2017-01-03T13:27:26.841824Z: [SYSTEM]: opening the update log:
path=/var/db/kyototycoon/updates sid=2
2017-01-03T13:27:26.842787Z: [SYSTEM]: opening a database: path=:#bnum=200000#
2017-01-03T13:27:26.843594Z: [SYSTEM]: starting the server: expr=127.0.0.1:1978
2017-01-03T13:27:26.843765Z: [SYSTEM]: server socket opened:
expr=127.0.0.1:1978 timeout=30.0
2017-01-03T13:27:26.843856Z: [SYSTEM]: listening server socket started: fd=4
2017-01-03T13:27:27.386037Z: [SYSTEM]: replication started: host=127.0.0.1
port=11979 rts=0
...
2017-01-03T13:27:57.040883Z: [INFO]: snapshotting databases
2017-01-03T13:27:57.149034Z: [ERROR]: database error: 7: no record: no record

# 2017-01-03T13:28:17.341527Z: [SYSTEM]: server stopped
2017-01-03T13:28:17.341742Z: [SYSTEM]: finishing the server

# 2017-01-03T13:28:17.343796Z: [SYSTEM]: closing the server socket
2017-01-03T13:28:17.936916Z: [SYSTEM]: replication finished: host=127.0.0.1
port=11979
2017-01-03T13:28:17.937432Z: [SYSTEM]: snapshotting databases
2017-01-03T13:28:18.049065Z: [ERROR]: database error: 0: success: no error
2017-01-03T13:28:18.049227Z: [SYSTEM]: closing a database: path=:#bnum=200000#
2017-01-03T13:28:18.113054Z: [SYSTEM]: ================ [FINISH]: pid=89116
```


dtrace/dtruss shows the fork dying off, it is never seen again.


```
 27774/100285:  write(0x3, "2017-01-03T09:23:20.259852Z: [INFO]: snapshotting
databases\n\0", 0x3C)              = 60 0
 27774/100285:  sched_yield(0x0, 0x0, 0x0)               = 0 0
 27774/100285:  sched_yield(0x0, 0x0, 0x0)               = 0 0
 27774/100285:  sched_yield(0x0, 0x0, 0x0)               = 0 0
 27774/100285:  sched_yield(0x0, 0x0, 0x0)               = 0 0
 27774/100285:  sigprocmask(0x1, 0x8014CAB80, 0x802617EE8)               = 0x0
0
 27774/100285:  fork(0x0, 0x0, 0x0)              = 35497 0
 27774/100285:  fork()           = 35497 0
 35497/101532:  thr_self(0x802617E00, 0x0, 0x0)          = 0 0
 27774/100285:  sigprocmask(0x3, 0x802617EE8, 0x0)               = 0x0 0
 27774/100285:  sched_yield(0x0, 0x0, 0x0)               = 0 0
 27774/100285:  sched_yield(0x0, 0x0, 0x0)               = 0 0
 35497/101532:  sysarch(0x81, 0x7FFFDF5F8B58, 0x0)               = 0 0
 27774/100285:  wait4(0x8AA9, 0x7FFFDF5F8C5C, 0x1)               = 0 0
 35497/101532:  sigprocmask(0x3, 0x802617EE8, 0x0)               = 0x0 0
 35497/101532:  sigprocmask(0x3, 0x7FFFDF5F8BD0, 0x0)            = 0x0 0
 35497/101532:  thr_self(0x7FFFDF5F8BC0, 0x0, 0x0)               = 0 0
 35497/101532:  thr_kill(0x18C9C, 0x6, 0x0)              = 0 0
 27774/100280:  nanosleep(0x7FFFDFFFDF50, 0x7FFFDFFFDF40, 0x0)           = 0 0
 27774/100280:  sched_yield(0x0, 0x0, 0x0)               = 0 0
 ```

coredump & logfiles available on request with pgp or similar encryption.

-- 
You are receiving this mail because:
You are the assignee for the bug.