On 7/13/2022 5:14 PM, Abdlerhman Abotaleb wrote: > After through debugging > It appears that the problem happens at the following call: > Inside "CoherentXBar::recvTimingReq": > success = memSidePorts[mem_side_port_id]->*sendTimingReq*(pkt); > This "*sendTimingReq*" appears to cause Pkt modifications. > This function actually will end up calling *recvTimingReq *at the memory controller. > > I found an intersteing comment few lines before calling this function: > // store the original address as an address mapper could possibly > // modify the address upon a sendTimingRequest > const Addr addr(pkt->getAddr()); > > I still have no clue what is happening , but this converges the problem search if one can help. > Still, if I tried to "print" the packet (i.e. pkt->print()) anywhere on the path (or at least enable > CoherentXBar debug flag) , it will cause a segmentation fault!
I looked at that code, and while it indicates that the address can be changed via mapping, I don't think that would lead to a problem, though of course I could be wrong. What occurred to me was that, since you are queueing these things for later processing, maybe the place that allocated them expected a shorter lifetime, so part of the memory is getting freed and reused, which could cause all kinds of oddities. Among other things, this could happen if the Packet object is local to some function, rather than being allocated explicitly with new and later disposed of with an explicit delete. This thought also could be wrong, but might suggest a place to look. While it can be tricky to trigger on just the right thing in gdb, if the packet's address in memory, or the address being accessed, are repeatable, you can set a conditional breakpoint at the place where the packet is created, or other places along the path of its processing, and possibly find where things go off the rails. Regards - Eliot Moss > ---------------------------------------------------------------------------------------------------- > *From:* Abdlerhman Abotaleb <abota...@mcmaster.ca> > *Sent:* Wednesday, July 13, 2022 11:52 AM > *To:* Balazs Gerofi via gem5-users <gem5-users@gem5.org> > *Subject:* [gem5-users] Packet VALID_ADDR being cleared when try to resend it ! > Hi all > > What does it make a Packet's "VALID_ADDR" flag being cleared , even it was set before? > > 1. I'm sending some packets from the cache to unblocking memory object that I created > 2. Inside this unblocking memory object, I crated a queue to store packets that fail to be sent > 3. After a while , this memory object receives a packet that failed to be sent , so this packet is > blocked. > 4. Then, I'm inserting the packet to the queue of blocked requests. > 5. Inside the recvReqRetry I'm calling sendTimingReq(pkt). > 6. Eventually this packet is sent to CoherentXBar::recvTimingReq it fails there. > > The following assertion fails: > gem5.debug: build/RISCV/mem/packet.hh:832: bool gem5::Packet::isSecure() const:*Assertion > `flags.isSet(VALID_ADDR)' failed.* > Even If I tried to enable any packet debugging method (like calling pkt->print()) a segmentation > fault arises! > > I can find only that Packet's flags.clear() happens : > a. happens when constructing a new Packet from request, but even with that the "VALID_ADDR" is > being set if it has a PAddr. > (There are two constructors) > b. Another case , is for a third constructor that takes another packet as an argument, but > this constructor set the "VALID_ADDR" and "VALID_SIZE" to be the same as the packet being passed. > > I can't find anywhere that flags.clear(VALID_ADDR) happens. > So, what can be the problem cause? > > Thank you. > > regards, > Abdelrhman > > > > > > > > > > _______________________________________________ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org > _______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
