Recent

Author Topic: [solved] Why debugging my form hangs on Ubuntu ?  (Read 3018 times)

CapelliC

  • Jr. Member
  • **
  • Posts: 58
[solved] Why debugging my form hangs on Ubuntu ?
« on: August 02, 2020, 02:18:00 pm »
I had posted previously https://forum.lazarus.freepascal.org/index.php/topic,50590.0.html about my problem, and marked it as solved, but further testing on Ubuntu 16.04 shows it again, and it's not bound to just the first debug of a new form. Will try to summarize my experience step by step, as it's quite simple. I'm using Lazarus 2.0.10, but the problem AFAIKT was the same with Lazarus 2.0.8.

Hit menu [Project / New project ...]
Select [Project / Application] from the [Create a new project] form.
Hit [OK], a new, empty form is shown.
Hit Ctrl+s, save the project and unit in a new folder (I use the [Create Folder] button top right, give the new folder the name 'x_hang', and name the project 'x_hang', the unit 'ux_hang'. This way, I have a this folder
Code: Bash  [Select][+][-]
  1. $ cd test/lazarus/
  2. $ ls -l x_hang
  3. total 296
  4. drwxrwxr-x 2 carlo carlo   4096 ago  2 13:48 backup
  5. -rw-rw-r-- 1 carlo carlo    125 ago  2 13:48 ux_hang.lfm
  6. -rw-rw-r-- 1 carlo carlo    236 ago  2 13:48 ux_hang.pas
  7. -rw-rw-r-- 1 carlo carlo 137040 ago  2 13:48 x_hang.ico
  8. -rw-rw-r-- 1 carlo carlo   1873 ago  2 13:48 x_hang.lpi
  9. -rw-rw-r-- 1 carlo carlo    407 ago  2 13:48 x_hang.lpr
  10. -rw-rw-r-- 1 carlo carlo    939 ago  2 13:48 x_hang.lps
  11. -rw-rw-r-- 1 carlo carlo 139052 ago  2 13:48 x_hang.res
  12.  

Now, in Lazarus hit F9. It does build and the empty form shows up. So far, so good.
I click the close window button (the small x top left in form caption).
Then I hit F9 again - the form does come out, but 'frozen'. It doesn't display its content (to be true, in this case it has nothing to display, but the same applies to more usual cases as well), and even the close window button doesn't work. Clicking it, Ubuntu says me 'This window is not responding' (see attachment), after I click [Force Quit] I see the [Execution Stopped] modal dialog, after [OK] I have a modal error dialog saying [Project x_hang raised exception class 'External: SIGKILL'.].

End of game, but if I click on the executable (it's x_hang, obviously), it starts and close normally...

Please forgive if there is something obvious I'm missing.

I usually works on Windows for my current customer, where this problem doesn't exist, but I value high Lazarus' portability, and cannot explain/debug the problem. Also, I would understand if the problem were tagged as 'inexplicable', because I'm the only one it's occurring. It happened me several time in the past, to find a bug that none of my coworkers incurred into, even on commercial SW. Eventually, I'll byte the bullet and install Ubuntu 20.04...

Thanks for your attention,
Carlo
« Last Edit: August 03, 2020, 08:29:36 pm by CapelliC »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Why debugging my form hangs on Ubuntu ?
« Reply #1 on: August 02, 2020, 02:54:04 pm »
Put a button on the form, with the event handler invoking close. Also try it with a different window manager (aka desktop, environment etc.). Try running both from inside the IDE, and standalone. And when you believe that the app is terminates, use ps (probably ps ax | less) to make sure it's not lurking.

I /definitely/ don't see anything like that on x86_64 Debian.

And give us adequate information: you've not even told us what processor you've got.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

CapelliC

  • Jr. Member
  • **
  • Posts: 58
Re: Why debugging my form hangs on Ubuntu ?
« Reply #2 on: August 02, 2020, 03:48:46 pm »
Thanks for the quick reply.

As I said above, the form doesn't show its content, so there is no button to push to close it.
Anyway I've placed a push button, just to be sure the form still (bad) behaves as I described. Indeed it does...

About the processor...
Code: Bash  [Select][+][-]
  1. $ lscpu
  2. Architecture:          x86_64
  3. CPU op-mode(s):        32-bit, 64-bit
  4. Byte Order:            Little Endian
  5. CPU(s):                4
  6. On-line CPU(s) list:   0-3
  7. Thread(s) per core:    1
  8. Core(s) per socket:    4
  9. Socket(s):             1
  10. NUMA node(s):          1
  11. Vendor ID:             GenuineIntel
  12. CPU family:            6
  13. Model:                 76
  14. Model name:            Intel(R) Celeron(R) CPU  N3150  @ 1.60GHz
  15. Stepping:              3
  16. CPU MHz:               2080.000
  17. CPU max MHz:           2080,0000
  18. CPU min MHz:           480,0000
  19. BogoMIPS:              3199.88
  20. Virtualization:        VT-x
  21. L1d cache:             24K
  22. L1i cache:             32K
  23. L2 cache:              1024K
  24. NUMA node0 CPU(s):     0-3
  25. Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb ibrs ibpb stibp kaiser tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat md_clear
  26.  

The system I assembled more or less 4 years ago, and used continuously from then, has 16 Gb ram, and passive cooling (the main feature I was interested at the time).

Sincerely, cannot imagine why should be relevant, but anyway... As I said, I'm open to 'unexplicable bug' explanation  :).

About the process lurking after the first close: after hit F9 in Lazarus (the form is shown, empty)
Code: Bash  [Select][+][-]
  1. $ ps ax | grep x_hang
  2. 17540 pts/19   Ssl+   0:00 /home/carlo/test/lazarus/x_hang/x_hang
  3. 17551 pts/4    S+     0:00 grep --color=auto x_hang
  4.  
after hit the close button (the x in form caption) and confirmed the kill with [Force Quit]:
Code: Bash  [Select][+][-]
  1. $ ps ax | grep x_hang
  2. 17629 pts/4    S+     0:00 grep --color=auto x_hang
  3.  
After press [OK] in the [Execution stopped] dialog box:
Code: Bash  [Select][+][-]
  1. $ ps ax | grep x_hang
  2. 17663 pts/4    S+     0:00 grep --color=auto x_hang
  3.  
After press [OK] in the Error dialog (where the message is [Project x_hang raised exception class 'External: SIGKILL'.]):
Code: Bash  [Select][+][-]
  1. $ ps ax | grep x_hang
  2. 17729 pts/4    S+     0:00 grep --color=auto x_hang
  3.  

So, it seems nothing is pending. What is shown should be the grep process itself...

CapelliC

  • Jr. Member
  • **
  • Posts: 58
Re: Why debugging my form hangs on Ubuntu ?
« Reply #3 on: August 02, 2020, 04:06:53 pm »
Have tried after a reboot, nothing changed....

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Why debugging my form hangs on Ubuntu ?
« Reply #4 on: August 02, 2020, 04:37:15 pm »
So is your OS 32- or 64-bit? Can you confirm that your Lazarus matches?

> Try running both from inside the IDE, and standalone

...and run the binary by name from a shell and report what text you see.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

CapelliC

  • Jr. Member
  • **
  • Posts: 58
Re: Why debugging my form hangs on Ubuntu ?
« Reply #5 on: August 02, 2020, 04:59:22 pm »
As I said (maybe not so clearly...), when I run the executable from the bash shell

Code: Bash  [Select][+][-]
  1. ~$ cd test/lazarus/x_hang
  2. ~/test/lazarus/x_hang$ ./x_hang
  3.  

the problem is not there. The form starts, displays its content, reacts normally to the close button in the form caption. It's somewhat related to debugging, guess...

My Ubuntu is 16.04 is 64 bits, I'm not sure what you means by '...Lazarus matches'.
I've downloaded and installed

lazarus-project_2.0.10-0_amd64.deb
fpc-src_3.2.0-1_amd64.deb
fpc-laz_3.2.0-1_amd64.deb

IIRC, the same problem was there with Lazarus 2.0.8. Sorry I don't have the relative .debs, I've dumped them when installed v 2.0.10.


Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Why debugging my form hangs on Ubuntu ?
« Reply #6 on: August 02, 2020, 08:00:23 pm »
To recap:
- The first run in the IDE debugger is fine
- The second and any further will hang.

I assume if you restart the IDE, you get another first run that will be ok?

Please generate a logfile (first/good and 2nd/hanging run, into one file)
https://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session


Once you have the logfile, you may want to try this.
Tools > Options > Debugger > General : "Reset debugger after each run"

Alternatively you can try to use FpDebug.
Install package LazDebuggerFP and change setting in Tools > Options
« Last Edit: August 02, 2020, 08:02:40 pm by Martin_fr »

CapelliC

  • Jr. Member
  • **
  • Posts: 58
Re: Why debugging my form hangs on Ubuntu ?
« Reply #7 on: August 02, 2020, 09:34:57 pm »
Have tried first to start another empty project, this time the debugger hangs even the first run.
Anyway, I've produced 2 logs, and diffed them. I'm not sure this could be the culprit, but these lines stating breakpoint-hit seem suspicious.
Code: Diff  [Select][+][-]
  1. ---
  2. >   << TCmdLineDebugger.ReadLn "=thread-group-started,id="i1",pid="4149""
  3. 1200c1177
  4. <   << TCmdLineDebugger.ReadLn "*stopped,reason="breakpoint-hit",disp="keep",bkptno="3",frame={addr="0x000000000041e740",func="SI_C_$$__FPC_LIBC_START",args=[]},thread-id="1",stopped-threads="all",core="1""
  5. ---
  6. >   << TCmdLineDebugger.ReadLn "*stopped,reason="breakpoint-hit",disp="keep",bkptno="3",frame={addr="0x000000000041e740",func="SI_C_$$__FPC_LIBC_START",args=[]},thread-id="1",stopped-threads="all",core="3""
  7. 1346c1323
  8. <   << TCmdLineDebugger.ReadLn "~"[New Thread 0x7fffeda39700 (LWP 3674)]\n""
  9.  

I don't have set breakpoints. Are those lines always set ?
The lines of first log around line 1200 say

Code: Text  [Select][+][-]
  1. ...
  2.   << TCmdLineDebugger.ReadLn "=library-loaded,id="/usr/lib/x86_64-linux-gnu/libXau.so.6",target-name="/usr/lib/x86_64-linux-gnu/libXau.so.6",host-name="/usr/lib/x86_64-linux-gnu/libXau.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff16a6e50",to="0x00007ffff16a7acc"}]"
  3.   << TCmdLineDebugger.ReadLn "=library-loaded,id="/usr/lib/x86_64-linux-gnu/libXdmcp.so.6",target-name="/usr/lib/x86_64-linux-gnu/libXdmcp.so.6",host-name="/usr/lib/x86_64-linux-gnu/libXdmcp.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff14a11d0",to="0x00007ffff14a2b38"}]"
  4.   << TCmdLineDebugger.ReadLn "=library-loaded,id="/usr/lib/x86_64-linux-gnu/libharfbuzz.so.0",target-name="/usr/lib/x86_64-linux-gnu/libharfbuzz.so.0",host-name="/usr/lib/x86_64-linux-gnu/libharfbuzz.so.0",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff1248650",to="0x00007ffff1283519"}]"
  5.   << TCmdLineDebugger.ReadLn "=library-loaded,id="/usr/lib/x86_64-linux-gnu/libdatrie.so.1",target-name="/usr/lib/x86_64-linux-gnu/libdatrie.so.1",host-name="/usr/lib/x86_64-linux-gnu/libdatrie.so.1",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff103b130",to="0x00007ffff103e5bd"}]"
  6.   << TCmdLineDebugger.ReadLn "=library-loaded,id="/usr/lib/x86_64-linux-gnu/libgraphite2.so.3",target-name="/usr/lib/x86_64-linux-gnu/libgraphite2.so.3",host-name="/usr/lib/x86_64-linux-gnu/libgraphite2.so.3",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff0e16490",to="0x00007ffff0e32065"}]"
  7.   << TCmdLineDebugger.ReadLn "~"[Thread debugging using libthread_db enabled]\n""
  8.   << TCmdLineDebugger.ReadLn "~"Using host libthread_db library \"/lib/x86_64-linux-gnu/libthread_db.so.1\".\n""
  9.   << TCmdLineDebugger.ReadLn "=breakpoint-modified,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="0x000000000041e740",at="<SI_C_$$__FPC_LIBC_START>",thread-groups=["i1"],times="1",original-location="*4319040"}"
  10.   << TCmdLineDebugger.ReadLn "~"\n""
  11.   << TCmdLineDebugger.ReadLn "~"Breakpoint 3, 0x000000000041e740 in SI_C_$$__FPC_LIBC_START ()\n""
  12.   << TCmdLineDebugger.ReadLn "*stopped,reason="breakpoint-hit",disp="keep",bkptno="3",frame={addr="0x000000000041e740",func="SI_C_$$__FPC_LIBC_START",args=[]},thread-id="1",stopped-threads="all",core="1""
  13.   << TCmdLineDebugger.ReadLn "(gdb) "
  14.   >> TCmdLineDebugger.SendCmdLn "-break-delete 2"
  15.   << TCmdLineDebugger.ReadLn "^done"
  16.   << TCmdLineDebugger.ReadLn "(gdb) "
  17.   >> TCmdLineDebugger.SendCmdLn "-break-delete 3"
  18.   << TCmdLineDebugger.ReadLn "^done"
  19.   << TCmdLineDebugger.ReadLn "(gdb) "
  20.   >> TCmdLineDebugger.SendCmdLn "-break-delete 4"
  21.   << TCmdLineDebugger.ReadLn "^done"
  22.   << TCmdLineDebugger.ReadLn "(gdb) "
  23.   DebuggerState: Setting to dsRun, from dsStop
  24.     DebugDataMonitor: TCurrentThreads.SetCurrentThreadId 0
  25.     TGDBMIThreads: >>ENTER: TGDBMIThreads.DoStateChange  New-State=dsRun
  26.     TGDBMIThreads: <<EXIT: TGDBMIThreads.DoStateChange
  27.     TIdeThreadsMonitor: >>ENTER: TIdeThreadsMonitor.DoStateChange  New-State=dsRun
  28. ...
  29.  
  30.  
