> On Sept. 21, 2015, 7:57 a.m., Andreas Hansson wrote: > > src/dev/x86/intdev.hh, line 153 > > <http://reviews.gem5.org/r/3117/diff/1/?file=49498#file49498line153> > > > > Seems dangerous to do this in a virtual method that looks like the > > whole point is to override it? > > > > Who is actually allocating the request and packet? > > Joel Hestness wrote: > The one that triggered the leak is X86ISA::I82094AA::signalInterrupt(). > I8259 looks like the only other device that descends from IntDevice, but it > uses signal lines rather than sending PIO packets to communicate. Neither > overload recvMessage. I could overload recvMessage in I82094AA and delete > packets there. Would probably also make sense to change the virtual > IntDevice::recvMessage to be a panic to force overloading. Thoughts?
I think that's a better option. That way the allocation and deletion are in the same place. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3117/#review7223 ----------------------------------------------------------- On Sept. 16, 2015, 6:07 p.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3117/ > ----------------------------------------------------------- > > (Updated Sept. 16, 2015, 6:07 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11094:bdbe55d7d4e0 > --------------------------- > arch, x86: Delete packet in IntDevice::recvResponse > > IntDevice::recvResponse is called from two places in current mainline: (1) the > short circuit path of X86ISA::IntDevice::IntMasterPort::sendMessage for atomic > mode, and (2) the full request->response path to and from the x86 interrupts > device (finally called from MessageMasterPort::recvTimingResp). In the former > case, the packet was deleted correctly, but in the latter case, the packet and > request leak. To fix the latter leak, move request and packet deletion into > IntDevice::recvResponse(). > > > Diffs > ----- > > src/dev/x86/intdev.hh 62e1504b9c64 > src/dev/x86/intdev.cc 62e1504b9c64 > > Diff: http://reviews.gem5.org/r/3117/diff/ > > > Testing > ------- > > Compiled gem5.debug with --without-tcmalloc. Ran x86 FS tests with Valgrind. > > > Thanks, > > Joel Hestness > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
