<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi,<div>The 'foo' is indeed a left-over debugging printout. I usually remove them before committing the files, but every once in a while one remains. I will replace it with a Logger call later today.</div><div>If you actually read the code for libcxx.py:</div><div><br></div><div><pre style="word-wrap: break-word; white-space: pre-wrap; "> def get_child_at_index(self,index):
logger = Logger.Logger()
if index < 0:
return None
if index >= self.num_children():
return None;
if self.garbage:
return None
try:
iterator = stdmap_iterator(self.root_node,max_count=self.num_children())
# the debug info for libc++ std::map is such that __begin_node_ has a very nice and useful type
# out of which we can grab the information we need - every other node has a less informative
# type which omits all value information and only contains housekeeping information for the RB tree
# hence, we need to know if we are at a node != 0, so that we can still get at the data
need_to_skip = (index > 0)
current = iterator.advance(index)
if current == None:
self.garbage = True
return None
if self.get_data_type():
if not(need_to_skip):
current = current.Dereference()
obj = current.GetChildMemberWithName('__value_')
obj_data = obj.GetData()
self.get_value_offset(current) # make sure we have a valid offset for the next items
# we do not return __value_ because then we would end up with a child named
# __value_ instead of [0]
return self.valobj.CreateValueFromData('[' + str(index) + ']',obj_data,self.data_type)
else:
# FIXME we need to have accessed item 0 before accessing any other item!
if self.skip_size == None:
return None
return current.CreateChildAtOffset('[' + str(index) + ']',self.skip_size,self.data_type)
else:
print "foo"
return None
except Exception as err:
print err
return None
</pre></div><div><br></div><div>"foo" is printed when self.get_data_type() does not work. On my side, the right thing to do is add a fair amount of logging to better diagnose this and similar scenarios.</div><div><br></div><div>On your side, there are several possibilities:</div><div>(a) wait for the logging to be in, and then repeat the test case and send the new log files</div><div>(b) send the a.out and associated dSYM and let's check if they look correct or the older compiler is doing something wrong with the debug info</div><div>(c) compile a new clang from TOT and retry using the updated compiler</div><div><br></div><div>Thanks,</div><div><div><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; "><i>Enrico Granata</i></div><div style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; ">✉ egranata@<font class="Apple-style-span" color="#ff230e"></font>.com</div><div>✆ (four oh eight) 862-7683</div><div><br></div></div></div></span></div></span></div></span></div></span></span></div></div><div><br></div><div><div><div>On Mar 30, 2012, at 2:54 AM, Filipe Cabecinhas wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi,<br><br>Attahced is the output of the test ran in verbose mode.<br>There's a very weird 'foo' that is shown after I enabled logging in the test (I enables verbose formatter logging right before the instruction that fails).<br><br>That print comes from stdmap_SynthProvider.get_child_at_index(), on line 546 of the Python/libcxx.py file. It seems like some kind of error, maybe you know what it's about (Something unfinished in that file?). <br><br><br> Filipe<br><br><br>On Thursday, March 29, 2012 at 6:31 PM, Enrico Granata wrote:<br><br><blockquote type="cite">Hi,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">a good first step is for you to run the test in verbose mode and attach the output.<br></blockquote><blockquote type="cite">You can also try to manually repeat the test case behavior and seeing what you get.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Moving from there should not be too complicated.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">As for tool versions, I am using a previous version of swig because of licensing issues. I also have a more recent clang based off LLVM 3.1 svn. I am not sure why that would be the case but given that the test case at fault here is related to libc++ I would guess that the build of libc++ has something to do with it. However, we are on the same OSX version.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Thanks.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Enrico Granata<br></blockquote><blockquote type="cite">✉ egranata@.com<br></blockquote><blockquote type="cite">✆ (four oh eight) 862-7683</blockquote></div></blockquote></div><br></div></body></html>