Re: [fpc-pascal] Debug information
Linux Platform. In the past there was a discussion about it already. It may has to do with dynamic loaded library? On Tuesday 13 January 2015 16:32:37 you wrote: On 13 Jan 2015, at 16:14, Martin Frb wrote: On 13/01/2015 14:40, Rainer Stratmann wrote: Can not get debug information -g -gl -gw switched on but no further information (line nr) is displayed when an error occured. -gl has a feature it prints the stack info, until it finds an address for which there is no stack info (e.g. in the rtl, if the rtl was not compiled with info). No, it only stops printing line info for both the current and all future backtraces if an error occurs during the reading/decoding of the line information. If no line info is found for a particular address, nothing special happens. However, -gl is not fully functional on platforms. E.g., it doesn't work for DWARF on (Mac) OS X. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Debug information
Can not get debug information -g -gl -gw switched on but no further information (line nr) is displayed when an error occured. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
On 13 Jan 2015, at 16:14, Martin Frb wrote: On 13/01/2015 14:40, Rainer Stratmann wrote: Can not get debug information -g -gl -gw switched on but no further information (line nr) is displayed when an error occured. -gl has a feature it prints the stack info, until it finds an address for which there is no stack info (e.g. in the rtl, if the rtl was not compiled with info). No, it only stops printing line info for both the current and all future backtraces if an error occurs during the reading/decoding of the line information. If no line info is found for a particular address, nothing special happens. However, -gl is not fully functional on platforms. E.g., it doesn't work for DWARF on (Mac) OS X. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
On 13/01/2015 14:40, Rainer Stratmann wrote: Can not get debug information -g -gl -gw switched on but no further information (line nr) is displayed when an error occured. -gl has a feature it prints the stack info, until it finds an address for which there is no stack info (e.g. in the rtl, if the rtl was not compiled with info). IIRC this is to avoid issues if an error occurred while getting line info. But not sure. So if your first address is not in code with debug info, then that is it. If you run in the debugger, or resolve with leak-view then this will not happen. But ofcourse if the error occurs with either a corrupted stack, or in some code (e.g system kernal) that does not use stackframes then the stack can not always be parsed. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
Am Tuesday 11 September 2012 19:30:55 schrieb Mark Morgan Lloyd: Rainer Stratmann wrote: Am Tuesday 11 September 2012 18:14:57 schrieb Mark Morgan Lloyd: Martin wrote: On 11/09/2012 10:28, Rainer Stratmann wrote: I found out that there is no line information shown (-gl) if an error occurs (more or less shortly) after the program loads a dynamic library. This same behaviour happens with fpc version 2.4.2-0 and 2.6.0. If no library is loaded line information is shown. The error adresses are the same in both cases. How is the library being loaded: using FPC's dynlibs unit? Yes. If using dynlibs, is the problem immediately after loading the library (.so) or is it on a call of an entry point in the library? Immediately after loading the library. In which case I presume that you could comment out the calls to the entry points in the library and duplicate the problem (have you tried this?). Does the recently-added GetLoadError() function tell you anything useful? The error is produced immediately after loading (not executing) the library (writing to a random memory adress). I did not find information of the GetLoadError() function. Is the DLL successfully called, does it exit predictably, and does the stack recover to the state it was on entry (i.e. without an extra or missing word)? The program restarts some times and there is no error. If it's specifically something that happens at load time then below probably isn't relevant. Stack recovery I don't know. I think it will be ok. How can I see that? Inline assembler to dump esp and ebp. ? I use loadlibrary and freelibrary. There are only 3 functions/procedures calling from the program. (init_proc, loop_proc, exit_proc). The library calls back a procedure (add a key to a keybuffer) but in this procedure there is no error. I tried safeloadlibrary but the same thing. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Debug information
I found out that there is no line information shown (-gl) if an error occurs (more or less shortly) after the program loads a dynamic library. This same behaviour happens with fpc version 2.4.2-0 and 2.6.0. If no library is loaded line information is shown. The error adresses are the same in both cases. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
Rainer Stratmann wrote: I found out that there is no line information shown (-gl) if an error occurs (more or less shortly) after the program loads a dynamic library. This same behaviour happens with fpc version 2.4.2-0 and 2.6.0. If no library is loaded line information is shown. The error adresses are the same in both cases. What OS? Are you expecting a line number associated with code in the calling program or the .DLL/.so? What has caused the error- is the calling convention etc. correct? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
Am Tuesday 11 September 2012 12:05:02 schrieb Mark Morgan Lloyd: Rainer Stratmann wrote: I found out that there is no line information shown (-gl) if an error occurs (more or less shortly) after the program loads a dynamic library. This same behaviour happens with fpc version 2.4.2-0 and 2.6.0. If no library is loaded line information is shown. The error adresses are the same in both cases. What OS? Linux Are you expecting a line number associated with code in the calling program or the .DLL/.so? Expecting: line xxx of yyy.pas But when loading a library only adresses are shown. What has caused the error simple access violation - is the calling convention etc. correct? I hope so because the program runs 24/7 in some places in eurpoe. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
Am Tuesday 11 September 2012 12:05:02 schrieb Mark Morgan Lloyd: Are you expecting a line number associated with code in the calling program or the .DLL/.so? By now only the main program if affected. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
On 11/09/2012 10:28, Rainer Stratmann wrote: I found out that there is no line information shown (-gl) if an error occurs (more or less shortly) after the program loads a dynamic library. This same behaviour happens with fpc version 2.4.2-0 and 2.6.0. If no library is loaded line information is shown. The error adresses are the same in both cases. This is about debug info written by DumpStack or similar (written by the exe itself, to the console)? Or debug info shown by gdb using bt? If the first, does the latter work? As from your other replies, the exception occurs in your pascal code. But is this code in a callback from the DLL? (This would mean that stackframes of the DLL exist, and they have no line info) Or could for any other reason (including compiled with optimization) there be a stackframe (just one) that has no line info? IIRC the line-info on stacktraces is only displayed until the very first time a line without info is discovered. That is: 1) If within the current stackdump a line without info is discovered, then no further line will be attempted to be resolved (even if info could be available) 2) If in a previous dump, such a line was discovered, then in any further dump (even though unrelated) no line info is printed. In Lazarus the leak view, can attempt to resolve such traces. It requires the exact exe with debug info. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
Am Tuesday 11 September 2012 14:16:35 schrieb Martin: On 11/09/2012 10:28, Rainer Stratmann wrote: I found out that there is no line information shown (-gl) if an error occurs (more or less shortly) after the program loads a dynamic library. This same behaviour happens with fpc version 2.4.2-0 and 2.6.0. If no library is loaded line information is shown. The error adresses are the same in both cases. This is about debug info written by DumpStack or similar (written by the exe itself, to the console)? Or debug info shown by gdb using bt? If the first, does the latter work? ? It is a console program with graphic output to the framebuffer. When loading succesfully the library (which depends on the x11 library) the framebuffer is written to an XWindow (Linux). The software runs with a plain (embedded) linux and also in an XWindow environment. I have only the information of what the exe program writes down in case of an error. No other debug tool is used by now. Specially when the program runs outside it will be not easy to use additional tools, I think. As from your other replies, the exception occurs in your pascal code. But is this code in a callback from the DLL? (Linux Library *.so) No. (This would mean that stackframes of the DLL exist, and they have no line info) Or could for any other reason (including compiled with optimization) there be a stackframe (just one) that has no line info? May be. IIRC the line-info on stacktraces is only displayed until the very first time a line without info is discovered. That is: 1) If within the current stackdump a line without info is discovered, then no further line will be attempted to be resolved (even if info could be available) With not loading the library it shows all lines correctly. 2) If in a previous dump, such a line was discovered, then in any further dump (even though unrelated) no line info is printed. But why are the lines not shown if there is only one line without info? In Lazarus the leak view, can attempt to resolve such traces. It requires the exact exe with debug info. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
On 11/09/2012 16:07, Rainer Stratmann wrote: Or could for any other reason (including compiled with optimization) there be a stackframe (just one) that has no line info? May be. IIRC the line-info on stacktraces is only displayed until the very first time a line without info is discovered. That is: 1) If within the current stackdump a line without info is discovered, then no further line will be attempted to be resolved (even if info could be available) With not loading the library it shows all lines correctly. You load the lib dynamically? e.g OpenLibrary? If it is hardlinked (procedure ... external) then this changes the exe, and the linker may move stuff around (including debug info, and maybe debug info gets broken). On some platform samrtlinking, also has a real risk of breaking debug info... If it is via OpenLibrary (e.g. you can control the usage via commandline switch, and therefore truly have the same exe, then I do not know... There may be other reasons, that I do not know of. You can always (not sure if it works for PIE / position independent) take the address, and have gdb check, if it can be resolved). 2) If in a previous dump, such a line was discovered, then in any further dump (even though unrelated) no line info is printed. But why are the lines not shown if there is only one line without info? Missing recovery in the implementation... Now this is from memory. double check it. I may well remember this wrong. Basically, if an error happens (exception) during a trace is printed, then this could lead to a new trace, a new error, a new trace ... a stackoverflow. So during a trace, the pointer to the trace prog, is set to the basic address only prog. Unfortunately there is no distinction between errors. So not finding a line is an error (IIRC it is handled the same as if dbg info is invalid/broken), and that is the end... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
Martin wrote: On 11/09/2012 10:28, Rainer Stratmann wrote: I found out that there is no line information shown (-gl) if an error occurs (more or less shortly) after the program loads a dynamic library. This same behaviour happens with fpc version 2.4.2-0 and 2.6.0. If no library is loaded line information is shown. The error adresses are the same in both cases. How is the library being loaded: using FPC's dynlibs unit? If using dynlibs, is the problem immediately after loading the library (.so) or is it on a call of an entry point in the library? This is about debug info written by DumpStack or similar (written by the exe itself, to the console)? Or debug info shown by gdb using bt? If the first, does the latter work? As from your other replies, the exception occurs in your pascal code. But is this code in a callback from the DLL? (This would mean that stackframes of the DLL exist, and they have no line info) Or could for any other reason (including compiled with optimization) there be a stackframe (just one) that has no line info? Is the DLL successfully called, does it exit predictably, and does the stack recover to the state it was on entry (i.e. without an extra or missing word)? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
Am Tuesday 11 September 2012 18:14:57 schrieb Mark Morgan Lloyd: Martin wrote: On 11/09/2012 10:28, Rainer Stratmann wrote: I found out that there is no line information shown (-gl) if an error occurs (more or less shortly) after the program loads a dynamic library. This same behaviour happens with fpc version 2.4.2-0 and 2.6.0. If no library is loaded line information is shown. The error adresses are the same in both cases. How is the library being loaded: using FPC's dynlibs unit? Yes. If using dynlibs, is the problem immediately after loading the library (.so) or is it on a call of an entry point in the library? Immediately after loading the library. This is about debug info written by DumpStack or similar (written by the exe itself, to the console)? Or debug info shown by gdb using bt? If the first, does the latter work? As from your other replies, the exception occurs in your pascal code. But is this code in a callback from the DLL? (This would mean that stackframes of the DLL exist, and they have no line info) Or could for any other reason (including compiled with optimization) there be a stackframe (just one) that has no line info? Is the DLL successfully called, does it exit predictably, and does the stack recover to the state it was on entry (i.e. without an extra or missing word)? The program restarts some times and there is no error. Stack recovery I don't know. I think it will be ok. How can I see that? I use loadlibrary and freelibrary. There are only 3 functions/procedures calling from the program. (init_proc, loop_proc, exit_proc). The library calls back a procedure (add a key to a keybuffer) but in this procedure there is no error. I tried safeloadlibrary but the same thing. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
Am Tuesday 11 September 2012 17:38:44 schrieb Martin: But why are the lines not shown if there is only one line without info? Missing recovery in the implementation... Now this is from memory. double check it. I may well remember this wrong. Basically, if an error happens (exception) during a trace is printed, then this could lead to a new trace, a new error, a new trace ... a stackoverflow. So during a trace, the pointer to the trace prog, is set to the basic address only prog. Unfortunately there is no distinction between errors. So not finding a line is an error (IIRC it is handled the same as if dbg info is invalid/broken), and that is the end... For debugging the best would be to write down as much information as possible. Even if it causes (eventually) more (endless) errors. Would this be possible? May be with a switch? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
Rainer Stratmann wrote: Am Tuesday 11 September 2012 18:14:57 schrieb Mark Morgan Lloyd: Martin wrote: On 11/09/2012 10:28, Rainer Stratmann wrote: I found out that there is no line information shown (-gl) if an error occurs (more or less shortly) after the program loads a dynamic library. This same behaviour happens with fpc version 2.4.2-0 and 2.6.0. If no library is loaded line information is shown. The error adresses are the same in both cases. How is the library being loaded: using FPC's dynlibs unit? Yes. If using dynlibs, is the problem immediately after loading the library (.so) or is it on a call of an entry point in the library? Immediately after loading the library. In which case I presume that you could comment out the calls to the entry points in the library and duplicate the problem (have you tried this?). Does the recently-added GetLoadError() function tell you anything useful? Is the DLL successfully called, does it exit predictably, and does the stack recover to the state it was on entry (i.e. without an extra or missing word)? The program restarts some times and there is no error. If it's specifically something that happens at load time then below probably isn't relevant. Stack recovery I don't know. I think it will be ok. How can I see that? Inline assembler to dump esp and ebp. I use loadlibrary and freelibrary. There are only 3 functions/procedures calling from the program. (init_proc, loop_proc, exit_proc). The library calls back a procedure (add a key to a keybuffer) but in this procedure there is no error. I tried safeloadlibrary but the same thing. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information again
Hi all again. About this boring problem I have maybe a track. I downloaded the latest Lazarus release (0.9.30 as it is on the main download page from France mirror) and installed it in place of 1.1 It runs FPC 2.6.0 Compile and install needed packages Compile and run the test project and get the same results: no line tracing information. Then I changed the test as suggested by Martin on the Lazarus mailing list and used a TStringList which is never freed. This time it woks !!! =-O I did not experience all possible combinations of debug switches I will try now to change the package I must test and include some smart memory leaks. I'll notice the results on the list Antonio. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Debug information again
Hi folks. I've got a serious prblem too with debugger and heaptrc. It look like the one described by *Rainer Stratmann *posted last month. My problem goes around the tracing of memory leaks. I've been busy with Martin on the Lazarus mailing list and he couldn't find why addresses were not followed by their line reference. Apparently all tracing references from the program seem to be omitted or maybe better, unreachable. When I do a strip from the program executable it shrinks from 17 meg down to 2.5 meg. So something is in it. I can see the memory leak I have generated (read below) but no refecence to the line itself. Instead I receive the reference lines before and after the memory leak creation inside the rtl. Environment: W7-win32, Lazarus 1.1 from 2012-06-11, WinCE target added and compiles OK Project: Very simple project (one form, two buttons one to create a memory leak, one to close) Redirect heaptrc output to a file Set compiler options for compiler and linker: do not use INLINE style C++ -O- omit any optimization -g automatic debugger -gl add line numbers -gh use heaptrc -WG win32 program compile, link and run and get this: /*c:\sources\compiled\TestUib.Exe Heap dump by heaptrc unit 756 memory blocks allocated : 1539928/1541288 755 memory blocks freed : 1539912/1541272 1 unfreed memory blocks : 16*/ my block, looks OK /*True heap size : 655360 (96 used in System startup) True free heap : 658416 Should be : 655184 Call trace for block $001D62B0 size 16*/ my block, looks OK /* $0040D628 $004FAA4E TCONTROL__CLICK, line 2735 of ./include/control.inc $00512A7F TBUTTONCONTROL__CLICK, line 56 of ./include/buttoncontrol.inc $005130B6 TCUSTOMBUTTON__CLICK, line 175 of ./include/buttons.inc $00513711 TBUTTON__CLICK, line 355 of ./include/buttons.inc $005129AA TBUTTONCONTROL__WMDEFAULTCLICKED, line 26 of ./include/buttoncontrol.inc $0040AE56 $004EDBEF TWINCONTROL__WNDPROC, line 5298 of ./include/wincontrol.inc*/ Thea ddress /*$0040D628*/ corresponds to the function Reallocmem function used to get the memory block Problem is that I need to debug a complicated package which leaves a lot of memory leaks that I have to trace and correct. Antonio. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information again
Antonio Fortuny wrote on Wed, 13 Jun 2012: I can see the memory leak I have generated (read below) but no refecence to the line itself. Instead I receive the reference lines before and after the memory leak creation inside the rtl. The reason is that the RTL itself is compiled with optimisations. This means that sometimes no stack frame is generated for such routines. As a result, when crawling the stack, you will not see the *caller* of such routines in the stack trace. The only way to work around this is to recompile the RTL without optimisations. FWIW, the same problem happens with any compiler that implements stack frame optimisations (e.g., with gcc you'd have to use -fno-omit-frame-pointer to prevent this from taking place; the equivalent FPC parameter is -Oonostackframe). The only solution from a distribution point of view would be to either disable this stack frame optimisation for released units, or to distribute two different RTL's (one compiled with and one compiled without optimisations). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information again
On 13/06/2012 14:12, Jonas Maebe wrote: Antonio Fortuny wrote on Wed, 13 Jun 2012: I can see the memory leak I have generated (read below) but no refecence to the line itself. Instead I receive the reference lines before and after the memory leak creation inside the rtl. The reason is that the RTL itself is compiled with optimisations. This means that sometimes no stack frame is generated for such routines. As a result, when crawling the stack, you will not see the *caller* of such routines in the stack trace. The only way to work around this is to recompile the RTL without optimisations. Out of interest. I reproduced this myself. And I found that while fpc is omitting some frames, if I run in gdb and step into reallocmem, then gdb is able to show the stack. So it appears, that it is possible. Though I do not know if GDB does this by analysing the stack only, or gdb also uses knowledge from disassembling the function headers ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
Am Tuesday 29 May 2012 01:42:12 schrieb Martin: On 28/05/2012 23:53, Rainer Stratmann wrote: Am Monday 28 May 2012 22:25:47 schrieb Martin: Check that you have not accidentally set any options that will block -gl, such as -Xs or maybe (may work but I do not know for sure) -Xg After changing options, change Build or Build all from run menu. All done, same effect (only addresses shown). I thought of other options that block the lineoutput, but can not imagine which one. Gets back to one of the questions of the last mail: Did you have a look at the exe size? The exe size is the easiest indicator, if debug info was added. The program size (in Linux) is nearly 3 times more than without debug info. Running out of ideas myself. May be someone else can help... Can you run with F9 in Lazarus? making sure the debugger is set up ( http://wiki.lazarus.freepascal.org/Debugger_Setup ) I will try later. The debugger should stop on a run error, and you should be able to get the stacktrace. It does not solve the initial problem, but one step at a time. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
On 29.05.2012 10:25, Rainer Stratmann wrote: I will try later. Also make sure you have turned *off* all optimizations, they can sometimes mess up the stack trace badly (by removing unneeded stack frames which can produce very confusing results) and also I have witnessed at least one occasion where smart linking also somehow interfered with debugging (but this might have been a gdb problem), but maybe better turn this off also, just to be on the safe side. Building your own compiler and RTL from source with debugging symbols only sounds complicated the very first time you hear about this idea, once you have successfully done it yourself you will find that it is actually quite easy and not more complicated than installing a compiler via the .deb packages. Bernd ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
Am Sunday 27 May 2012 17:44:41 schrieb Sven Barth: On 27.05.2012 14:32, Rainer Stratmann wrote: How to get debug information? There is an error, but only adresses are shown. I put on debugger Information in Lazarus (-g) but can get no further infos when an error occurs (except the adresses). Lazarus 0.9.30 fpc 2.4.2 You also need to enable line information using -gl. Debug information itself is only useful for stepping through an application using a debugger. The line information is the one you seek. That does not work. I sign it in the lazarus project preferences window, but no effect. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
On 27/05/2012 13:32, Rainer Stratmann wrote: How to get debug information? There is an error, but only adresses are shown. How/ Where are the addresses shown? Does your program has code of it's own, that dumps the stacktrace? (normally added using with -gl) Or do you run in a debugger (gdb?) You should note that the DumpStack function, if called by your code (AND if debug info is available) does dump source file and line. BUT only up to the very first time it does encounter an address that can not be resolved. Once that has happened no further addresses are resolved. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
Am Monday 28 May 2012 21:12:30 schrieb Martin: On 27/05/2012 13:32, Rainer Stratmann wrote: How to get debug information? There is an error, but only adresses are shown. How/ Where are the addresses shown? The addresses were shown in the output window (console). Runtime error 207 at $0808BE90 $0808BE90 $080A0E60 $080A0738 $08049064 $08053256 $080494F2 $08048F84 $08048754 $080483E3 $080482B3 Does your program has code of it's own, that dumps the stacktrace? No. (normally added using with -gl) Or do you run in a debugger (gdb?) No. You should note that the DumpStack function, if called by your code (AND if debug info is available) does dump source file and line. I am not familiar with that function? BUT only up to the very first time it does encounter an address that can not be resolved. Once that has happened no further addresses are resolved. I do not understand exactly what that means. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
On 28/05/2012 20:35, Rainer Stratmann wrote: Am Monday 28 May 2012 21:12:30 schrieb Martin: On 27/05/2012 13:32, Rainer Stratmann wrote: How to get debug information? There is an error, but only adresses are shown. How/ Where are the addresses shown? The addresses were shown in the output window (console). Runtime error 207 at $0808BE90 $0808BE90 Ok: those addresses *should* get names, if you compile with -gl AND do not in any form strip (strip.exe removes the debug info) your app An app containing debug info has a considerable bigger exe. (can be 10 times or more as big as without) if you make a copy of your exe, and run strip[.exe] the_copy the the copy should be much smaller On windows strip.exe is in the fpc bin directory BUT only up to the very first time it does encounter an address that can not be resolved. Once that has happened no further addresses are resolved. I do not understand exactly what that means. If you get it to work, and one of the addresses is in the RTL (assuming your RTL has no dobug info), or in the kernel then the translation simply stops. It could be that the top address is in the rtl, then you will never get the info you can use gdb (assuming there is debug info / check the exe size) gdb your_exe and inside gdb info symbol *0x0808BE90 Not all symbols may resolve though -- You can (again assume debug info) run in gdb gdb your_exe break FPC_RUNERROR r and when stopped bt ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
Am Monday 28 May 2012 22:09:21 schrieb Martin: On 28/05/2012 20:35, Rainer Stratmann wrote: Am Monday 28 May 2012 21:12:30 schrieb Martin: On 27/05/2012 13:32, Rainer Stratmann wrote: How to get debug information? There is an error, but only adresses are shown. How/ Where are the addresses shown? The addresses were shown in the output window (console). Runtime error 207 at $0808BE90 $0808BE90 Hi, that sounds very complicated in comparison to the past. There I could get it work and simply the line numbers and the file were displayed in combination with the addresses. Why does it not work this way again? The addresses are not in the system unit. I am compiling under Linux! Are there also gdb and strip available? Ok: those addresses *should* get names, if you compile with -gl AND do not in any form strip (strip.exe removes the debug info) your app An app containing debug info has a considerable bigger exe. (can be 10 times or more as big as without) if you make a copy of your exe, and run strip[.exe] the_copy the the copy should be much smaller On windows strip.exe is in the fpc bin directory BUT only up to the very first time it does encounter an address that can not be resolved. Once that has happened no further addresses are resolved. I do not understand exactly what that means. If you get it to work, and one of the addresses is in the RTL (assuming your RTL has no dobug info), or in the kernel then the translation simply stops. It could be that the top address is in the rtl, then you will never get the info you can use gdb (assuming there is debug info / check the exe size) gdb your_exe and inside gdb info symbol *0x0808BE90 Not all symbols may resolve though -- You can (again assume debug info) run in gdb gdb your_exe break FPC_RUNERROR r and when stopped bt ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
On 28/05/2012 21:19, Rainer Stratmann wrote: Am Monday 28 May 2012 22:09:21 schrieb Martin: On 28/05/2012 20:35, Rainer Stratmann wrote: Am Monday 28 May 2012 21:12:30 schrieb Martin: On 27/05/2012 13:32, Rainer Stratmann wrote: How to get debug information? There is an error, but only adresses are shown. How/ Where are the addresses shown? The addresses were shown in the output window (console). Runtime error 207 at $0808BE90 $0808BE90 Hi, that sounds very complicated in comparison to the past. There I could get it Well as others already said: it should still work simply by adding -gl But apparently it does not for you. Finding out why not, indeed can be more complex. So I added various bits of info... In case. Just seeing you use lazarus. Check that you have not accidentally set any options that will block -gl, such as -Xs or maybe (may work but I do not know for sure) -Xg After changing options, change Build or Build all from run menu. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
Am Monday 28 May 2012 22:25:47 schrieb Martin: Check that you have not accidentally set any options that will block -gl, such as -Xs or maybe (may work but I do not know for sure) -Xg After changing options, change Build or Build all from run menu. All done, same effect (only addresses shown). I thought of other options that block the lineoutput, but can not imagine which one. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
On 28/05/2012 23:53, Rainer Stratmann wrote: Am Monday 28 May 2012 22:25:47 schrieb Martin: Check that you have not accidentally set any options that will block -gl, such as -Xs or maybe (may work but I do not know for sure) -Xg After changing options, change Build or Build all from run menu. All done, same effect (only addresses shown). I thought of other options that block the lineoutput, but can not imagine which one. Gets back to one of the questions of the last mail: Did you have a look at the exe size? The exe size is the easiest indicator, if debug info was added. Running out of ideas myself. Can you run with F9 in Lazarus? making sure the debugger is set up ( http://wiki.lazarus.freepascal.org/Debugger_Setup ) The debugger should stop on a run error, and you should be able to get the stacktrace. It does not solve the initial problem, but one step at a time. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Debug information
How to get debug information? There is an error, but only adresses are shown. I put on debugger Information in Lazarus (-g) but can get no further infos when an error occurs (except the adresses). Lazarus 0.9.30 fpc 2.4.2 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Debug information
On 27.05.2012 14:32, Rainer Stratmann wrote: How to get debug information? There is an error, but only adresses are shown. I put on debugger Information in Lazarus (-g) but can get no further infos when an error occurs (except the adresses). Lazarus 0.9.30 fpc 2.4.2 You also need to enable line information using -gl. Debug information itself is only useful for stepping through an application using a debugger. The line information is the one you seek. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
