Am 06.10.2014 23:09, schrieb flamencofantasy:
warning: exec file is newer than core file.
[New Thread 31660]
[New Thread 31659]
[New Thread 31661]
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Core was generated by `./mq'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000007d0c98 in vibe.data.bson.BsonSerializer.endWriteDictionary!(CMD).endWriteDictionary (this=0x6852bf)at ../../../root/.dub/packages/vibe-d-0.7.21-rc.2/source/vibe/data/bson.d:13751375 mdst.data[sh .. sh + 4] = toBsonData(cast(uint)(mdst.data.length - sh))[];
Assuming that the above is still accurate (the warning at the top could
indicate that the location below is wrong), this would definitely
indicate a bug in the BSON serialization code. I'll review that part of
the code to see if there is anything suspicious.
Hello again,
The previous post was from a core dump.
I was able to follow your instructions and here is the stack trace;
Program received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0x7fff96ebf700 (LWP 29303)]
vibe.core.drivers.libevent2.levlockmutex (mode=0, lock=0x0)at ../../../root/.dub/packages/vibe-d-0.7.21-rc.2/source/vibe/core/drivers/libevent2.d:12871287 int levlockmutex(uint mode, void* lock)
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.132.el65.4.x8664 keyutils-libs-1.4-4.el6.x8664 krb5-libs-1.10.3-15.el65.1.x8664 libcomerr-1.41.12-18.el65.1.x8664 libselinux-2.0.94-5.3.el64.1.x8664 openssl-1.0.1e-16.el65.15.x8664 zlib-1.2.3-29.el6.x8664
(gdb) bt
#0 vibe.core.drivers.libevent2.levlock_mutex (mode=0, lock=0x0)at ../../../root/.dub/packages/vibe-d-0.7.21-rc.2/source/vibe/core/drivers/libevent2.d:1287
This looks like this is just a false alarm (SIGUSR1, AFAIK, is used by
the garbage collector to interrupt all threads during a collection). I
don't have the exact command at hand, but you can disable breaking on
SIGUSR1 and SIGUSR2 within GDB to ignore those.
My service is basically a queue where messages (arrays of bytes) can be stored and retrieved using POST and GET requests. I will shorten my code and post it here if that would be helpful.
A reproduction case would definitely be most helpful, especially for
debugging the segfault above, as it may prove necessary to inspect the
memory to find the root cause.