----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3117/#review7223 -----------------------------------------------------------
src/dev/x86/intdev.hh (line 153) <http://reviews.gem5.org/r/3117/#comment6142> 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? - Andreas Hansson 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
