GDB 7.7. Ubuntu 64bit debugging problems lazarus / 12-Debugger ---------------------------------------------------------------------- tk · 2014-06-17 13:09 Hi, having a strange problem with Lazarus under my Kubuntu 14.04. Never experienced this before but now I am testing Lazarus in Linux on a 64 bit machine, for the first time. Just installed version 1.2.2 + FPC 2.6.4, GDB 7.7 was already installed. Run fresh empty project with F9, sometimes runs OK sometimes hangs, sometimes cannot be terminated with dialog cross, must press Ctrl+F2. Without debugging runs normally. Tried to install older GDB but always had strange GCC compilation errors. Does anybody have experience with Lazarus + GDB 7.7 + Kubuntu 64bit? Which version of GDB is stable and compatible with Ubuntu 14? ---------------------------------------------------------------------- BigChimp · 2014-06-17 13:52 See here http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips and linked pages for what versions are known to be problematic... In general, there's a lot of useful information on the wiki ---------------------------------------------------------------------- Martin_fr · 2014-06-17 14:07 You can attach a logfile (as on the end of the wiki page) It may be a while until I can analyse it. See also: http://forum.lazarus.freepascal.org/index.php/topic,24633.ms g148955.html#msg148955 And make sure you use dwarf only, in all packages and everywhere. (You can choose stabs, but dwarf is recommended.) ---------------------------------------------------------------------- tk · 2014-06-17 15:08 Logs attached. I am not wise from that. Have checked dwarf2. Here maybe 6 times ok and then debugger hanged. Now there are some packages installed but the same problems were with fresh installation of Lazarus. Interesting is when I check dwarf3 I cannot compile at all, linker produces errors like unit.pas:(.debug_info+0x6a7d): undefined reference to `DBG_GRAPHICS_TCanvas' tk ---------------------------------------------------------------------- Martin_fr · 2014-06-17 15:31 I didnt see any particular issue in the log. Neither GDB nor the IDE reported any error. About "dwarf2", some of the pre-installed packages may have debug settings, so you need to check them too (like LCL, LCLBase, ...). 2 more thinks to try; - In the debugger options: reset debugger after each run. If it only happens on consequutive runs, maybe there is a clean up issue. The IDE keeps gdb loaded, and re-uses it. This option starts a fresh gdb each time. - set the auto-solib option (search solib on the mentioned wiki page). ---------------------------------------------------------------------- tk · 2014-06-18 11:21 I don't know what exactly I changed, maybe Lazarus recompiled necessary packages for me, but now it seems to work. But I have another problem, when stepping into DLL, on second or third line in the DLL function, entire desktop hangs (is the same for Gnome and KDE) and I have to restart the computer. Without debugging this runs just normally. I don't see any notice about Linux desktop freezing on the wiki page. It seems that OS is running mouse is moving but you cannot do anything with it. And keyboard is dead. It seems to be some bug in Ubuntu but how could GDB cause such freezes? (these remind me the old Windows 9x times). Kubuntu 14.04 64-bit. ---------------------------------------------------------------------- Martin_fr · 2014-06-18 12:53 That usually happens when you try to debug events, like paint or keydown. Under linux there is an issue if you have a breakpoint in them. Not sure what the workaround is, if any. I just remember someone had that before. Maybe some setting with the thread scheduler, but I do not know. 1) Remote debug) 2) Use debug history, modify breakpoint properties, so breakpoint takes a snapshot, but does not break. Maybe some one else remembers. --- If it is not in an event, then good question. Maybe if it is a shared dll, and gdb is not allowed to step it... But that should give an error instead. If you debug dll, you can NOT set "solib = off" ---------------------------------------------------------------------- tk · 2014-06-18 13:12 More and more confused. Now latest automatic updates were installed, computer restarted, switched to KDE and Linux desktop hangs no more. Even I can step into DLL (so) routines and see some variables. However, then debugger sometimes hangs at FreeMem sometimes in a for loop.... But luckily here it is enough to kill Lazarus and start it again, much faster than to start Delphi on Win:) No more computer restarts necessary. Note that I am debugging a program which calls first DLL (SO) which in turn calls another DLL (SO). Main program and DLL written in Lazarus the second DLL is libftdixxx.so for FTDI chip. Moreover the first DLL is called in second thread. Certainly not easy task for the debugger. But without debugger it seems to run normally. ---------------------------------------------------------------------- Martin_fr · 2014-06-18 13:14 You can google gdb and scheduler locking. But I do not know much about it. ---------------------------------------------------------------------- tk · 2014-06-18 14:58 Just additional info about the GDB error: While executing the command: "TGDBMIDebuggerInstruction: "ptype PDevs^", [ifRequiresThread, ifRequiresStackFrame] Thr=6 Frm=0" gdb reported: "&"/build/buildd/gdb-7.7/gdb/utils.c:1067: internal-error: virtual memory exhausted: can't allocate 2147483600 bytes.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable."" So maybe GDB has problem with pointers to big arrays, here: Code: [Select] type  TFT_Device_Info_Node = record     Flags         : DWord;     DeviceType    : Dword;     ID            : DWord;     LocID         : DWord;     SerialNumber  : array [0..15] of AnsiChar;     Description   : array [0..63] of AnsiChar;     DeviceHandle  : DWord;   end;   TFT_Device_Info_Nodes = array[0..MaxInt div SizeOf(TFT_Device_Info_Node) - 1] of TFT_Device_Info_Node;   PFT_Device_Info_Nodes = ^TFT_Device_Info_Nodes;  var   PDevs: PFT_Device_Info_Nodes; ---------------------------------------------------------------------- Martin_fr · 2014-06-18 15:31 Quote from: tk on June 18, 2014, 04:58:30 pmSo maybe GDB has problem with pointers to big arrays, here: Afaik GDB  attempts to always allocate memory for the entire data struct (even on ptype), so yes that does not work.