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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
