Am 04.03.2014 03:17, schrieb Øivind Loe:
On Mon, 03 Mar 2014 00:28:26 GMT, Etienne Cimon wrote:
On Sat, 01 Mar 2014 22:55:43 GMT, Øivind Loe wrote:
Thanks. That fixes it. There is still something strange though.. because my MongoDB connection dies unexpectedly at some point
./dboss-test(immutable(vibe.db.mongo.connection._MongoErrorDescription) vibe.db.mongo.connection.MongoConnection.getLastError(immutable(char)[])+0x6cf) [0x12ff097]I think you'd have more success looking at the MongoDB log file. I've only managed to get MongoDB 2.4 working, I think the connection gets closed because of an invalid command, I see this:
Bson[string] command_and_options = [ "getLastError": Bson(1.0) ];
and it looks like it should be
Bson[string] command_and_options = [ "getLastError": Bson(1) ];
according to the spec at http://docs.mongodb.org/manual/reference/command/getLastError/
There could be a few adjustments to do before 2.6 gets covered. I'm not sure what version you're using
For now, I reconnect to MongoDB every time I get an exception.. Keeps my program running. Nothing special in MongoDB log.. Keeps outputting this:
Mon Mar 3 20:08:47.037 [conn310] end connection 127.0.0.1:49979 (2 connections now open) Mon Mar 3 20:08:47.038 [initandlisten] connection accepted from 127.0.0.1:54743 #311 (3 connections now open) Mon Mar 3 20:08:48.916 [conn311] end connection 127.0.0.1:54743 (2 connections now open) Mon Mar 3 20:08:48.916 [initandlisten] connection accepted from 127.0.0.1:57121 #312 (3 connections now open) Mon Mar 3 20:08:49.974 [conn312] end connection 127.0.0.1:57121 (2 connections now open) Mon Mar 3 20:08:49.974 [initandlisten] connection accepted from 127.0.0.1:49872 #313 (3 connections now open)
Can you retry starting mongod with -v? It should list all commands and
their responses, maybe that gives a hint.
Found one more issue with the Timer now. I just noticed I get a seg-fault in the Timer destructor in vibed on GC collect:
Call-stack from GDB:
0 in vibe.core.core.Timer.__dtor() of /home/oivind/.dub/packages/vibe-d-master/source/vibe/core/core.d:555 1 in boss.proc.procio.ProcIO.__fieldDtor() of src/boss/proc/procio.d:39 2 in rt_finalize2 3 in gc.gc.Gcx.fullcollect() 4 in gc.gc.GC.mallocNoSync() 5 in gc.gc.GC.malloc() 6 in gc_qalloc 7 in _adDupT
Code it points at:
struct Timer { private { EventDriver m_driver; size_t m_id; debug uint m_magicNumber = 0x4d34f916; } private this(EventDriver driver, size_t id) { m_driver = driver; m_id = id; } this(this) { debug assert(m_magicNumber == 0x4d34f916); if (m_driver) m_driver.acquireTimer(m_id); } ~this() { debug assert(m_magicNumber == 0x4d34f916); if (m_driver) m_driver.releaseTimer(m_id); <------------ Here }
Locals:
(gdb) print m_driver $3 = (struct vibe.core.driver.EventDriver *) 0x7fffd3738db8 (gdb) print m_id $4 = 2 (gdb) print m_magicNumber $5 = 1295317270 (gdb) print this $6 = (struct vibe.core.core.Timer *) 0x7fffd372c8c0 (gdb)
Judging by the code, it doesn't really make sense to have a segfault at
that position - it could happen inside of releaseTimer
, but there are
no indirections in Timer.~this()
apart from the this
pointer itself.
Can you dump the assembly (and registers) around the crash, too?