Re: [Gems-users] cacheAvail assertions

["Liqun Cheng" <liqun.cheng@xxxxxxxxx>]

Dave,

I assume you are debugging your own protocol, the released ones are quite stable. I have met similar problems several times when debugging my home-brew protocols. What I normally do is hooking tester.exec with gdb, so you can have the calling stack at the failure points. Then based on the c codes, you can figure out what transition/action in sm file causes the problem. 

just my 2 cents
Liqun

On 4/3/07, Dave Z. <zhu_dave@xxxxxxxxx> wrote:

Hello,

My simulations stop due to the following assertions after running for several hours:

- cacheAvail in CacheMemory allocate (line 428)
- !cacheAvail in CacheMemory cacheProbe (line 461)

This means that I'm trying to allocate a new block when there is no space in cache and I'm probing cache when there is already space in cache, right?

I get these assertions when my simulations have run for several hours. The L1 and L2 caches are already full by then, in other words L1_to_L2 and L2_replacement events have already taken place several times. In addition, the assertions fail during a different time step every time. So, I cannot use the debug trace, as the file exceeds the maximum size.

I follow the same idea in mandatoryQueue's data access, but still get the assertions above. Is there any reason you could think of why I would get such assertions? Any comments will be greatly appreciated.

Thank you,

Dave





____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site: https://lists.cs.wisc.edu/archive/gems-users/" to your search.