Re: [fpc-devel] Stack dump with possible segfault
On Mon, May 12, 2014 23:33, Johann Glaser wrote: Hi, I'm working on a project with an external library (libtcl, it is written in C) which creates some problems with back traces for exceptions. . . While not completely related to your original topic, I'd like to ask you if you decided knowingly not to use the package tcl provided with FPC (and possibly improve / extend it for your target platform) and if so, what were your reasons. I ask because I'm not sure to which extent it's used and/or maintained, especially considering that it supports a fairly limited set of platforms measured by current FPC span and that the included name of the TCL DLL for Win32 does not seem to match currently available TCL version. Should the package not to be useful any longer, we should probably either update it (if anyone volunteers to maintain it, because I suspect that the original maintainer is not involved actively any longer), or consider deprecating it. Thanks Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCL [was: Stack dump with possible segfault]
On Tue, May 13, 2014 10:54, Johann Glaser wrote: Hi! Hi, I'm working on a project with an external library (libtcl, it is written in C) which creates some problems with back traces for exceptions. . . While not completely related to your original topic, I'd like to ask you if you decided knowingly not to use the package tcl provided with FPC (and possibly improve / extend it for your target platform) and if so, what were your reasons. I ask because I'm not sure to which extent it's used and/or maintained, especially considering that it supports a fairly limited set of platforms measured by current FPC span and that the included name of the TCL DLL for Win32 does not seem to match currently available TCL version. Should the package not to be useful any longer, we should probably either update it (if anyone volunteers to maintain it, because I suspect that the original maintainer is not involved actively any longer), or consider deprecating it. I have to admit that I didn't consider that there could already be a TCL unit available. Therefore I did a full header translation for TCL 8.4 (which was the current version at that time). Additionally I added an object oriented wrapper to ease the programming. Please see at https://github.com/hansiglaser/pas-tcl for the sources. I use this library (together with pas-readline) in several projects (e.g. eztool on Github), some of which are actively in development but not yet published. It currently works perfectly with TCL 8.5, but I didn't (yet) update the header translations. I'd be happy for any help improving the library or even inclusion in FPC! Since you already use TCL, could you please check if the version included with FPC is still useable at all with the currently available TCL version? I guess that you'd be probably able to modify one of your test programs to only use functions available in the older TCL version (or create another simple test for that purpose if that would be easier)? Depending on the result (and compatibility of the relevant licences), we have to agree with other members of the FPC core team on the most sensible approach. I noticed that there are some obvious differences in used types (pointer versus PChar, minor differences in parameter or record member names, etc.) between the two translations, but these might not impose a major issue. PS: I've mentioned the TCL library in the fpc-pascal list some time ago: http://lists.freepascal.org/fpc-pascal/2012-September/035177.html I see; I probably missed it then. BTW, I noticed that you refer to file license.terms in multiple places of your repository, but I couldn't find that file there. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stack dump with possible segfault
Hi again! Am Montag, den 12.05.2014, 23:33 +0200 schrieb Johann Glaser: Hi! I'm working on a project with an external library (libtcl, it is written in C) which creates some problems with back traces for exceptions. If a custom TCL command raises an exception, I catch it and use the function DumpExceptionBackTrace to print the back trace. This function uses RaiseList which returns the ExceptObjectStack pointer. The stack frame information is filled by fpc_PushExceptObj in except.inc using the functions get_frame, get_caller_addr and get_caller_frame. These three functions are also used by dump_stack which can be used at any point in the code (outside of exceptions). These three functions assume, that the stack frame is stored in the RBP register (x86_64 architecture) and that every function call starts with these two assembler instructions push %rbp mov%rsp,%rbp which leads to the stack layout of the return address (pushed by the call instruction) followed by the RBP value. As this is true for FreePascal code (I guess), this doesn't necessarily hold for external libraries as the TCL library mentioned above. News on that front: Today I investigated a duplicate key exception in FGL.TFPSMaps.Add(AKey: Pointer): Integer. In the current Debian package fp-units-rtl-2.6.4 2.6.4+dfsg-2 this seems to be compiled with looots of optimization and without stack frame: 1918 FGL_TFPSMAP_$__ADD$POINTER$$LONGINT: 1918: 48 81 ec 18 01 00 00sub$0x118,%rsp 191f: 48 89 9c 24 08 01 00mov%rbx,0x108(%rsp) 1926: 00 1927: 4c 89 a4 24 10 01 00mov%r12,0x110(%rsp) 192e: 00 192f: 48 89 fbmov%rdi,%rbx 1932: 49 89 f4mov%rsi,%r12 Even GDB couldn't trace back the stack there. :-O Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCL
Hi! Am Dienstag, den 13.05.2014, 11:46 +0200 schrieb Tomas Hajny: On Tue, May 13, 2014 10:54, Johann Glaser wrote: Hi! Hi, I'm working on a project with an external library (libtcl, it is written in C) which creates some problems with back traces for exceptions. . . While not completely related to your original topic, I'd like to ask you if you decided knowingly not to use the package tcl provided with FPC (and possibly improve / extend it for your target platform) and if so, what were your reasons. I ask because I'm not sure to which extent it's used and/or maintained, especially considering that it supports a fairly limited set of platforms measured by current FPC span and that the included name of the TCL DLL for Win32 does not seem to match currently available TCL version. Should the package not to be useful any longer, we should probably either update it (if anyone volunteers to maintain it, because I suspect that the original maintainer is not involved actively any longer), or consider deprecating it. I have to admit that I didn't consider that there could already be a TCL unit available. Therefore I did a full header translation for TCL 8.4 (which was the current version at that time). Additionally I added an object oriented wrapper to ease the programming. Please see at https://github.com/hansiglaser/pas-tcl for the sources. I use this library (together with pas-readline) in several projects (e.g. eztool on Github), some of which are actively in development but not yet published. It currently works perfectly with TCL 8.5, but I didn't (yet) update the header translations. I'd be happy for any help improving the library or even inclusion in FPC! Since you already use TCL, could you please check if the version included with FPC is still useable at all with the currently available TCL version? I guess that you'd be probably able to modify one of your test programs to only use functions available in the older TCL version (or create another simple test for that purpose if that would be easier)? I used the files in /usr/share/fpcsrc/2.6.4/packages/tcl/ which also include a demo program. I had to do the following changes: - tcl80.pp: remove the $define USE_C - tcl80.pp: change TCL_LIBRARY = 'tcl8.5'; - tcl80.pp: in function ArgvItem I removed the ridiculous assembler stuff by the simple line Result := argv[Idx];. This expression should also be used in tcl_demo.pp, btw. - copied over test.tcl from a quite old SVN checkout of http://svn.freepascal.org/svn/fpc/trunk (2011-03-05) I had somewhere on my disk Then compilation worked properly and the demo works too. Using tcl8.6 also works. Depending on the result (and compatibility of the relevant licences), we have to agree with other members of the FPC core team on the most sensible approach. I noticed that there are some obvious differences in used types (pointer versus PChar, minor differences in parameter or record member names, etc.) between the two translations, but these might not impose a major issue. Ok. PS: I've mentioned the TCL library in the fpc-pascal list some time ago: http://lists.freepascal.org/fpc-pascal/2012-September/035177.html I see; I probably missed it then. BTW, I noticed that you refer to file license.terms in multiple places of your repository, but I couldn't find that file there. That is a verbatim cite of the original TCL header files. Is it necessary to include their file with my Pascal translations? Thanks Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stack dump with possible segfault
Am 13.05.2014 21:56 schrieb Johann Glaser johann.gla...@gmx.at: As this is true for FreePascal code (I guess), this doesn't necessarily hold for external libraries as the TCL library mentioned above. News on that front: Today I investigated a duplicate key exception in FGL.TFPSMaps.Add(AKey: Pointer): Integer. In the current Debian package fp-units-rtl-2.6.4 2.6.4+dfsg-2 this seems to be compiled with looots of optimization and without stack frame: 1918 FGL_TFPSMAP_$__ADD$POINTER$$LONGINT: 1918: 48 81 ec 18 01 00 00sub$0x118,%rsp 191f: 48 89 9c 24 08 01 00mov%rbx,0x108(%rsp) 1926: 00 1927: 4c 89 a4 24 10 01 00mov%r12,0x110(%rsp) 192e: 00 192f: 48 89 fbmov%rdi,%rbx 1932: 49 89 f4mov%rsi,%r12 Even GDB couldn't trace back the stack there. :-O Code in release packages is normally compiled using -O2, which can result in hard to follow backtraces. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel