Debugging under Linux (Ubuntu) is the largest development pain, and has persisted since I started cross platform development with FPC/Lazarus. I was wondering what if anything could be done to get a bug report together and submit something to either GDB or X.org, or identify the source of the problem and resolve it so we can debug without having to restart the desktop manager.

Recently, main threaded debugging doesn't crash the gdm but threading still does. If I set a break point for a threaded method, I can step two or three lines down/deep before the desktop manager hangs and I have to open a terminal session with ctrl+alt+F2 and sudo service gdm restart.

What would be involved in running the GDM under debugger and seeing where in the world it crashed? Is this too big of a task?

I noticed GDB has done some updating w/r/t FPC in the past and was wondering whose responsibility this might fall on. It seems to me like this problem is way beyond the scope of Lazarus or FPC but I hope with some noise we possibly could get some stability while debugging threaded apps.

Anyone want to help?

Op 2011-01-10 16:41, Andrew Brunner het geskryf:

I remember others complaining about this issue too. Not a solution but a possible work-around would be to run 'xnest' and debug your application inside the new display / window manager running inside xnest. That way you don't have to kill your display :0 every time the window manager freezes, but simply kill and restart xnest.

Regards,
- Graeme -

I don't understand what the problem is?

I debug 64-apps with lazarus daily ? (admittedly, without threads).

Michael.

In your case you should refine your statement:
"Debugging under Linux (Ubuntu) is the largest development pain" versus:
"threaded debugging"

While debugging threaded apps should be no special at all, it probably still is....
And so is 64 bits at current => simply due to the lack of testing it had

Also make sure your debugged app, does not have any console output itself... http://bugs.freepascal.org/view.php?id=12172

What would be involved in running the GDM under debugger and seeing where in the world it crashed? Is this too big of a task?

I don't know what makes the x server hang, so I can't help you much on that...
Also if gdb itself crashes....

But to get you some info; as for the lazarus side: Compile the IDE with
-dDBG_VERBOSE -dDBGMI_QUEUE_DEBUG

and start it from a console, so you can see the IDE's debug output.

That way you will get all the communication between the IDE and gdb; including some warnings, and state info. (You will see if the IDE thinks the app is pause or running => if that differs from the real state, then obviously there is an issue)

If you get it to work in gdb by hand, and find out what Lazarus needs to to different....

-------------
You can also compile the IDE with
-dDBG_WITH_DEBUGGER_DEBUG
this will add an edit field and button to the "debug output" window. So you can test gdb commands from the IDE.
BUT this is low level, and not guarded => this allows you to screw up the debug session, and it is supposed to allow you to do this... This is to develop on the debugger integration, not to debug an app. = > You must not / never issue a command that will change between run/pause state => as the IDE will not update it's internal state => and once you got them out of sync, you can only start killing stuff the hardcore way.

I didn't mean to say that there definitely was one. Just likelihood is bigger.

not all versions of gdhb seem to like it... At least on windows there was an issue with the 64bit imagebase. but afaik the very latest gdb deals with it.

As for testing, several blocking issues where fixed in Lazarus in Nov/Dec 1010 => many addresses, including some breakpoints where handled as 32 bits => that must have prevented some features from working. Again that is fixed....

But all in all Lazarus 32 bit debugging (and gdb too) has been there much longer than 64 bit => so it had more testing. I wouldn't be to surprised if there still are 64 bit issues left (but I don't know of them...)

---
Another issue are 64 bit Macs to all apparence => because Lazarus users are bound to use 32 bit code, and that seems to be an other source of problems => or maybe it;'s the special gdb version that apple supplies, or.....

Ah, yes.

Well, since I exclusively work on Linux 64-bit, debugging works fine for me.

Michael.

Well, since I exclusively work on Linux 64-bit, debugging works fine for me.

Well, if you just use the application thread I didn't have many problems there in a while. My issues are with debugging the threaded network engine - when data arrives - app stops @ break point - I get to trace two or three lines (typically at least one method in from where I set bp) - and the entire desktop locks up.

