How to translate relative addresses to line numbers? lazarus / 12-Debugger ---------------------------------------------------------------------- ciuly · 2009-03-09 21:11 I have a service (daemon) compiled for win32. For some reason it started to freeze with a 100% CPU usage which basically suggests some infinite loop with no action. although it can be anything. I loaded process explorer (from sysinternals) and I looked at the threads and found the theradid which is over using the CPU and I know the stack trace of it in the form: appname.exe+number where number is probably a relative address, however, I couldn't find it in the MAP file generated at compilation time (-Xm). This doesn't happen every time, but it does happen about 20-30% of the time so it makes it difficult to catch. So, the question is: how can I translate that number to a sensible address or line number? OR, how can I get the stacktrace of that thread with some debugger so I can see the code lines, given the fact that the daemon runs on a customers computer? (which makes it a pain to debug) thanks. ---------------------------------------------------------------------- ciuly · 2009-04-24 13:38 the problem went away at that time, but now it's back (possibly another problem) and it reproduces all the time. I tried the following to no avail: - created a new thread which is counting (cnt=0; in an infinite loop it sleeps 1000 ms, then writes the current cnt, and then increments it) after 12-20 seconds, right after the problematic thread freezez the cpu at 100% (well, 50% since it's a dual core), the thread does not count anymore. for some odd reason, it appears that all the threads are locked, even though the counter thread is totally independant from the rest of the code. it has it's own dedicated file and code to write to it. so beside the fact that this doesn't make any sense, I still don't have a way of getting a correct stacktrace for the frozen thread, either from within the application or using another external application, which gets the trace but the trace does not map to anything found in the map file. I have -g -gl and -Xm specified. any ideas? ---------------------------------------------------------------------- Marc · 2009-04-26 17:01 Do you have a code sample ? ---------------------------------------------------------------------- ciuly · 2009-04-26 20:31 I code sample with the freeze? no, that would be what I am trying to find out in order to fix the problem It's a very big application and it's a service running on my clients computer which makes it almost impossible to remote-debug. I rely on logging and some 3rd party applications to track down issues. in almost all the cases, just the logging is sufficient, but in this particular case, the logging is not happening, so I turned to a 3rd party software, which gives me some stacktrace, but which stacktrace is unusable since the fpc generated map file does not contain actual usable line addresses. you can read a bit on the issue here: http://delphitools.info/forums/index.php?topic=13.0 basically how I and some other windows developers use the map file is that we get an address, do some transformation (usually subtracting the base/load address) and then look up that address in the map file. this works fine with delphi, VC, etc, but not with FPC. as you can read on this freepascal thread http://community.freepascal. org:10000/bboards/message?message_id=319487&forum_id=24082 I've tried using gdb to just load the exe and get the line number by the address provided by sysinternals process explorer AND by GetThreadContext winapi function, but to no avail. There is something specific about corelating addresses with linenumbers when it comes to FPC but I just can't seem to find the info which would solve OR help me solve the issue. at the moment I am trying to understand the lineinfo unit, and as a start, understanding some AT asm syntax as you can see in this thread http://community.freepascal.org:10000/bboards/message?message_id=32389 0&forum_id=24089 I hope that by understanding what is going on in the actual code, I will be able to figure out a way to translate an existing address to a correct linenumber either by using the map file or the gdb debug info. if you have any pointers on any of these, I'd appreciate them ---------------------------------------------------------------------- ciuly · 2009-04-27 10:11 I managed to write myself a helper app to get the stacktrace of any running thread in an external, running, freepascal compiled application. It support only win32 platform. The code can be found here: http://www.ciuly.com/tools/programming/esprinter/index.html Having the stacktrace, I managed to find the infinite loop and thus solve my problem. (just for the record, it was generated by the way I was reading the data from an indy servers client socket because I wasn't actually reading the data (a bad if clause) and thus my method was continuosly executed by the indy thread)