Exception raised when accessing private values

[suever]

From bob94...@gmail.com on August 27, 2010 15:04:25

What steps will reproduce the problem? 1. load a dicom fle from a GE MR750 scanner

2. Access any private field. E.g:

   ds[0x0019,0x10e0].value

RuntimeError Traceback (most recent call last)

in () /usr/lib/python2.6/site-packages/dicom/dataset.pyc in **getitem**(self, key) 253 data_elem = read_deferred_data_element(self.filename, self.timestamp, data_elem) 254 # Hasn't been converted from raw form read from file yet, so do so now: --> 255 self[tag] = DataElement_from_raw(data_elem) 256 return dict.**getitem**(self, tag) 257 /usr/lib/python2.6/site-packages/dicom/dataset.pyc in **setitem**(self, key, value) 485 private_creator_tag = Tag(tag.group, private_block) 486 if private_creator_tag in self: --> 487 data_element.private_creator = self[private_creator_tag].value 488 dict.**setitem**(self, tag, data_element) [SNIP REPEATING ERRORS] /usr/lib/python2.6/site-packages/dicom/dataset.pyc in **getitem**(self, key) 253 data_elem = read_deferred_data_element(self.filename, self.timestamp, data_elem) 254 # Hasn't been converted from raw form read from file yet, so do so now: --> 255 self[tag] = DataElement_from_raw(data_elem) 256 return dict.**getitem**(self, tag) 257 /usr/lib/python2.6/site-packages/dicom/dataset.pyc in **setitem**(self, key, value) 484 private_block = tag.elem >> 8 485 private_creator_tag = Tag(tag.group, private_block) --> 486 if private_creator_tag in self: 487 data_element.private_creator = self[private_creator_tag].value 488 dict.**setitem**(self, tag, data_element) /usr/lib/python2.6/site-packages/dicom/dataset.pyc in **contains**(self, name) 118 return False 119 if tag: --> 120 return dict.**contains**(self, tag) 121 else: 122 return dict.**contains**(self, name) # will no doubt raise an exception RuntimeError: maximum recursion depth exceeded 1. Named fields work fine: ds[0x0010,0x0010].value 2. Matlab's dicom parser works fine on these files. 3. Loading the files into Matlab and then saving them back out solves the problem. (As does any anonymizing that I've tried.) What is the expected output? What do you see instead? Accessing any private fields raises exceptions. What version of the product are you using? 0.9.4-1 Note that I can't attach the problematic files because they contain identifying information and anonymizing the files fixes the problem. _Original issue: http://code.google.com/p/pydicom/issues/detail?id=90_

[suever]

From darcymason@gmail.com on September 01, 2010 05:41:26

I'm not sure where to go with this ... hard to figure out without some more information. Since it goes away when rewritten (by matlab or by anonymizing) there must be something different about the way the file is originally stored.

Could you perhaps use pydicom's hex dump or turn on pydicom's debug mode, both explained on the Troubleshooting wiki page [1], and then capture part of the text around the start of the private data section, and "anonymize" by simply replacing values -- both hex bytes and text -- that include confidential information, with 00's (bytes) or "-" (text). That would show the structure of how the information is stored without exposing any confidential info. And I might be able to create from that a file which could reproduce the failure. If you want you could send directly to me (my full name, no punctuation, at gmail.com).

Thanks Darcy

[1] https://code.google.com/p/pydicom/wiki/Troubleshooting

Status: Accepted

[suever]

From med.diag...@gmail.com on September 07, 2010 05:21:58

I debugged this issue and found that the calls keep going back and forth between getitem and setitem for setting the private creator code. The code goes into infinite recursion once the private_block becomes 0 (line 484 above)

For the tag (0x09,0x10e0) for e.g. code goes to set (0x09,0x10) and in the next loop goes to (0x09,0x00) and then keeps looping with this tag.

A simple return after a check if private_block == 0 seems to fix this issue. May be there is a better fix.

I tried modifying existing test files to reproduce the problem but have not succeeded. I think any data set with private attributes (including creator code and group lengths for the private group) should help to reproduce the issue.

[suever]

From darcymason@gmail.com on September 08, 2010 18:08:22

After revisiting this I'm thinking it is likely the same problem that was fixed in revision f54d9aa6b3 . When I first checked it I somehow convinced myself it wasn't, but looking again the fix for the if statement in dataset.py -- "and tag != private_creator_tag:" does not appear in the error trace (at line 486) copied above.

Would you be able to update to that revision (or later) and check if that solves your problem? Alternatively, you could just add the the extra conditional just quoted and see if that works.

[suever]

From darcymason@gmail.com on December 18, 2011 08:42:19

Closing issue as resolved. As in previous comment, I believe the issue was resolved in revision f54d9aa6b3 .

Status: Verified