Will try later to produce the log on Windows, to see if the breakpoint is present there as well. Of course, on a different platform, I don't what it could means.

CapelliC

  • Jr. Member
  • **
  • Posts: 58
Re: Why debugging my form hangs on Ubuntu ?
« Reply #8 on: August 02, 2020, 10:51:12 pm »
On Windows there are those breakpoints as well, so probably the problem is not there...

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Why debugging my form hangs on Ubuntu ?
« Reply #9 on: August 02, 2020, 11:58:07 pm »
For historical reasons (older gdb and mapping address in certain situations) there are some breakpoints set when your app is started in the debugger.
One of them is supposed to be hit at the earliest possible time. Then they all will be deleted (that seems to happen), and breakpoints at fpc_raise_exception and similar will be added. (not possible to tell, log truncated)

So the breakpoint you saw could be normal (by it being number 3, it likely is off this group).
However in order to be able to tell for sure, I need to see the log before it is hit (where this, and any other breaks are set)

And in order to say, if it is causing any issue, I would need to see the remainder of the log.


If they are part of causing the issue, there is an option that influences how they are set (they will be set, unless you have Lazarus svn trunk, which has an xtra option to disable them).
Tools >Option >Debugger : inside the property grid: "InternalStartBreak". You can test any of the available options.


I would still appreciate if you could sent the entire log. If you wish you can send it in private.
If I can figure out the details causing the problem, I might be able to add safeguards to the IDE code, so it can be detected and prevented (if possible, and also depending on how much work that would involve, and how likely it might affect more users).

CapelliC

  • Jr. Member
  • **
  • Posts: 58
Re: Why debugging my form hangs on Ubuntu ?
« Reply #10 on: August 03, 2020, 08:06:14 am »
Hi Martin
Thanks so much for taking on this problem.
Here is the log produced this morning, debugging an empty form, let me know if you need more information about my system, I'll send you by PM

CapelliC

  • Jr. Member
  • **
  • Posts: 58
Re: Why debugging my form hangs on Ubuntu ?
« Reply #11 on: August 03, 2020, 10:54:43 am »
About testing "InternalStartBreak" flags, I'll be able to do this evening

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Why debugging my form hangs on Ubuntu ?
« Reply #12 on: August 03, 2020, 02:26:42 pm »
Looking at the log, the InternalStartBreak seems to work as expected.

Then the process loads various libraries. During this process the app is terminated.
Unfortunately there is on exact location for that error.
Two possibilities come to mind though.

1)  gdb tracks loading of libraries and attempts to get extra info. In rare cases I have seen that to cause errors.
In the options/grid is an entry "DisableLoadSymbolsForLibraries" => try setting it to true.

