When i debug a programmer, I found too many lines useless info which appear in GDB. this kind of infomation may come from iphone framework. it is not logged by my code. the info like this
Node 48 TrialMT(102,102,101,101)
Node 58 TrialMT(102,102,101,101)
Node 69 TrialMT(102,102,101,101)
Node 72 TrialMT(102,102,101,101)
Just too much. so i can not find my log.
I want to known is there a way i can export GDB log to a file, so i can find my log info in the file later on.
thanks
In Xcode you can type GDB commands in the debugger console. There you can reset the stdout and stderr file descriptors to your preferred log file like this
(gdb) call (void)close(1)
(gdb) call (void)close(2)
(gdb) call (int)open("/tmp/out.log", 0x201, 0644)
$1 = 1
(gdb) call (int)dup(1)
$2 = 2
(gdb) continue
Related
I am looking a dump file collected from production environment for high cpu usage. I ran !threadpool and !runaway command as follows
0:000> !ThreadPool
CPU utilization: 100%
Worker Thread: Total: 6 Running: 2 Idle: 4 MaxLimit: 32767 MinLimit: 4
Work Request in Queue: 0
--------------------------------------
Number of Timers: 8
--------------------------------------
Completion Port Thread:Total: 8 Free: 3 MaxFree: 8 CurrentLimit: 8 MaxLimit: 1000 MinLimit: 4
0:000> !runaway
ERROR: !runaway: extension exception 0x80004002.
"Unable to get thread times - dumps may not have time information"
I want to know what threads are consuming most cpu time but I cannot run !runaway command. Are there any other commands in sos, sosex or any other extension that could be helpful in this case?
You need a tool that adds the necessary information to the dump.
In WinDbg, the .dump command has the /mt MiniOption, which
Adds additional thread information to the minidump. This includes thread times, which can be displayed by using the !runaway extension or the .ttime (Display Thread Times) command when debugging the minidump.
(Emphasis: links in WinDbg)
The t option is included in the a option as well, so .dump /ma is fine as well.
To find out whether or not your dump has that information, use the undocumented command .dumpdebug like this:
.shell -ci ".dumpdebug" findstr "MiniDump"
If there is a line
1000 MiniDumpWithThreadInfo
the information is contained and you have a different issue. If it's not there, the time info is not available.
Most other tools I know do not provide such detailed settings, so it's more or less luck, whether this info is included or not.
Today I wanted to write a crash dump and I got the error message
0:000> .dump /ma c:\classid_loads_net4.dmp
Creating c:\classid_loads_net4.dmp - mini user dump
GenInvokeEnumStackProviders(C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscordacwks.dll) failed, 0x8007007f
Dump successfully written
I googled for GenInvokeEnumStackProviders but there are no results at all.
What could the reason for this error message be and what impact could this have on the dump (which was successful according the last message)?
Using WinDbg 6.3.9600
Update 2014-09-18
Same error again today, reproducible at the moment. In Process Monitor I can see that WinDbg tries to access verifier.dll while writing the dump
C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x86\verifier.dll
However, the file does not exist in that place. From the list of loaded modules I see it is loaded from
0:008> lm fm verifier
start end module name
6ddf0000 6de50000 verifier C:\Windows\syswow64\verifier.dll
In addition (not sure it is related) I get errors dumping the .NET heap:
0:008> !dumpheap -stat
c0000005 Exception in C:\Windows\Microsoft.NET\Framework\v2.0.50727\sos.dumpheap debugger extension.
PC: 6b55dbe8 VA: 00000000 R/W: 0 Parameter: 00000000
Still using WinDbg 6.3.9600
The problem persists, even after a reboot and after disabling application verifier.
I'm attempting to debug a manual dump file of a 64bit w3wp process with 64bit Windbg (Version 6.10). The dump was taken with taskmgr. I can't get anything from the !clrstack command. Here is what I'm getting:
!loadby sos clr
!runaway
User Mode Time
Thread Time
17:cf4 0 days 5:37:42.455
~17s
ntdll!ZwDelayExecution+0xa:
00000000`776208fa c3 ret
!clrstack
GetFrameContext failed: 1
What is GetFrameContext failed: 1?
Use !dumpstack command instead of !clrstack. It usually works.
Try getting the "native" call stack by doing "k" and see what that gets you. Sometimes, the stack isn't quite right and the !ClrStack extension is pretty sensitive.
I tried traditional ways and answers to analyze my .DMP files. WinDbg doesn`t take it, it outputs:
Could not find the C:\program files\softwaredir\dumps\dumpname_0313.rsa.dmp
File, Win32 error 0n87
It's an Multi Theft Auto: San Andreas crash dump. .rsa.dmp
Why doesn`t WinDbg take it, does it have to do with a certain dump type?
If anyone would want to try opening, here is the dumpfile with the issue
I would like to know if you have the solution to solve the opening problem/or any other tool to open the dump.
But I really need the exception that caused the crash, so either I'll need advise on how to open it or if I can fix it.
For case 2 (can't solve it for me here) the crash memory locations are:
Version 1.3.5-release 6078.0.000
Time Tue Jan 21 03:13:18 2014
Module C:\Program Files (x86)\MTA San Andreas 1.3\mods\deathmatch\client.dll
Code 0 x C0000005
Offset 0 x 0009E796
EAX 00000000 EBX 30994AB0 ECX 21E82218 EDX 0028F71C ESI 3098E520
EDI 6FBBCCC9 EBP 0028F7BC ESP 0028F6F4 EIP 1B00E796 FLG 00210246
CS 0023 DS 002B SS 002B ES 002B FS 0053 GS 002B
This is what I did to generate and analyze a dump file:
Downloaded ProcDump (a free Sysinternals tool)
Created a folder c:\dumps
Added ProcDump to PATH
Entered procdump -ma -i c:\dumps into command prompt to start the JustInTime debugger
Opened the dump file in visual studio
Using this method we were able to resolve a difficult bug and determine what exception was causing my machine to crash.
What is the best way to debug MobileSubstrate extensions, i.e. placing breakpoints etc.? Is there away to do this in Xcode? GNU Debugger?
I use the syslog and tail. You'll need syslogd and Erica Utilities from Cydia. Then throughout your tweak place NSLog(#"breakpoint 1 - %#", someObject); and run the tweak.
tail -f /var/log/syslog
#define Debugger() { kill( getpid(), SIGINT ) ; }
Then you just call Debugger() wherever you want to place a breakpoint.
You can also raise an exception if you want to trace the stack:
[NSException raise:#"Exception Message" format:formatString];
Mobilesubstrate injects your dylib into the target process. Debugging the target process using GDB or LLDB is also debugging your extension code.
I will show you how to debug Mobilesubstrate extension using GDB.
Here is simple Mobilesubstrate/Logos extension:
%hook SBApplicationController
-(void)uninstallApplication:(id)application {
int i = 5;
i = i +7;
NSLog(#"Hey, we're hooking uninstallApplication: and number: %d", i);
%orig; // Call the original implementation of this method
return;
}
%end
I compile and install the code, and then attaching gdb to it:
yaron-shanis-iPhone:~ root# ps aux | grep -i springboard
mobile 396 1.6 4.3 423920 21988 ?? Ss 2:19AM 0:05.23 /System/Library/CoreServices/SpringBoard.app/SpringBoard
root 488 0.0 0.1 273024 364 s000 S+ 2:22AM 0:00.01 grep -i springboard
yaron-shanis-iPhone:~ root# gdb -p 488
You can find your Mobilesubstrate extension with the command:
(gdb) info sharedlibrary
This command print a list of loaded modules, find your extension:
test-debug-substrate.dylib - 0x172c000 dyld Y Y /Library/MobileSubstrate/DynamicLibraries/test-debug-substrate.dylib at 0x172c000 (offset 0x172c000)
You can also find the address of Logos uninstallApplication hook:
(gdb) info functions uninstallApplication
Which outputs this:
0x0172cef0 _logos_method$_ungrouped$SBApplicationController$uninstallApplication$(SBApplicationController*, objc_selector*, objc_object*)
You can debug your uninstallApplication hook function with breakpoints and other gdb features:
(gdb) b *0x0172cef0+36
Where the offset 36 is the assembly opcode that adding of 7 to the i variable in uninstallApplication hook function. You can continue to debug your Mobilesubstrate extension from here as you wish.