New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 711428 link

Starred by 0 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

lldb cannot properly translate qualified enum value if a intermediate nested class is private

Project Member Reported by rdsmith@chromium.org, Apr 13 2017

Issue description

To reproduce:
* Sync to Chromium commit 0877ce62e907e9a76083121c29ce4c7d31f2949f (p463777) and build net_unittests.  (I can't imagine the Chromium commit matters very much, except possibly for the line number for the breakpoint below.)

* Build lldb from tree tip.  The commits I used (via "git pull" today) were:
** llvm: d8dec6c86f982f17e9d06aff22f680e1fe3a8784
** clang: dbf1b8007c7d43ca8c802b277a75785f1c0ed3ae
** 449d2091fc0842092b317d3db3c72a2b6fbf1a6e

Log showing problems converting state value.  If these show multiple problems (or pilot error for some problems) please focus on the first failure, as what I'm trying to do is eventually create a function via expression -- \n <fndef> to convert from state values to strings for debug logging.

The problem may not actually be the private class, that was just my best guess when the top level refused to recognize 'Transacation' (which is defined in its own .h file, but its relationship with HttpCache is specified in the http_cache.h file via a "class Transaction" after the private: label).

rdsmith-macbookpro:../chrome/src [master]  $ lldb out/Default/net_unittests
lldb out/Default/net_unittests
(lldb) target create "out/Default/net_unittests"
Current executable set to 'out/Default/net_unittests' (x86_64).
(lldb) p net::HttpCache::Transaction::STATE_NONE
p net::HttpCache::Transaction::STATE_NONE
error: 'Transaction' is not a class, namespace, or enumeration
(lldb) break set -f http_cache_transaction.cc -l 710
break set -f http_cache_transaction.cc -l 710
Breakpoint 1: where = libnet.dylib`net::HttpCache::Transaction::DoLoop(int) + 570 at http_cache_transaction.cc:710, address = 0x0000000000637afa
(lldb) run --gtest_filter=HttpCache.RangeGET_NoStrongValidators
run --gtest_filter=HttpCache.RangeGET_NoStrongValidators
Process 26803 launched: '/Users/rdsmith/Sandboxen/chrome/src/out/Default/net_unittests' (x86_64)
Debugger detected, switching to single process mode.
Pass --test-launcher-debug-launcher to debug the launcher itself.
Detected presence of a debugger, running without test timeouts.
Note: Google Test filter = HttpCache.RangeGET_NoStrongValidators
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from HttpCache
[ RUN      ] HttpCache.RangeGET_NoStrongValidators
Process 26803 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00000001092dfafa libnet.dylib`net::HttpCache::Transaction::DoLoop(this=0x000000010e02ee00, result=0) at http_cache_transaction.cc:710
   707 	  int rv = result;
   708 	  do {
   709 	    State state = next_state_;
-> 710 	    next_state_ = STATE_UNSET;
    	                ^
   711 	    base::AutoReset<bool> scoped_in_do_loop(&in_do_loop_, true);
   712 	
   713 	    switch (state) {
(lldb) p net::HttpCache::Transaction::STATE_NONE
p net::HttpCache::Transaction::STATE_NONE
error: reference to 'HttpCache' is ambiguous
candidate found by name lookup is 'net::HttpCache'
candidate found by name lookup is 'net::HttpCache'
(lldb) p HttpCache::Transaction::STATE_NONE
p HttpCache::Transaction::STATE_NONE
error: 'Transaction' is not a class, namespace, or enumeration
error: reference to 'Transaction' is ambiguous
candidate found by name lookup is 'Transaction'
candidate found by name lookup is 'Transaction'
(lldb) p Transaction::STATE_NONE
p Transaction::STATE_NONE
error: reference to 'Transaction' is ambiguous
candidate found by name lookup is 'Transaction'
candidate found by name lookup is 'Transaction'
(lldb) p STATE_NONE
p STATE_NONE
(int) $0 = 1
(lldb) 

 

Comment 1 by egranata@google.com, Apr 13 2017

I am unfamiliar with the Chromium bug tracker UI, so it's possible the log is already attached and I am just not seeing it, but in my experience this kind of issue requires the expression log to investigate.

Do:

(lldb) log enable lldb expr -f /tmp/expr.log
(lldb) <reproduce the bug>

and attach /tmp/expr.log to the issue; it should contain *a lot* of useful information
Nope; I'm not familiar with the best ways to debug these problems :-}. expr.log from the initial problem shown above (without running any tests and breaking to change the evaluation context) attached.  Let me know if you want pointers to the relevant .h files.


expr.log
104 KB View Download

Comment 3 by egranata@google.com, Apr 13 2017

What is the policy with sharing this information outside of Google?

Even when I worked at Apple, I was not the resident expert in the LLDB expression parser (the guy that kicks in when you "p" something)

I know a few people still in DevTools over there, but my suggested course of action would be to forward this issue to the LLDB bugzilla (http://bugs.llvm.org/) with expression log and as much other info as you can reasonably provide.

Also, IIRC, the ambiguous reference problem you're seeing is a somewhat known issue - as in, it popped up every so often in tricky C++ codebases, but we never had the time to sit down and squash it once and for all.
This bug is public, and chromium's an open source project; we can share whatever's useful.  

The reason I didn't go with filing a bug on that bug tracker in the first place is that I think of those folks as (not unreasonably) wanting a repro case that is boiled down from the large mess that is the CPP output of compiling a chromium file, and I think that would take me a lot longer to do than creating a repro based on Chrome code.  And it being a somewhat known issue makes me have even less enthusiasm for the process of filing a bug @ llvm.org, since it sounds like a reasonably likely result is "Yeah, we know--patches welcome" :-J.

But if you think it's possible to get some traction with the amount of information I can provide without spending too much time creating a minimal repro, I'm happy to give it a try.
I filed an upstream bug with a reduced test case as http://bugs.llvm.org/show_bug.cgi?id=32702
Thank you both!

Sign in to add a comment