Fixed
Status Update
Comments
ap...@google.com <ap...@google.com> #2
download_sdk.py requires a python module called colorama which I don't have on my mac. Is there a recommended way to get it for naclports?
ap...@google.com <ap...@google.com> #3
gclient should install it during runhooks.
ap...@google.com <ap...@google.com> #4
Oh.. and run it with build_tools/python_wrapper to get those modules.
sg...@google.com <sg...@google.com>
ap...@google.com <ap...@google.com> #5
[Empty comment from Monorail migration]
ap...@google.com <ap...@google.com> #6
This bug seems to be a problem with the inliner. In this trace seems to be inlining ~basic_string into ~basic_stringstream; in my repro it's a the same verifier failure but with different functions. It looks like the inliner is failing to update (or create) the inlinedAt field in the MDLocation metadata. The verifier starts with the original MDSubprogram (first output line), finds the function it describes (second output, the function prototye) checks each instruction in that function (3rd output, the load instruction) and follows the chain from its !dbg attachment (4th-6th outputs) lead back to an MDSubprogram describing the same function. Here they don't match.
an...@google.com <an...@google.com> #7
Here's a bugpoint-reduced version of the testcase. bugpoint made the code pretty small but apparently it doesn't know how to remove debug info.
an...@google.com <an...@google.com> #8
So, this seems to happen when function A that has debug info (in the attached repro from #6 it's _ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEaSERKS5_) gets inlined into a function B (_ZNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEE3strERKNS_12basic_stringIcS2_S4_EE in the repro) which has no debug info, which is then in turn inlined into a function C (_ZN7testing7MessageC2Ev in the repro) which has debug info.
When the verifier visits the MDSubprogram entry for function B it finds the instruction originally from A, walks its debug info attachments and finds that it points to function A, and fails verification.
I'm not sure if it matters whether B is ultimately inlined into C or not. It does appear that a workaround is to generate debug info for B.
For glibc-compat this happens because the main program for the unit tests is built without debug info (it's built in one command without a separate link step). So as a workaround you could enable debug info for that. Usually everything has debug info or nothing does (this case can only happen with LTO) but clearly it should work, and it definitely seems to be an upstream bug.
When the verifier visits the MDSubprogram entry for function B it finds the instruction originally from A, walks its debug info attachments and finds that it points to function A, and fails verification.
I'm not sure if it matters whether B is ultimately inlined into C or not. It does appear that a workaround is to generate debug info for B.
For glibc-compat this happens because the main program for the unit tests is built without debug info (it's built in one command without a separate link step). So as a workaround you could enable debug info for that. Usually everything has debug info or nothing does (this case can only happen with LTO) but clearly it should work, and it definitely seems to be an upstream bug.
vi...@gmail.com <vi...@gmail.com> #9
I'm happy to put the workaround in naclports, as long we don't loose track of this. Might be worth a test case?
Description
Backporting of
android.os.Build.VERSION_CODES_FULL.BAKLAVA
used a value of 1.000.000.000 as that was the value present inandroid.jar
in the Baklava SDK revision 3. In revision 5 the value was changed to 3.600.000.The backporting should be updated to reflect the value which will most likely be the final value for the release.