Bug 389374 - MemoryErrorReport constructor may close TCF channel on virtual addresses translations
Summary: MemoryErrorReport constructor may close TCF channel on virtual addresses tran...
Status: NEW
Alias: None
Product: TCF
Classification: Tools
Component: Python (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-12 03:02 EDT by Frederic Leger CLA
Modified: 2012-09-14 04:35 EDT (History)
1 user (show)

See Also:


Attachments
Proposed patch (also converted to PEP8) (10.65 KB, patch)
2012-09-12 03:03 EDT, Frederic Leger CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Frederic Leger CLA 2012-09-12 03:02:19 EDT
Using a simics agent based on TCF, I got a "No translation for virtual address" error :

2012-09-12 08:30:42,627 : ---> C 164 Memory get "tracker0.ctx710" 140736507740133 4 4 2 
2012-09-12 08:30:42,632 : <--- R 164 None None "AAAAAA==" {"Code":1,"Time":1347431442627,"Format":"No translation for virtual address"} [{"addr":3314352101,"size":4,"stat":6,"msg":{"Code":1,"Time":1347431442627,"Format":"No translation for virtual address"}}] 

I guess that either the "addr" in the error message is wrong, either simics is trying to do a virtual/physical memory mapping, still I get a 'channel closed' because of the 

                assert r.offs >= 0
                assert r.size >= 0

Lines in the MemoryErrorReport constructor.

I do not think that the assert is needed. Either add something in the error message, or do nothing ... The patch attached just ignores the problem.
Comment 1 Frederic Leger CLA 2012-09-12 03:03:28 EDT
Created attachment 220959 [details]
Proposed patch (also converted to PEP8)
Comment 2 Anton Leherbauer CLA 2012-09-14 03:12:53 EDT
The same asserts exist also in the corresponding Java implementation, so I would rather not remove them just like that.  The asserts seem to test for obvious programming errors. E.g. the address reported in the error must not be lower than the address given in the command, which makes sense.
Comment 3 Frederic Leger CLA 2012-09-14 03:22:08 EDT
I agree that it makes sense, but having a disconnection because of an error message ?
Comment 4 Anton Leherbauer CLA 2012-09-14 03:40:38 EDT
TCF in general is pretty strict. Protocol errors like wrong number of arguments in commands or replies usually cause immediate disconnect.
On the other hand, in this case I think we can auto-correct the invalid address in the error report instead, i.e. assume the address given to the command.  I guess this is what a client would do anyway if no particular address can be associated with the failure.
Comment 5 Frederic Leger CLA 2012-09-14 04:35:36 EDT
By the way, I mentionned the problem to the Simics team ... so hopefully when the bug is fixed on their side, we should not have this error anymore, and the error message ma be fixed too (wen the error happens)