Doing another command line tool I found that if I enable cthreads, the debugger stops working correctly.

I set -dUseCThreads or otherwise enable "use cthreads".

If I start the program with F7 I get to the "begin" in the source code but the next F7 just runs the program without a break.

If I set a breakpoint and start the program with F9 the program just runs but does not break.

I tested this with a new "Program" that just contains two writeln();

Of course everything works fine if "cthreads" is not used.

The really funny thing is that I do have (I did last week) a much more complex "program" that does not show this behavior and here stepping works just fine (of course - as discussed at some length several times before - the writeln() output is invisible when debugging).

Any idea what might be the difference between my two programs, and how I can make a new "program" work in the debugger again ?

-Michael

Michael Schnell het geskryf:

I use cthreads in our applications and it is enabled. I have no problems stepping through my program or use FPC 2.4.1 r13804 with Lazarus IDE (GTK2) v0.9.29 r23696. All 64-bit versions running on Ubuntu 8.04.2 LTS.

I tested this with a new "Program" that just contains two writeln(); Of course everything works fine if "cthreads" is not used.

Are you running the program with console output (terminal) enabled via the Lazarus IDE? If so, then breakpoints or debugging will not work at all because Lazarus IDE is then debugging the 'xterm' application instead of your application running inside that xterm session. A known bug in Lazarus IDE.

Try debugging from the command line using GDB directly.

Regards,
- Graeme -

Graeme Geldenhuys wrote

I use cthreads in our applications and it is enabled. I have no problems stepping through my program or stopping at breakpoints.

It's not "Applications", with those, I never had any problems with CThreads and debugging, either. I find these problems with "Programs" (command line tools),

Are you running the program with console output (terminal) enabled via the Lazarus IDE?

I don't think so. I just created a new "Program" to do these projects. I'll check if I find the "terminal" options somewhere. But OTOH, starting the "Program" with F7 just takes me to the "begin" line, as it's supposed to.

Try debugging from the command line using GDB directly.

I never used the command line GDB with a Lazarus program yet. I'll try to do that and come back with results,

Thanks,
-Michael

Michael Schnell het geskryf:

I'm pretty sure it is a Lazarus IDE issue - console apps with Lazarus IDE is problematic. Alternatively try MSEide, it has a built-in terminal type window to display output, so gets around the problem of debugging console applications.

> Try debugging from the command line using GDB directly. > I never used the command line GDB with a Lazarus program yet. I'll try to do that and come back with results,

I think the Lazarus wiki has a tutorial on this.

Regards,
- Graeme -

I now copied the project that works on that behalf then I replaces the content of the lpr file by that of the test-program:

========================================================
program test1;
{$mode objfpc}{$H+}
uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes
  { you can add units after this };
{$IFDEF WINDOWS}{$R test1.rc}{$ENDIF}
begin
  writeln('Test 1');
  writeln('Test 2');
end.
========================================================

And after doing this (-dUseCThreadsw was set) the debugger stopped working correctly. :(

I think the Lazarus wiki has a tutorial on this.

I'll take a look.

-Michael

OOOOPS !!!!!!

if I use libc, additionally, I can debug normally, again.

What is this ?????

I do know that the libc unit is depreciated. What should I "uses" instead ? "baseunix" does not help.

I suppose I came across a bug here. Maybe I should upgrade to a more recent FPC and Lazarus. But the new Lazarus rpm has a crc error and can't be installed :( And I don't dare to use the svn versions of Lazarus and/or FPC.

-Michael

Some more recent glibc systems no longer work correctly when libpthread is loaded dynamically while the program was not linked against it at compile time. Since I haven't seen any reactions from anyone last time I asked why we load libpthread dynamically (and only on Linux), I'll change this tonight. We only use very basic libpthread functions in the cthreads unit, so it shouldn't cause any problems (and definitely not more than are happening now).

I do know that the libc unit is depreciated. What should I "uses" instead ? "baseunix" does not help.

Add {$linklib pthread}

Jonas

PS: Please don't use so many question marks and exclamation marks.

Jonas Maebe wrote

Add {$linklib pthread}

Great !!!

That is the solution.

I did

  {$IFDEF UNIX}{$IFDEF UseCThreads}
  {$linklib pthread}
  {$ENDIF}{$ENDIF}

I suppose something like this should be added to the automatic project source code creator in Lazarus.

PS: Please don't use so many question marks and exclamation marks.

OK. :) I do this only once a year, But I was very exited about the very unexpected fact that the depreciated libc made the debugger working.

Thanks again (!)
-Michael

To be sure: remove the libc again; it can create unexpected side-effects. Just leave the {$linklib pthread}

This is actually quite strange and probably a bug in the cthreads unit. It should contain the {$linklib pthread} clause instead of loading the pthreads library manually, that's why we have this unit.

Could you file a bugreport please ?

Michael.

It already contains that, but it's explicitly disabled for Linux (and for Linux only).

Jonas

I know, I saw that. I guess that it was originally developed using dynamically loading, and was subsequently disabled for BSD...

Michael.

Michael Van Canneyt wrote

I know, I saw that. I guess that it was originally developed using dynamically loading, and was subsequently disabled for BSD...

I've changed it, but I've kept both systems for Linux: link it at compile time, but also still resolve all symbols dynamically (via dlopen, which will simply return a handle to the already loaded libpthread) so that it will still work should some of the symbols not be available.

Jonas

Michael Van Canneyt wrote

To be sure: remove the libc again; it can create unexpected side-effects. Just leave the {$linklib pthread}

Of course I did this :) .

Done. Issue ID 0015890 <http://bugs.freepascal.org/view.php?id=15890>

-Michael