When I use a unix utility from MinGW make, I get a StackDump file:
error:
sed -i -e 's/reveal.js\/css\/theme\/simple.css/reveal.js\/css\/theme\/moon.css/' index.html
0 [main] sed 8744 open_stackdumpfile: Dumping stack trace to sed.exe.stackdump
make: *** [index.html] Error 5
sed.exe.stackdump:
MSYS-1.0.12 Build:2012-07-05 14:56
Exception: STATUS_ACCESS_VIOLATION at eip=68008DAA
eax=03019001 ebx=60EA4124 ecx=00692788 edx=00000150 esi=00000000 edi=60EA00D4
ebp=0028FE9C esp=0028FE78 program=c:\Program Files (x86)\Git\bin\sed.exe
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
0028FE9C 68008DAA (60EA00D4, 00000150, 0028FEEC, 680044EA)
0028FEEC 6800466B (00000000, 00000000, 0028FF2C, 00517CF8)
0028FF0C 68004C5F (00401C28, 00000000, 5C952BA0, FFFFE001)
0028FF2C 68004C98 (00000000, 00000000, 928A67BF, FFFFF800)
0028FF5C 00517C08 (00401C28, FFFFE001, 00000001, 00000000)
0028FF8C 0040103D (7FFDE000, 0028FFDC, 771F0BBB, 7FFDE000)
0028FF98 74F6919F (7FFDE000, 99B8EAFE, 00000000, 00000000)
0028FFDC 771F0BBB (FFFFFFFF, 771DC9D0, 00000000, 00000000)
0028FFEC 771F0B91 (00401000, 7FFDE000, 00000000, 78746341)
End of stack trace
I get very similar errors when trying to use tools like rm, mv, and cp. What can I do to fix these errors? It is making developing on Windows impossible.
The make binary that I am using is located at C:\MinGW\msys\1.0\bin\make.exe, and the version information is:
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i686-pc-msys
I'm guessing your problem is the msysgit version of sed is using the version of the MSYS DLL in C:\MinGW\msys\1.0\bin instead of the DLL in c:\Program Files (x86)\Git\bin. Try changing your PATH so that your makefile uses the sed in C:\MinGW\msys\1.0\bin, rather than the msysgit version.
I discovered the problem. I was actually using the MSYS version of make, but the sed binary was the one that shipped with cmder. This mismatch was causing the stackdumps. I fixed the path, and now it is working fine.
Related
I'm trying to load the lx-symbols from the kernel. but it keeps showing me the following error:
(gdb) lx-symbols
loading vmlinux
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0xffffffff824fb470:
Error occurred in Python command: Cannot access memory at address 0xffffffff824fb470
Now I was successfully able to load the lx-symbols before from the same build(not sure if this is the correct terminology) but don't know why I can load it anymore.
Now, When I first connect to the remote machine via gdb it used to shows the build trace like the following:
GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./vmlinux...done.
(gdb) target remote: 1235
Remote debugging using : 1235
native_safe_halt ()
at /build/linux-hwe-22QmxS/linux-hwe-5.3.0/arch/x86/include/asm/irqflags.h:61
61 /build/linux-hwe-22QmxS/linux-hwe-5.3.0/arch/x86/include/asm/irqflags.h: No such file or directory.
Now when I connect to the remote kernel, it is showing me just this :
(gdb) target remote :1235
Remote debugging using :1235
0xffffffff81a98522 in __irqentry_text_end ()
I notice that the build trace /build/linux-hwe-22QmxS/linux-hwe-5.3.0/arch/x86/include/asm/irqflags.h:61
61 disappear (I did not make any changes to the configuration or setting).
This is the second time I'm facing the same problem. At the first time, I thought maybe i accidentally make some changes but as the problem occurs again, this time I'm quite sure I did not make any changes.
I have my .gdbinit file with the correct path.
add-auto-load-safe-path /../../ubuntu-bionic/debian/build/build-generic/vmlinux-gdb.py
I checked if the source is loading correctly by using the this:
(gdb) source /home/../../ubuntu-bionic/debian/build/build-generic/vmlinux-gdb.py
It didn't throw me any error. So, I guess the source is loading correctly. I just don't know what else to do. Please help.
Try to add to the kernel boot parameters "nokaslr" and/or build with CONFIG_RANDOMIZE_BASE=n
I am making an exe from an existing VB6 project. During Make, VB crashes with the following message
Visual Basic has stopped working
Problem Event Name: APPCRASH
Application Name: vb6.exe
Application Version: 6.0.97.82
Fault Module Name: ntdll.dll
Exception Code: c0000005
I am able to run the project from VB6 without any trouble. The problem occurs when I try to make the exe.
Please could you let me know what could be wrong?
Thanks!
This all needs to be done on the computer with the fault. I cannot load my ntdll.dll as it a different version and the addresses will be different to yours.
Download and install Debugging Tools for Windows
http://msdn.microsoft.com/en-us/windows/hardware/hh852363
Install the Windows SDK but just choose the debugging tools.
Create a folder called Symbols in C:\
This allows WinDbg to get the symbols for your version of ntdll.dll. Start Windbg. File menu - Symbol File Path and enter
srv*C:\symbols*http://msdl.microsoft.com/download/symbols
then
Open ntdll in WinDbg as a crashdump.
It will show the load address.
Type in WinDbg
ln <modloadaddress> + 7c911780
This will give you the nearest symbol to the crash. It probably isn't useful but lets see.
You can also run VB6 under WinDbg (make sure WinDbg is run as admin). When you crash do a stack trace.
Also do an !Analyze when you crash. It is meant for blue screens but will give info on appcrash.
Type in the WinDbg command prompt
!analyze -v
-v stands for Verbose and if the crash was originated by a program, as opposed to hardware or a driver, it will appear in the middle of the listing.
eg
PROCESS_NAME: java.exe
IMAGE_NAME: ntkrnlmp.exe
PROCESS_NAME only appears in the analyze -v output and only if a program originated the call that faulted.
WinDbg Commands
Open as Executable.
windbg -o -g -G c:\windows\system32\cmd.exe /k batfile.bat
You can press F12 to stop it and kb will show the call stack (g continues the program). If there's errors it will also stop and show them.
There is a breakpoint after loading but before any code is run. Press g to continue. Likewise there is a breakpoint after all code has run but before it is unloaded.
Type lm to list loaded modules, x *!* to list the symbols and bp symbolname to set a breakpoint
If programming in VB6 then this environmental variable link=/pdb:none stores the symbols in the dll rather than separate files. Make sure you compile the program with No Optimisations and tick the box for Create Symbolic Debug Info. Both on the Compile tab in the Project's Properties.
Sample output from a nearest symbol search.
Loading Dump File [C:\Windows\System32\ntdll.dll] Symbol search path
is: srvc:\symbolshttp://msdl.microsoft.com/download/symbols
Executable search path is: ModLoad: 4b280000 4b3f9000
C:\Windows\System32\ntdll.dll eax=00000000 ebx=00000000 ecx=00000000
edx=00000000 esi=00000000 edi=00000000 eip=4b280000 esp=00000000
ebp=00000000 iopl=0 nv up di pl nz na pe nc cs=0000 ss=0000
ds=0000 es=0000 fs=0000 gs=0000 efl=00000000
ntdll!__guard_fids_table (ntdll+0x0): 4b280000 4d
dec ebp 0:000> ln 4b280000 + 65534 (4b2e5520)
ntdll!RtlInitializeBitMap+0x14 | (4b2e5540)
ntdll!TpCallbackUnloadDllOnCompletion
Sample stack trace.
You follow what function called what functions. So you read it from the bottom up. It has the first 4 parameters that were passed to the function. You find the debugger starts additional threads so we need to find our program's one.
~
Lists all threads
~<threadid> e <command>
Do a KB on all threads until you find the main one.
0:004> ~0 e kb
ChildEBP RetAddr Args to Child 04bdfc30
75ae325a 04bdfc70 00000000 00000000 USER32!NtUserGetMessage+0xc
04bdfc4c 00895eb6 04bdfc70 00000000 00000000 USER32!GetMessageW+0x2a
04bdfc8c 008a5b41 00890000 00000000 04e2336f notepad!WinMain+0xe6
04bdfd20 74ad3744 7f229000 74ad3720 10fde46e
notepad!WinMainCRTStartup+0x151 04bdfd34 7755a064 7f229000 b0c1107f
00000000 KERNEL32!BaseThreadInitThunk+0x24 04bdfd7c 7755a02f ffffffff
7757d7c9 00000000 ntdll!__RtlUserThreadStart+0x2f 04bdfd8c 00000000
008a59f0 7f229000 00000000 ntdll!_RtlUserThreadStart+0x1b
Assume that 04bdfc70 is an HWnd. Which it is because the documentation says so. But assume it an address of a string. This displays what is there.
ds 775a1300
or to look at the values
db 775a1300
I just installed the most recent Git for Windows (https://git-scm.com/download/win) using the default installation settings. I have the 64 bit 2.10.0 version of Git running on Windows 10.
When I tried using Git Bash here, the console closes immediately and it produces a mintty.exe file with the following text:
Exception: STATUS_ACCESS_VIOLATION at rip=00100407559
rax=FFFFFFFFFFFFFFFF rbx=00000000FFFFC5D0 rcx=0000000000000000
rdx=03FFFFFFFFFFFFFF rsi=0000000100444E20 rdi=00000000FFFFC5CC
r8 =0000000000000001 r9 =0000000000000001 r10=0000000000000000
r11=8000000000000000 r12=0000000100445960 r13=00000000FFFFC5E0
r14=0000000600042F70 r15=0000000100445960
rbp=00000000FFFFC6C0 rsp=00000000FFFFC580
program=C:\Program Files\Git\usr\bin\mintty.exe, pid 6944, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
000FFFFC6C0 00100407559 (000FFFFC6C0, 7FFB0536FF20, 00100444DC8, 00600000001)
000FFFFC6C0 00100425455 (001801980AD, 00600041880, 001800CE622, 0000000002F)
000FFFFCCC0 00180047C0F (00000000000, 00000000000, 00000000000, 00000000000)
00000000000 0018004590C (00000000000, 00000000000, 00000000000, 00000000000)
000FFFFFFF0 001800459A4 (00000000000, 00000000000, 00000000000, 00000000000)
End of stack trace
I have tried searching for a solution but cannot find anything.
Try instead the portable edition:
PortableGit-2.10.0-64-bit.7z.exe
See if the a bash --login -i from this package works better than when it is installed.
vonc#gvonc MINGW64 /bin
$ git version
git version
git version 2.10.0.windows.1
$ bash --version
bash --version
GNU bash, version 4.3.46(2)-release (x86_64-pc-msys)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
If the issue persists, check your services: for instance, in issue 768, the Null service wasn't started.
Check its state:
sc query nul
Start it if needed:
sc start null
Resolved this by starting the Null service on my machine.
In GDB, I can call a function that is part of the executable I am debugging by issuing a command like call foo("123").
How do I do the same in OllyDbg (or possibly some other primarily Windows debugger)?
I don't know how to do it using OllyDbg but since you mention other Windows Debuggers you can use the .call command in WinDbg.
0:001> .call ABC!DoSomething(1,2)
Thread is set up for call, 'g' will execute.
WARNING: This can have serious side-effects,
including deadlocks and corruption of the debuggee.
0:001> r
eax=7ffde000 ebx=00000001 ecx=00000001 edx=00000003 esi=00000004 edi=00000005
eip=10250132 esp=00a7ffbc ebp=00a7fff4 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246
ABC!DoSomething:
10250132 55 push ebp
0:001> dd esp
00a7ffbc 00a7ffc8 00000001 00000002 ccfdebcc
The best explanation for it is from The Old New Thing.
In its default installation, Ollydbg can do this only for DLLs which have exports:
Debug > Call DLL export
For executables and DLLs without exports, you will have to build a plugin to do this.
here is what I'm trying to solve. I have a crash dump from Google Chrome.
I open windbg and say File -> Symbol File Path:
"SRV*c:\code\symbols*http://msdl.microsoft.com/download/symbols;SRV*c:\code\symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com"
I guess this looks for the debugging symbols from let to right and should finally grab them from google then. I copied that from http://www.chromium.org/developers/how-tos/debugging.
I drag and drop the crash dump into windbg
And then...
Microsoft (R) Windows Debugger Version 6.2.8400.0 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\cburgdorf\Desktop\Chrome-last.dmp]
User Mini Dump File: Only registers, stack and portions of memory are available
Symbol search path is: SRV*c:\code\symbols*http://msdl.microsoft.com/download/symbols;SRV*c:\code\symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com
Executable search path is:
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Wed May 16 16:25:24.000 2012 (UTC + 2:00)
System Uptime: not available
Process Uptime: 0 days 0:01:39.000
.........................................
This dump file has a breakpoint exception stored in it.
The stored exception information can be accessed via .ecxr.
eax=00000000 ebx=0038e1f8 ecx=00000001 edx=0012df58 esi=00000002 edi=0038e218
eip=776e013d esp=0038e1a8 ebp=0038e244 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00200246
ntdll!NtWaitForMultipleObjects+0x15:
776e013d 83c404 add esp,4
0:000> .excr
^ Syntax error in '.excr'
You see that it says "The stored exception information can be accessed via .ecxr" but once I insert that it tells me that I have a syntax error.
Does anyone know what I'm doing wrong?
You've got a typo, it's .ecxr :) In the meantime, another easy way to get information out of a crash dump without needing too much WinDbg-fu, is:
.symfix; .reload
!analyze -v
And if this is a .NET App (Chromium isn't but just for extra info), add these three lines
.loadby sos clr
!pe
~*e !clrstack