On Thu, Jun 13, 2013 at 10:41:30PM +0300, Tommi Rantala wrote: > Latest trinity from git is constantly complaining: weird. > [32492] Random reseed: 3901037224 > msgrcv (70) returned ENOSYS, marking as inactive. > msgrcv (70) returned ENOSYS, marking as inactive. > msgrcv (70) returned ENOSYS, marking as inactive. > msgrcv (70) returned ENOSYS, marking as inactive. > msgrcv (70) returned ENOSYS, marking as inactive. > msgrcv (70) returned ENOSYS, marking as inactive. > msgrcv (70) returned ENOSYS, marking as inactive. > msgrcv (70) returned ENOSYS, marking as inactive. > msgrcv (70) returned ENOSYS, marking as inactive. > msgrcv (70) returned ENOSYS, marking as inactive. > msgrcv (70) returned ENOSYS, marking as inactive. > [watchdog] 200253 iterations. [F:161784 S:38468] > msgrcv (70) returned ENOSYS, marking as inactive. > msgrcv (70) returned ENOSYS, marking as inactive. > msgrcv (70) returned ENOSYS, marking as inactive. > msgrcv (70) returned ENOSYS, marking as inactive. > msgrcv (70) returned ENOSYS, marking as inactive. > msgrcv (70) returned ENOSYS, marking as inactive. > msgrcv (70) returned ENOSYS, marking as inactive. puzzling. this should (obviously) only occur once. Maybe it's happening once per thread at the same time, so they're all racing. (I should add some locking around the modifications of the syscall table I suppose). > trinity: malloc.c:3616: _int_malloc: Assertion `(unsigned long)(size) > >= (unsigned long)(nb)' failed. This is trinity corrupting itself. Seen this occasionally for a while now, but haven't had time to track it down. Need to spend some time with scripts/test-all-sequentially.sh to figure out a) which syscall is causing it, and b) what memory it's scribbling over. > I collected bunch of cores with -D and see this a lot, related perhaps: > > Core was generated by `./trinity -q -l off -C40 -D'. > Program terminated with signal 11, Segmentation fault. > #0 mkcall (childno=childno@entry=1) at syscall.c:292 > 292 syscalls_32bit[call32].entry->flags &= ~ACTIVE; > #0 mkcall (childno=childno@entry=1) at syscall.c:292 > #1 0x0000000000407e8c in do_random_syscalls (childno=childno@entry=1) > at random-syscalls.c:125 Can you see what syscalls_32bit, and call32 are at that point ? Also a backtrace might be useful. Is it always the 32bit path ? Dave -- To unsubscribe from this list: send the line "unsubscribe trinity" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
