This question already has an answer here:
How are data breakpoints created?
(1 answer)
Closed 1 year ago.
Requirements:
I need to generate an interrupt, when a memory location changes or is written to. From an ISR, I can trigger a blue screen which gives me a nice stack trace with method names.
Approaches:
Testing the value in the timer ISR. Obviously this doesn't give satisfying results.
I discovered the bochs virtual machine. It has a basic builtin debugger that can set data breakpoints and stop the program. But I can't seem to generate an interrupt at that point.
bochs allows one to connect a gdb to it. I haven't been able to build it with gdb support though.
Other thoughts:
A kind of "preview instruction" interrupt that triggers for every instruction before executing it. The set of used memory-writing instructions should be pretty manageable, but it would still be a PITA to extract the adress I think. And I think there is no such interrupt.
A kind of "preview memory access" interrupt. Again, I don't think its there.
Abuse paging. Mark the page of interest as not present and test the address in the page fault handler. One would still have to distinguish read and write operations and I think, the page fault handler doesn't get to know the exact address, just the page number.
See chapter 16 in Intel's Software Developer's Manual Volume 3A. It gives information about using the debug registers, which provide support for causing the debugger exception when accessing a certain address, among other things. The interrupt will be triggered after the instruction which caused it. Specifically, you will have to set one of dr0-dr3 to the address you want to watch, and dr7 with the proper values to tell the processor what types of accesses should cause the interrupt.
Related
I am working on a Delphi application using the TService functionalities.
It is a large project that was started by someone else.
The application uses several separate threads for processing, communicating with clients, database access, etc. The application’s main job is to poll regularly (every 2-300ms) certain devices and, a couple times a day, execute specific actions.
Now somewhere there is an unhandled exception for which I cannot seem to find the cause:
According to the debugger, the faulting method is System.Classes.StdWndProc.
This also seems to be confirmed by analyzing the crash dump file with WinDbg.
After numerous tests and debugging, I noticed that the crash happened on my dev computer every day at almost the same time.
I looked at the windows log and found this event:
This, coupled with the fact that the stack trace from Delphi indicates that a message with ID=26 (WM_WININICHANGE) was processed, made me believe that there might be something wrong with my usage of FormatDateTime() or DateTimeToStr() when regional settings are reloaded.
I checked every call and made sure to be using the thread-safe overload with a local instance of TFormatSettings.
However today the service crashed again.
A few points that I think are worth mentioning:
The application is also installed on a Windows 2008 server and has
been running OK for over a month.
On 2012r2 I tried forcing DEP off, but it didn’t change anything.
The service’s OnExecute() method is not implemented. I create a base thread in TService. ServiceStart() which then in turn creates the main data module and all the other threads.
The service is not marked as interactive and is executed with the Local System account.
All data modules are created with AOwner=nil.
With a special parameter, the application can be started a normal windowed application with a main form (which is created only in this case). The exception does not seem to happen when running in GUI mode.
Almost all threads have a message pump and use PostThreadMessage() to exchange information. There are no window handle allocations anywhere.
I have checked the whole project and there are no timers or message dialogs or other graphical components anywhere.
I have activated range as well as overflow checking and found no issues.
I am a loss for what to do here. I have checked and re-checked the code several times without finding anything that could explain the error.
Looking online I found several reports that seem to be pertinent to my situation, but none that actually explains what is going on:
https://answers.microsoft.com/en-us/windows/forum/windows_10-other_settings/windows-10-group-policy-application-hang/72016ea4-ba89-4770-b1de-6ddf14b0a51f
https://www.experts-exchange.com/questions/20720591/Prevent-regional-settings-from-changing-inside-a-TService-class.html
https://forums.embarcadero.com/thread.jspa?messageID=832265
Before taking everything apart I would like to know if anyone experienced anything similar or has any tips.
Thanks
Edit: looking at the call stack and the first method executed I am thinking of the TApplication instance that is used in TService.
LPARAM is always 648680.
LPARAM is a pointer to a string (you can cast it to PChar).
You could try to catch WM_SETTINGS_CHANGE and log anytime it's processing.
I think you could use TApplicationEvents component. The component has OnSettingsChange event. The event provides a setting area name (section name) and a flag that points to changed parameter.
Have a look at doc-wiki.
There is a full list of possible parameters.
I did not test it, but maybe you can use Abort procedure in OnSettingsChange event handler to stop the message distribution. Of course it's not a solution, but it may work.
I using freertos on my project. My code is stuck in hardfault handler, I want know last executed function address or last executed line address for debugging.How to debug code when PC is pointing Hardfault handler.
That information is 100% dependent on which microcontroller you are using, and also which tool chain you are using as some IDEs will do this for you. You failed to provide either piece of information, so are asking people to guess on your behalf. A good question is one that cannot only possibly be answered by another question.
I am going to guess you are using a Cortex-M microcontroller, in which case information on debugging a hard fault can be found on lots of links found by Google, including the following: http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
I have an iOS app that does alot of low-level socket work, and recently after adding IPv6 support I noticed there is a kernel panic which occurs sometimes when running my app. The entire device reboots, and I get a panic file which has alot of cryptic information (including no stack frames from my app), but a few critical things as shown here:
panic(cpu 0 caller 0xffffff800f15fba0): assertion failed: se->se_flags & SEF_ATTACHED, file: /SourceCache/xnu/xnu-2784.30.7/bsd/kern/uipc_socket.c, line: 6228
Debugger message: panic
Fortunately this module is open source, and I found the code for a close version here: http://opensource.apple.com//source/xnu/xnu-2782.1.97/bsd/kern/uipc_socket.c
The error seems to match up with this function:
void
sockaddrlist_remove(struct sockaddr_list *sl, struct sockaddr_entry *se)
{
VERIFY(se->se_flags & SEF_ATTACHED);
se->se_flags &= ~SEF_ATTACHED;
VERIFY(sl->sl_cnt != 0);
sl->sl_cnt--;
TAILQ_REMOVE(&sl->sl_head, se, se_link);
}
I'm pretty sure the first VERIFY(), which is basically an assert, is failing.
However, this just tells me that some memory was probably corrupted by my program some time before this code got to run. So, like most memory corruptions, it is very challenging to find the cause.
Based on my logging, I see this happen after roughly some networking calls, including socket(), connect(), read() and write(), though it wouldn't be feasible to give the code here.
Another piece of information is this only happens with IPv6. On IPv4, everything works without issue. But I have scrubbed the IPv6 code and have not found anything obviously wrong. Also I'm confused how any memory corruption issue in user space would make the kernel fail. Maybe understanding how this could happen would help me trace the issue.
The next step most people would say is to try the guard malloc, however unfortunately when I try to turn that on I run into another problem, so for now lets just make the assumption that I cannot use guard malloc at present.
I have also tried to attach to the program live while running and make it crash, but it doesn't stop in the debugger anywhere, it just reboots the entire device (iPad).
If anyone has any triaging ideas for this tricky bug, please let me know.
EDIT:
Based on the feedback from one of the answers, I've checked all the lengths for the relevant socket API calls and those seem to be correct. So it seems like there is some other issue here, possibly overwriting memory.
I was able to try using "Malloc Guard Edges", but then the problem stops happening. I can't use "Guard Malloc" since it will only work on the simulator, and my app doesn't run well on the simulator due to how it interacts with the hardware.
If anyone has any more ideas, please let me know.
I have seen this happen (improperly coded IPv6 changes in iOS app causing the entire phone to reboot).
In my case, it was caused by making the system call sendto() with the wrong dest_len, one that didn't match the size of the structure pointed to by dest_addr. This kind of issue is possible to come up when adding support for IPv6 because, when everything was IPv4, all sockaddr structures are sockaddr_in, with the same size which can be hard-coded, but when you can have IPv4 and IPv6 addresses, you can have different-sized structures, and you have to pass the correct length corresponding to the structure passed. Your particular issue might not be exactly in sendto(), but it might be a similar issue so I would check every system call where you need to pass a socklen_t, including bind() and connect().
I agree that no code in the app should be able to cause the phone to reboot, and that the fact that this is possible is an Apple bug.
Although it is not possible for the debugger to stop on a kernel panic (because the device disconnects, so the debugger stops), you can still debug it in a way, if you know approximately where it happens, you can step line-by-line in the debugger, and see which line it kernel panics at. The line it panics on will be a function call (the panic happens inside the call), so you can now step inside that function call, and repeat, until you've narrowed it down to the specific system call.
I've started using SmartInspect in my Delphi applications because my users were running into bugs/problems I couldn't reproduce on my machine. When I have a general idea of the problem I'll monitor the application in a few specific places to confirm what is or is not working.
When the bug doesn't have an obvious cause, I feel lost. I don't know where to start logging in order to narrow down the problem. Are there common techniques or best practices for using a logger?
SmartInspect seems to be quite powerful, but I don't know quite what to log or how to organise my logs so the data is meaningful and useful for catching bugs.
NOTE: I'm using SmartInspect but I assume the answers should be suitable for any logging package.
Here are some guidelines I tried to implement in my own OpenSource logging unit, but it's fairly generic, and as you state, it should be suitable for any logging package:
Make several levels (we use sets) of logging, to tune the logging information needed;
Log all exceptions, even the handled one with a try...except block - and add an exception classes list not worth logging (e.g. EConvertError) - e.g. our unit is able to log all exceptions via a global exception "hook" (no try..except to add in your code), and handle a list of exception classes to be ignored;
Log all "fatal" errors, like database connection issues, or wrong SQL syntax - should be done though "log all exceptions" previous item;
For such exceptions, log the stack trace to know about the calling context;
Be able to log all SQL statements, or database access;
Add a generic User Interface logging, to know which main functions of the software the User did trigger (e.g. for every toolbar button or menu items): it's very common that the user said 'I have this on my screen/report, but I didn't do anything'... and when you see the log, you will discover that the "anything" was done. ;)
Monitor the main methods of your application, and associated parameters;
Logging is an evolving feature: use those general rules above, then tune your logging from experiment, according to your debugging needs.
For UI-driven applications here are the main things I instrument first:
ActionManager or ActionList's events when an action executes (gives me a user clicked here then here then here list).
Unhandled Exceptions with tracebacks using JCL debug go right in my main log, whereas if I was using MadExcept or EurekaLog, exceptions have their own log.
Background thread starts, stops and significant history events
Warnings, errors, API function failures, file access failures, handled (caught) exceptions.
Current memory usage can be useful for long running processes to see if there are memory leaks (which could lead to an out of memory error some day).
1) how to initialize the stack with some unique pattern? so i can check it on the exit? sample program plz
2) how to add values in prolog and check it in epilog ? sample program plz
valgrind and electric fence doesnt work with my multithreaded app it is too bulky i want some simple trick like
add const value in prolog
check it back in epilog
thanks,
Vj
In your first question I think you are talking about preventing the execution stack from being overran. There are different technique to archive this, but I think the one closest to "some unique pattern" is the canary.
Theory:
The canary is a (random) check value that is placed just below the functions return address. Before returning from the function, the system checks if the canary has the same value as before. If not, the stack has been overran, since the memory is written from lower to higher addresses, and you can't trust the return address.
How it's done:
When the return address are placed
on the stack, the canary is placed
there as well.
When the function exits, the canary is checked. If the canary has been altered, terminate the program (or whatever you find appropriate).
More information about canary values can be found here.
This (or some other stack overrun prevention technique) are generally implemented in modern compilers.
I have no idea about your second question.