2) Looking through the list of libraries loaded shortly before the error. As indicated there is no way (that I know) of telling which one it is.
So below are guesses:
a)
libdconfsettings => maybe you have some config/environment options in the IDE, that are passed to the debugged app and cause a problem?
b)
gio & gvfs & ibus => Does your IDE have the "double key" issue / do you have config to change ibus? Maybe that affects one of the mentioned libs? (Though strange it would be, as they would be loaded for the IDE too)



If DisableLoadSymbolsForLibraries does not help, consider trying FpDebug.

Menu Packages > Install Packages.
Find and install "LazDebuggerFp", rebuild, restart.

Menu Tools > Options > Debugger
In the dropdown (where it says "gnu debugger (gdb)", choose "FpDebug internal dwarf debugger (beta)"

CapelliC

  • Jr. Member
  • **
  • Posts: 58
Re: Why debugging my form hangs on Ubuntu ?
« Reply #13 on: August 03, 2020, 08:31:43 pm »

1)  gdb tracks loading of libraries and attempts to get extra info. In rare cases I have seen that to cause errors.
In the options/grid is an entry "DisableLoadSymbolsForLibraries" => try setting it to true.


Thanks so much.
With DisableLoadSymbolsForLibraries set to true now it's working.

Best regards, Carlo

 

TinyPortal © 2005-2018