I try to understand a reported heap corruption on W7 (32 bits process on 64 os)
ON XP this link was usually enough to understand, but not on W7
I'm using:
Microsoft (R) Windows Debugger Version 6.2.9200.20512 X86
I have found corruption using
!heap –s –v
And tries to inspect the reported corrupted block.
I can’t understand what is wrong with the Blink->Flink.
Has anyone any ideas what is wrong, or where to look !
The entire freelist for this heap (found from !heap -a is circular, is that correct ?
0:000> !list -x "dd" -a "L2" -m 0n1000 9c6b7048
9c6b7048 06ca7008 9bf0d010
06ca7008 99491ef8 9c6b7048
<Cut Cut>
9c6b7048 06ca7008 9bf0d010
Updated:
I have checked in a test process where heap is reported OK, and yes the FreeList is circular, the last entry points to the start.
In the original dump, I have made a script to follow the FreeList and check for correct Blink, and they were all correct. This makes the reported corruption even more mysterious.
Do you all trust the !heap –s –v ??
Related
I am new to this, or better rusted (being 62).
Trying to develop on Beaglebone Black running Debian over IP using Eclipse Luna CDT and linaro tools.
I succeed in running and debugging standard helloworld.c.
Need to control GPIO fast (to connect to uncommon peripheral) but
all attempts to read or write to memory mapped registers fail.
Instruction
i = (*((volatile unsigned int *)(0x4804c130)))
which should read GPIO status register results in
Child terminated with signal = 0xb (SIGSEGV)
GDBserver exiting
logout
This is the source (hellobone.c) I compile without errors:
int main(void)
{
unsigned int i = 1;
i = (*((volatile unsigned int *)(0x4804c130))) ;
}
(I tried all variations on this pointer arithmetic)
Makefile trace: (ignore includes)
---COMPILE--- C:/hellobone/source/hellobone.c
"C:\gcc-linaro\bin\arm-linux-gnueabihf-gcc.exe" -c -o C:/hellobone/object/hellobone.o C:/hellobone/source/hellobone.c -marm -O0 -g -I. -IC:/hellobone/include
.
---LINK---
"C:\gcc-linaro\bin\arm-linux-gnueabihf-gcc.exe" -o hellobone C:/hellobone/object/hellobone.o C:/hellobone/object/tools.o C:/hellobone/object/gpio_v2.o -marm -O0 -g -I. -IC:/hellobone/include
.
The binary also crashes running as root from TTY:
root#beaglebone:~# ./hellobone
Segmentation fault
I installed Eclipse on the BBB Debian and read and write to memory works just fine. Just too slow compiling, and unstable, to be practical.
Reading memory should be doable. What am I doing wrong?
I suspect
GNU gdbserver (GDB) 7.4.1-debian
This gdbserver was configured as "arm-linux-gnueabihf"
But maybe I am missing something obvious, have not seen any post on this problem...
Really stuck. Being working on this for months now. Setting up toolchain very frustrating, nothing works as in YouTube videos..
Any help would be really appreciated
Marco
You need to mmap /dev/mem to access memory mapped peripherals through physical addresses. Easiest example / code I know does this goes by the name devmem2.
Thank you a lot, that certainly helped.
I compiled the program you gave me and it worked perfect in run mode in Eclipse, and in terminal on the remote machine.
Curiously, when running the Eclipse debugger, it crashes executing:
if((fd = open("/dev/mem", O_RDWR | O_SYNC)) == -1) FATAL;
I get this error message from gdbserver
Remote debugging from host 192.168.1.2
/root/hellobone: relocation error: /root/hellobone: symbol �pen, version GLIBC_2.4 not defined in file libc.so.6 with link time reference
Child exited with status 127
GDBserver exiting
Have been trying to use fopen but that gives a segmentation fault. Anyhow, I think that is a toolchain issue and not a programming issue.
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.
This call fails on Solaris with EACCES when ran as ordinary user:
sem_open(fileName.c_str(), O_CREAT, S_IRWXU | S_IRWXG | S_IRWXO, 1);
When process is started as root, it runs fine. Is this expected behavior?
Environment:
$ uname -a
SunOS solaris 5.11 11.0 i86pc i386 i86pc
$ g++ --version
g++ (GCC) 4.5.2
At the command line try:
prctl $$
These are the system enforced resource limits your process has. Note there are
process.max-sem-ops
process.max-sem-nsems
project.max-sem-ids
These are limits that have a number, if you do not see them (or the limits are already reached) then you have to add them to your account's profile with projadd or projmod to increase them if your project already exists.
If you cannot do this (no root access) consult with your sysadmin, s/he probably has some reason for not allowing semapahore access.
Note carefully:
sempahores are kernel persistent. If you ran your code a bunch of times the sempahores you created are likely still out there.
To see existing semaphores try ipcs -as
To remove lingering sempahores that your code should have removed use ipcrm