| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
This reverts r369684 (git commit cc62e38d258f414c196b566374c606e83a85a034)
Adding a declaration doesn't appear to be a sufficient fix.
llvm-svn: 369706
|
|
|
|
|
|
|
|
| |
The evaluation context isn't guaranteed to have this declaration.
Fixes "error: use of undeclared identifier 'malloc_get_all_zones'" bugs.
llvm-svn: 369684
|
|
|
|
| |
llvm-svn: 355566
|
|
|
|
| |
llvm-svn: 355562
|
|
|
|
|
|
|
| |
This revert the commit because it broke the bots. I need to find
a way that works with both versions.
llvm-svn: 355364
|
|
|
|
|
|
| |
Fixes three tests in the testsuite.
llvm-svn: 355359
|
|
|
|
|
|
| |
<rdar://problem/44432167>
llvm-svn: 349372
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the expression parser does name resolution for local
variables in C++ closures it doesn't give the local name
priority over other global symbols of the same name. heap.py
uses "info" which is a fairly common name, and so the commands
in it fail. This is a workaround, just use lldb_info not info.
<rdar://problem/34026140>
llvm-svn: 314959
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
|
|
|
|
|
|
|
|
|
|
| |
lldb::addr_t SBFrame::GetCFA();
This gets the CFA (call frame address) of the frame so it allows us to take an address that is on the stack and figure out which thread it comes from.
Also modified the heap.py module to be able to find out which variable in a frame's stack frame contains an address. This way when ptr_refs finds a match on the stack, it get then report which variable contains the pointer.
llvm-svn: 238393
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expr_options = lldb.SBExpressionOptions()
expr_options.SetPrefix('''
struct Foo {
int a;
int b;
int c;
}
'''
expr_result = frame.EvaluateExpression ("Foo foo = { 1, 2, 3}; foo", expr_options)
This fixed a current issue with ptr_refs, cstr_refs and malloc_info so that they can work. If expressions define their own types and then return expression results that use those types, those types get copied into the target's AST context so they persist and the expression results can be still printed and used in future expressions. Code was added to the expression parser to copy the context in which types are defined if they are used as the expression results. So in the case of types defined by expressions, they get defined in a lldb_expr function and that function and _all_ of its statements get copied. Many types of statements are not supported in this copy (array subscript, lambdas, etc) so this causes expressions to fail as they can't copy the result types. To work around this issue I have added code that allows expressions to specify an expression specific prefix. Then when you evaluate the expression you can pass the "expr_options" and have types that can be correctly copied out into the target. I added this as a way to work around an issue, but I also think it is nice to be allowed to specify an expression prefix that can be reused by many expressions, so this feature is very useful.
<rdar://problem/21130675>
llvm-svn: 238365
|
|
|
|
|
|
|
|
|
|
| |
with another language.
This ensures the expression gets runs with the correct language.
<rdar://problem/18816647>
llvm-svn: 226041
|
|
|
|
|
|
|
| |
- If there is only 1 frame ptr_refs now works (fixed issue with stack detection)
- Fixed test for result now that it isn't a pointer anymore
llvm-svn: 198712
|
|
|
|
|
|
|
|
| |
resolution of class_getSuperclass.
<rdar://problem/14662686>
llvm-svn: 188240
|
|
|
|
|
|
| |
ptr_refs command frequently doesn't work when run in large applicaton. This was due to the default timeout of 500ms. The timeouts have now been increased and all expression evaluations have been modified.
llvm-svn: 178628
|
|
|
|
|
|
| |
contain the fully qualified module name
llvm-svn: 175856
|
|
|
|
|
|
| |
A bit of cleanup in the heap module.
llvm-svn: 174129
|
|
|
|
|
|
|
|
| |
and __PAGEZERO are excluded.
Added many more cleanups to the output.
llvm-svn: 174045
|
|
|
|
|
|
|
|
|
|
| |
C++11 lambdas that don't capture anything can be used as static callback functions!
Heavily modified this python module to be able to not require a dylib in order to traverse the heap allocations.
Re-implemented the ptr_refs, objc_refs, malloc_info and cstr_refs to use complex expressions that use lambdas to do all static callback function work.
llvm-svn: 173989
|
|
|
|
|
|
| |
module can now search the vm regions with the --vm-regions options to any of the heap functions. This is currently slow and often will time out when run on a large program since our user expression timeout is set to 500000 usec. We need to add an API to LLDB where we can specify the timeout for an expression.
llvm-svn: 165437
|
|
|
|
|
|
| |
better output format
llvm-svn: 163675
|
|
|
|
|
|
| |
only objective C objects are supported since they are easy to detect.
llvm-svn: 163637
|
|
|
|
|
|
| |
a large ObjC program without running into expression timeouts. Now we get a full list of ObjC classes using a runtime function and then qsort the result. Also added code that can count all instances of each ObjC on the heap and also the total byte sizes for the object allocations.
llvm-svn: 163520
|
|
|
|
|
|
|
| |
superclasses on top of finding the exact class. The current attempt is still
too slow, but it lays the groundwork.
llvm-svn: 163135
|
|
|
|
|
|
|
|
| |
Fixed an issue where not all text would always be seen when running any of the functions in heap.py in Xcode. Now we put the text directly into the command result object and skip STDIO since we have issues with STDIO right now in python scripts.
Also fixed an issue with the "--stack-history" option where MallocStackLoggingNoCompact was assumed to have to be enabled... It doesn't, just MallocStackLogging.
llvm-svn: 163042
|
|
|
|
|
|
| |
heap that have the "isa" for the objective C class at offset zero. This will need to be improved to deal with KVO classes, but it is a start. It also disallows looking up a pointer value of zero since that would return way too many matches.
llvm-svn: 161724
|
|
|
|
| |
llvm-svn: 160083
|
|
|
|
|
|
| |
Modified the heap.py to be able to correctly indentify the exact ivar for the "ptr_refs" command no matter how deep the ivar is in a class hierarchy. Also fixed the ability for the heap command to symbolicate the stack backtrace when MallocStackLogging is set in the environment and the "--stack" option was specified.
llvm-svn: 159883
|
|
|
|
| |
llvm-svn: 159284
|
|
|
|
| |
llvm-svn: 156651
|
|
|
|
| |
llvm-svn: 156605
|
|
|
|
|
|
| |
in your app's environment.
llvm-svn: 156588
|
|
|
|
|
|
| |
work in progress. Checking this in so I can work on it some more.
llvm-svn: 156584
|
|
|
|
|
|
|
|
| |
reused between lldb invocations. Also add the module name into the directory path that is used to store the target triple specific build of libheap.dylib.
Also added code that will rebuild libheap.dylib if heap_find.cpp is newer that libheap.dylib.
llvm-svn: 155590
|
|
|
|
|
|
|
|
| |
doesn't print out all of the commands when executing the shell script.
Cleaned up the lldb.utils.symbolication, lldb.macosx.heap and lldb.macosx.crashlog. The lldb.macosx.heap can now build a dylib for the current triple into a temp directory and use it from there.
llvm-svn: 155577
|
|
|
|
|
|
| |
work with all of the new module paths.
llvm-svn: 155528
|
|
|
|
|
|
| |
or malloc_info are called. If MallocStackLogging is enabled, then you can now use --stack to dump the backtrace of the code that allocated each malloc block.
llvm-svn: 155262
|
|
|
|
|
|
| |
with a default format that makes sense, or that format can be overridden with the --format option.
llvm-svn: 154671
|
|
|
|
| |
llvm-svn: 154615
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(lldb) command script import heap.py
Find all malloc blocks that contains a pointer value of 0x1234000:
(lldb) ptr_refs 0x1234000
Find all malloc blocks that contain a C string:
(lldb) cstr_refs "hello"
Get info on a malloc block that starts at or contains 0x12340000
(lldb) malloc_info 0x12340000
llvm-svn: 154602
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
block. Using this on the lldb/test/lang/objc/foundation test we can see this in action:
First we can load the module:
(lldb) command script import /Volumes/work/gclayton/Documents/src/lldb/examples/darwin/heap_find/heap.py
Loading "/Volumes/work/gclayton/Documents/src/lldb/examples/darwin/heap_find/libheap.dylib"...ok
Image 0 loaded.
"heap_ptr_refs" and "heap_cstr_refs" commands have been installed, use the "--help" options on these commands for detailed help.
Lets take a look at the variable "my":
(lldb) fr var *my
(MyString) *my = {
MyBase = {
NSObject = {
isa = MyString
}
propertyMovesThings = 0
}
str = 0x0000000100301a60
date = 0x0000000100301e60
_desc_pauses = NO
}
We can see that this contains an ivar "str" which has a pointer value of "0x0000000100301a60". Lets search the heap for this pointer and see what we find:
(lldb) heap_ptr_refs 0x0000000100301a60
found pointer 0x0000000100301a60: block = 0x103800270, size = 384, offset = 168, type = 'void *'
found pointer 0x0000000100301a60: block = 0x100301cf0, size = 48, offset = 16, type = 'MyString *', ivar = 'str'
(MyString) *addr = {
MyBase = {
NSObject = {
isa = MyString
}
propertyMovesThings = 0
}
str = 0x0000000100301a60
date = 0x0000000100301e60
_desc_pauses = NO
}
found pointer 0x0000000100301a60: block = 0x100820000, size = 4096, offset = 96, type = (autorelease object pool)
found pointer 0x0000000100301a60: block = 0x100820000, size = 4096, offset = 104, type = (autorelease object pool)
Note that it used dynamic type info to find that it was in "MyString" at offset 16 and it also found the ivar "str"!
We can also look for C string values on the heap. Lets look for "a.out":
(lldb) heap_cstr_refs "a.out"
found cstr a.out: block = 0x10010ce00, size = 96, offset = 85, type = '__NSCFString *'
found cstr a.out: block = 0x100112d90, size = 80, offset = 68, type = 'void *'
found cstr a.out: block = 0x100114490, size = 96, offset = 85, type = '__NSCFString *'
found cstr a.out: block = 0x100114530, size = 112, offset = 97, type = '__NSCFString *'
found cstr a.out: block = 0x100114e40, size = 32, offset = 17, type = '__NSCFString *'
found cstr a.out: block = 0x100114fa0, size = 32, offset = 17, type = '__NSCFString *'
found cstr a.out: block = 0x100300780, size = 160, offset = 128, type = '__NSCFData *'
found cstr a.out: block = 0x100301a60, size = 112, offset = 97, type = '__NSCFString *'
found cstr a.out: block = 0x100821000, size = 4096, offset = 100, type = 'void *'
We see we have some objective C classes that contain this, so lets "po" all of the results by adding the --po option:
(lldb) heap_cstr_refs a.out --po
found cstr a.out: block = 0x10010ce00, size = 96, offset = 85, type = '__NSCFString *'
(__NSCFString *) 0x10010ce00 /Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/a.out
found cstr a.out: block = 0x100112d90, size = 80, offset = 68, type = 'void *'
found cstr a.out: block = 0x100114490, size = 96, offset = 85, type = '__NSCFString *'
(__NSCFString *) 0x100114490 /Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/a.out
found cstr a.out: block = 0x100114530, size = 112, offset = 97, type = '__NSCFString *'
(__NSCFString *) 0x100114530 Hello from '/Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/a.out'
found cstr a.out: block = 0x100114e40, size = 32, offset = 17, type = '__NSCFString *'
(__NSCFString *) 0x100114e40 a.out.dSYM
found cstr a.out: block = 0x100114fa0, size = 32, offset = 17, type = '__NSCFString *'
(__NSCFString *) 0x100114fa0 a.out
found cstr a.out: block = 0x100300780, size = 160, offset = 128, type = '__NSCFData *'
(__NSCFData *) 0x100300780 <48656c6c 6f206672 6f6d2027 2f566f6c 756d6573 2f776f72 6b2f6763 6c617974 6f6e2f44 6f63756d 656e7473 2f737263 2f6c6c64 622f7465 73742f6c 616e672f 6f626a63 2f666f75 6e646174 696f6e2f 612e6f75 742700>
found cstr a.out: block = 0x100301a60, size = 112, offset = 97, type = '__NSCFString *'
(__NSCFString *) 0x100301a60 Hello from '/Volumes/work/gclayton/Documents/src/lldb/test/lang/objc/foundation/a.out'
found cstr a.out: block = 0x100821000, size = 4096, offset = 100, type = 'void *'
llvm-svn: 154519
|
|
|
|
| |
llvm-svn: 154506
|
|
find values on the heap and print out the dynamic type of the malloc block that contains the data. I will be modifying this a bit more to tweak the output and make the output more useful.
llvm-svn: 154504
|