From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXug9-0005TH-4N for qemu-devel@nongnu.org; Fri, 04 Sep 2015 13:21:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXug4-0004xS-8S for qemu-devel@nongnu.org; Fri, 04 Sep 2015 13:21:33 -0400 Received: from 5751f4a1.skybroadband.com ([87.81.244.161]:62397 helo=dan.rpsys.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXug3-0004x2-Uk for qemu-devel@nongnu.org; Fri, 04 Sep 2015 13:21:28 -0400 Message-ID: <1441387258.24871.197.camel@linuxfoundation.org> From: Richard Purdie Date: Fri, 04 Sep 2015 18:20:58 +0100 In-Reply-To: <1441370585.24871.166.camel@linuxfoundation.org> References: <1441362357.24871.155.camel@linuxfoundation.org> <1441365880.24871.164.camel@linuxfoundation.org> <1441370585.24871.166.camel@linuxfoundation.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Segfault using qemu-system-arm in smc91c111 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel On Fri, 2015-09-04 at 13:43 +0100, Richard Purdie wrote: > On Fri, 2015-09-04 at 12:31 +0100, Peter Maydell wrote: > > On 4 September 2015 at 12:24, Richard Purdie > > wrote: > > > So just based on that, yes, seems that the rx_fifo looks to be > > > overrunning. I can add the asserts but I think it would just confirm > > > this. > > > > Yes, the point of adding assertions is to confirm a hypothesis. > > I've now confirmed that it does indeed trigger the assert in > smc91c111_receive(). I just tried an experiment where I put: if (s->rx_fifo_len >= NUM_PACKETS) return -1; into smc91c111_receive() and my reproducer stops reproducing the problem. I also noticed can_receive() could also have a check on buffer availability. Would one of these changes be the correct fix here? (Still working on a reproducer, ended up fixing the other test continuation issues so the failure is more obvious). Cheers, Richard