Debugging GTK3 Assember lazarus / 12-Debugger ---------------------------------------------------------------------- dbannon · 2019-10-31 06:09 Hi Folks, so advice please ! I am trying to debug a problem on GTK3 that only appears on Fedora30 Gnome, I have installed Lazarus Trunk on my VM but the problems is, I think, cropping up in an assembly block. And I have no idea ! I expect the debugger to step through the assembly, line by line but it jumps around, does not seem to start at the start of routines and after some five or six apparently random jumps I get - "The debugger encountered an error when trying to run ... Cannot find bounds of current function"   In finer detail, much finer ... after a 'close' of a single blank form app, there is a seg v crash (and associated (?) memory leak report).  If I step through the code with the debugger, we get - .... we work our way down GTK3WidgetEvent, we entered here with event^.type_ set to 0, GDK_DELETE. We get to its final end; thats #1315 and then find ourselves in an Assembly window, from there we seem to do a handful of apparently random jumps and then the debugger spits the dummy - "The debugger encountered an error when trying to run ... Cannot find bounds of current function" I am assuming thats where the seg v happens but obviously not sure. I am not in any way familiar with assembly, did a module at Uni a long, long time ago. But I would expect to step through line by line. And start each time at the start of a block or routine heading. I see what look like headings to me in the assembly window, bold text with - _gtk_marshal_BOOLEAN_BOXED (61) scattered there but .... Davo ---------------------------------------------------------------------- 440bx · 2019-10-31 06:45 Quote from: dbannon on October 31, 2019, 07:09:57 am"The debugger encountered an error when trying to run ... Cannot find bounds of current function" First a necessary disclaimer: my knowledge of Linux leaves a great deal to be desired and my knowledge of gnome and GTK is close to an absolute zero.  Now that's out of the way... based on the above message, I'd suspect/speculate that the problem may be in the debug symbol tables. I suggest that, as a first try to diagnose the problem, compile the program with different  debug symbol options, on Windows, some of the options are: 1. dwarf with sets, 2. dwarf 2 and 3. stabs.  I'd try each option and see if that has any effect, that might shed some light on what is causing the problem. HTH. ---------------------------------------------------------------------- Martin_fr · 2019-10-31 09:45 Probably a gdb issue. At least the asm stepping. Though first things first... How to you step over asm? There are "asm step" buttons (you need to look up the key combo) in the asm window. Stepping normally send the default step command. GDB decides if it tries to step over a line (if it has any line info) or steps one asm step. The "asm step" command tells gdb to do one asm instruction, no matter what. You can check what the IDE sends: View > ide internals > debug output If nothing helps, try fpdebug. package LazDebuggerFp. (that is assuming you are on Lazarus trunk) ---------------------------------------------------------------------- dbannon · 2019-10-31 10:23 Oh, wow, I have been using the Lazarus IDE step button, did not even notice the ones on the assembler window. Sigh .... Will give that a try in the morning .... Thanks Martin and 440x, thanks. Davo ---------------------------------------------------------------------- dbannon · 2019-11-01 04:38 OK, while I can now step nicely through the asm code and I have increased my knowledge greatly I am no closer to solving this issue. The seg v happens at the place show in image attached. Its in the routine g_list_find, thats a Gnome thing, we have a prototype for it in /lcl/interfaces/gtk3/gtk3bindings/lazglib2 It gets a list and a pointer to some data that the routine should find in the list. But looking at the assembly code, I cannot see anything 'technical' enough to cause a crash.  It presumably lands on endbr64 code, then jumps to ~649FE9, but according to debugger, crashed a couple of steps back from there at ~640FE0 ?? This routine is being called from other gnome code, not directly from pascal code. I guess its getting either an invalid list to search or a bad pointer with data to search for.  This is all happening as the app shuts down so maybe the list is already freed ?  If the search term is not present, it should be OK, just returns a Null. I have stepped through the asm code, line by line (a lot of lines !) but never get to this routine, end up in the GTK main loop, thats strange given that the app is supposed, at this stage, to be shutting down... Any thoughts ? ---------------------------------------------------------------------- 440bx · 2019-11-01 05:00 Quote from: dbannon on November 01, 2019, 05:38:12 amAny thoughts ? Unlikely to be something really helpful but, what you got there is a simple loop that expects to be terminated by the presence of a nil pointer (presumably indicating the end of the list.)  What is happening is that the list contains a pointer that is not nil but does not point to accessible memory.  When that bad pointer is dereferenced (the statement pointed by the green arrow - current EIP) a violation occurs. You mention that the routine is not called from Pascal code but, it's possible - maybe even likely - that the contents of that list depend on something that the program has done (or is doing).  Do you know what is in the list ? and what is it that the code is trying to find ?  figuring that out may shed light on how your program affects the content of the list, hopefully leading to a solution. HTH. ---------------------------------------------------------------------- dbannon · 2019-11-01 05:23 No, sadly I have no idea of what that list is a list of.  I cannot even assume that the list everything falls over with is being accessed in the loop. Its possible it has broken out of the loop and is stepping through, eg, the list of windows to be disposed of. When I step through all the asm block, I end up in the GTK loop but by then, for whatever reason, the close seems to have been aborted, we're just going around endlessly in that GTK loop. So, I cannot get to the opcode before the fall over one, only way to get there is to let it fall over. Not useful. If I jump over the asm block, I don't even get the crash every time, maybe a 50% thing ? Very erratic .... I did find I can set break points in the asm code but it did not really work the way I'd expect. Is there some way I can inspect the values of (eg) registers like that ? Ah, the joys of debugging event driven programming ! Thanks for your interest 440bx. ---------------------------------------------------------------------- 440bx · 2019-11-01 06:04 Quote from: dbannon on November 01, 2019, 06:23:38 amIs there some way I can inspect the values of (eg) registers like that ? You can view the registers by selecting View->Debug Windows->Registers.  I normally select all the registers and set them to show in Hex (default seems to be decimal, which is often not very useful.) You could follow the values in rsi and rdi which are the registers involved in the problem and inspect/view the memory they point to (that _might_ help.)  Unfortunately, I do not know of a way to get a memory window to view the memory pointed to by a register of one's choice in Lazarus.  Under Windows, I use Process Hacker 2 to view the memory blocks I'm interested in but, obviously that is not available under Linux. If you know of a process memory viewing utility for Linux, that would be a way to inspect the memory pointed to by any register of your interest (in this case, likely rsi and rdi.) GDB has the "x" command to examine memory but, I don't know how to set things up so you can send commands to GDB from Lazarus.  I know it is possible, Martin_fr mentioned how to do it in a recent post, hopefully he can give the instructions again if you want them. Quote from: dbannon on November 01, 2019, 06:23:38 amThanks for your interest 440bx. Unfortunately, I cannot be of much help due to my rather limited knowledge of the Linux/Gnome environment.