From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Jones Subject: Re: trinity cores in watchdog while syslog'ing Date: Wed, 6 Aug 2014 14:28:04 -0400 Message-ID: <20140806182804.GB4605@redhat.com> References: <53E270FB.8040900@gmx.de> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <53E270FB.8040900@gmx.de> Sender: trinity-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="iso-8859-1" To: Toralf =?iso-8859-1?Q?F=F6rster?= Cc: trinity@vger.kernel.org On Wed, Aug 06, 2014 at 08:16:27PM +0200, Toralf F=F6rster wrote: > Just FWIW : >=20 > Fuzzying a 32 bit Gentoo Linux let the trinity process in side the U= ML guest sometimes core dump with this back trace: >=20 > Core was generated by `trinity -C 4 -N 100000 -x mremap -q'. > Program terminated with signal 11, Segmentation fault. > #0 __GI__IO_fflush (fp=3D0x8154200) at iofflush.c:40 > 40 iofflush.c: No such file or directory. > (gdb) bt > #0 __GI__IO_fflush (fp=3D0x8154200) 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=3D8, argv=3D0xbfc8fd94) at trinity.c:13= 2 > (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