I have no problems with debugging the GUI app where the main application thread is used. This problem is thread specific.

What happens if you kill Lazarus/gdb/your application when the desktop freezes? Do you really have to restart gdm?

Joost

Joost van der Sluis wrote

What happens if you kill Lazarus/gdb/your application when the desktop freezes? Do you really have to restart gdm?

Most of the times, nothing but ctrl+alt+f2 responds. The entire desktop goes into a halted state. Other times the entire laptop hangs and I have to hold the power button down.

The only reason why I have to maintain windows here is because of debugging. And I recently added a mechanism into the server that contains code that required testing and I must have restarted the desktop manager like 200 times... One time for each line of code :-o

So during times of heavy developmental changes this problem is severe but I've been mitigating the issue by testing under Window. The reason why I bring this up is that I recognize that XP is probably going to be fazed out and now that I've upgraded my laptop (ssd) XP won't let me install it. Which limits my options. I suppose I'll have to create a VirtualBox with XP on it.

Yes, but then you have a new terminal, in which you can kill your application/lazarus gdb. (try killall -9 gdb) That probably restores your desktop responsibility.

Other times the entire laptop hangs and I have to hold the power button down.

Most often it is also possible to use ssh to connect to the machine and kill some processes.

Joost.

Andrew Brunner wrote

have to create a VirtualBox with XP on it.

I can attest to this being a good idea. virtualbox is fantastic.

~D.

No no no. Don't use kill -9.
It doesn't give the process a chance to cleanly:
1) shut down socket connections
2) clean up temp files
3) inform its children that it is going away
4) reset its terminal characteristics
and so on and so on and so on.

Generally, send 15, and wait a second or two, and if that doesn't work, send 2, and if that doesn't work, send 1.

Don't use kill -9. Don't bring out the combine harvester just to tidy up the flower pot.

from http://partmaps.org/era/unix/award.html#uuk9letter

As for killall...

http://mywiki.wooledge.org/ProcessManagement#How_do_I_kill_a_process_by_name.3F__I_need_to_get_the_PID_out_of_ps_aux_.7C_grep_.... http://mywiki.wooledge.org/ProcessManagement#line-81

Op 2011-01-10 17:40, Andrew Brunner het geskryf:

problems there in a while. My issues are with debugging the threaded network engine - when data arrives - app stops @ break point - I get

It's not perfect, but I had great success debugging our threads using tiOPF's tiLog unit. You can specify one or more output methods (console, event log, file, GUI etc). I specify a log file, then simply filter that log file lines using the thread ID I am interested in. tiOPF's logging ability is multi-thread aware, does cached logging to file, gui etc (not console).

http://www.tiopf.com/
http://wiki.freepascal.org/tiOPF

Regards,
- Graeme -

I had the same problem and solved it by using DebugLn from lclproc unit. It is uncomfortable but is is working. Or just using a few Writeln and run program from console to see what is happening.

Petr

Dne 10.1.2011 15:41, Andrew Brunner napsal(a):

Setting Project Options -> Compiler Options -> Linking -> Debugging: Check Use external gdb debug symbols file (-Xg) stops my desktop from hanging. Do not ask me why.

http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#Linux

Latest Ubuntu with Gdb 7.2 is working great for main threaded apps. But I still have an issue where GDB freezes my Desktop entirely.

But I have a much better work around than my previous finding of sudo service gdm :-)

The fix is to kill gdb and the entire session comes back.

So ctrl+alt+f2
sudo ps -A // all jobs (required since this is different terminal) look for process id of GDB
kill -9 proces_number_of_gdb

After killing the gdb the desktop comes back and I can restart the process. Someone with GDB source needs to debug the GDB with a multi-threaded app in lazarus. Is this at all possible? Seems like a classic deadlock case to me.

But someone should update the wiki - this was much quicker and safer than restarting the desktop manager.

I replaced that.

http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#Linux

Mattias