On Wed, Aug 06, 2014 at 08:16:27PM +0200, Toralf Förster wrote: > Just FWIW : > > Fuzzying a 32 bit Gentoo Linux let the trinity process in side the UML guest sometimes core dump with this back trace: > > Core was generated by `trinity -C 4 -N 100000 -x mremap -q'. > Program terminated with signal 11, Segmentation fault. > #0 __GI__IO_fflush (fp=0x8154200) at iofflush.c:40 > 40 iofflush.c: No such file or directory. > (gdb) bt > #0 __GI__IO_fflush (fp=0x8154200) at iofflush.c:40 > #1 0x080582c3 in synclogs () at log.c:163 > #2 0x0805e93d in watchdog () at watchdog.c:363 > #3 init_watchdog () at watchdog.c:430 > #4 0x080538d9 in main (argc=8, argv=0xbfc8fd94) at trinity.c:132 > (gdb) quit ugh, when I switched the log file creation to happen from within the child, I forgot to take care of this function. I'm surprised it's taken this long for anyone to notice, as it can't possibly work. I think I'm just going to tear that whole thing out, as syncing from watchdog context just isn't going to be possible. 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
