Hello, General mailing list.

Lazarus 0.9.26 is coming. We have made all the main changes we wanted to make. We spent the last couple of days on bug fixing. We have fixed many issues, but we are not sure we have fixed all regressions. It would be sad to release a version, that you cannot use.

Thus we kindly ask you to test our latest snapshots at http://www.hu.freepascal.org/lazarus/ or (better) the svn version. Please, check your work projects, run tests, play with the IDE, do crazy things. And if you find a regression, let us know through the bug tracker at http://bugs.freepascal.org/ .

Lazarus 0.9.26 will not be released with regressions (new errors, things that worked in 0.9.24), *if* we know about them. If there are no more regressions, we will release in one or two weeks. After the release it will be too late to bash us for regressions. So grab this opportunity.

The Lazarus team.

Hurray!

Are you halting SVN development on anything that is NOT supposed to be for 0.9.26? Ie... If there is no regressions, will this be the same as the final 0.9.26? (Except for the version number that will get onto the LFM files).

No, there are few bugs to fix in the bug tracker. But they are not very important. Also boys on russian forum doing their testing and already found few bugs.

But if you asking about features then yes - we will not do any new features before 0.9.26 release.

Best regards,
Paul Ishenin.

Paul Ishenin wrote

Thus we kindly ask you to test our latest snapshots at http://www.hu.freepascal.org/lazarus/ or (better) the svn version.

Regression Bug #1:
The "editor toolbar" package doesn't allow to be configure. This was caused since the bitmap (graphics) rewrite. The package installs fine into the IDE (like it did in previous versions), but if you click on the configure button you get the following error:
"TGlyphBitmap: Unsupported ResourceType: XPM"

I wrote the editor toolbar package, but I have no idea what to do about this error. Could you help?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Hi,

OK, I tested this last week and it didn't work. I just got an update now - using r16425 i386-linux-gtk, and the Configure button seems to work again.

I guess it was fixed in the last few days. :-) Could somebody confirm this ? that it's working on other systems as well?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Hi Paul,
May I suggest
http://bugs.freepascal.org/view.php?id=12041
Is added to the list of failed regressions. as this was working earlier 0.9.25 builds.

Thanks,

Dominique.

Lazarus 0.9.26 is coming. We have made all the main changes we wanted to make. We spent the last couple of days on bug fixing. We have fixed many issues, but we are not sure we have fixed all regressions. It would be sad to release a version, that you cannot use.

Does 0.9.26 also target Carbon as default widget for Mac? Or does it still use gtk (and x) for the default widget for Mac?

I do use Lazarus on Mac intel with Carbon on daily basis. I got some things to be reported. I planned to report them. It'd be great if next Lazarus would be using Carbon for Mac.

-Bee-

Paul Ishenin wrote

Thus we kindly ask you to test our latest snapshots at http://www.hu.freepascal.org/lazarus/ or (better) the svn version.

Using Lazarus v0.9.25 r16425M i386-linux-gtk

Bug #2:
When pressing the keyboard shortcut to bring up the "Goto Line number" dialog, all other opened windows (Project Inspector, used Packages etc), flicker like crazy. It's as if all the other dialogs get a "bring to front" and then a "sent to back" action.

This doesn't just happen when I open the "Goto line number" dialog. It happens with any "popup" dialog, like (Ctrl+F) for Search dialog; (Ctrl+Shift+D) for Conditional Defines dialog, etc... Any "popup" dialog, causes all other open dialogs to flicker (as previously described).

It doesn't seem to be related to my choice of window managers either. I tested it under both Gnome and FVWM. Same behaviour. This also started happening in the last few svn updates (week or two back)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Dominique Louis ?????:

Yes, done.

Best regards,
Paul Ishenin.

Graeme Geldenhuys ?????:

I fixed that earlier. Please use bug-tracker if you find something. And please update oftenly :) Mail list is a bad tracker of issues.

Best regards,
Paul Ishenin.

Hi Bee,
If I'm not mistaken Lazarus is not natively Carbon in the overnight snapshots. I'm using SVN and build it as Carbon, but I remember reading somewhere that it would native Carbon in the snapshots a few months back.

Dominique.

Dominique Louis wrote

Hi Bee, If I'm not mistaken Lazarus is not natively Carbon in the overnight snapshots.

I think you are mistaken, I try to build them as Carbon. If they are not, then there is a critical bug in the building system.

Vincent

Reported in Mantis as:
http://bugs.freepascal.org/view.php?id=12065

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

If I'm not mistaken Lazarus is not natively Carbon in the overnight snapshots. I'm using SVN and build it as Carbon, but I remember reading somewhere that it would native Carbon in the snapshots a few months back.

I don't know about snapshots. Since the first day I read that Lazarus IDE supported Carbon, I always used SVN and build the IDE from source. And yes, it works natively on Carbon. Not quite stable, though it's pretty much usable. ;)

-Bee-

Yikes, the "not natively" was supposed to say "now natively"!!!

Sorry about the misunderstanding.

Dominique.

Vincent Snijders wrote

I think you are mistaken, I try to build them as Carbon. If they are not, then there is a critical bug in the building system.

One other question, does the snapshot ship with cross-compilation as well ( at least on i386 )?

Dominique.

About the snapshots...

How long do they stay there? I want to "schedule" a download, but don't want the file to dissappear whilst downloading it.

I doubt that'll be a problem though.

Regards,
-Reenen

On Fri, Sep 5, 2008 at 12:28 PM, Dominique Louis <

Bee wrote

Does 0.9.26 also target Carbon as default widget for Mac? Or does it still use gtk (and x) for the default widget for Mac?

0.9.26 will be released with Carbon, but the Carbon bugs will not stop the release.

Dominique Louis wrote

One other question, does the snapshot ship with cross-compilation as well ( at least on i386 )?

Yes. For i386 -> powerpc cross compilation. FPC doesn't support the other way around, because of missing extended (80 bits float) on powerpc.

Vincent

Reenen Laurie wrote

About the snapshots... How long do they stay there? I want to "schedule" a download, but don't want the file to dissappear whilst downloading it.

On most snapshot servers, they keep one version of the file, which stays until the next day's snapshot is added approximately 24 hours later.

On the French mirror files are kept for a week:
http://snapshots.lazarus.shikami.org/lazarus/downloads/

I doubt that'll be a problem though.

Maybe if you are using download accelerrators, that download the file in pieces.

Vincent

How long do they stay there? I want to "schedule" a download, but don't want the file to dissappear whilst downloading it.

Why not just use the SVN? IMO, it's lot easier rather than using snapshots. Whenever there is a revision that broken, you can simply revert it to the previous working revision. Compiling from source is very simple.

-Bee-

Le Sep 5, 2008 ? 5:01 PM, Bee a ?crit :

I can assure you, you don't want that :)
Snapshots are binaries, and big binaries. around 400Mo each day

Subversion is not scaled for that. A RSync like eventually.

Maybe we need to point lazarus users to some build manual (if exists) or create one (in other case).

But indeed building from svn is very easy:
- to clean and build ide without external components: make clean all
- to clean and build ide with some external component: make clean bigide
- to clean and build ide with all user component: make clean idepkg

Nothing more and no need to download 40mb of snapshots every day. And also no need to reinstall that snapshots.

Best regards,
Paul Ishenin.

Le Sep 5, 2008 ? 5:15 PM, Damien Gerard a ?crit :

Sorry I completely missed the point :) I need more coffee ^^

Please, see http://bugs.freepascal.org/view.php?id=12030

TDBImage is very usefull in simple db applications.

2008/9/5 Damien Gerard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080905/6aefa652/attachment.html

Maybe we need to point lazarus users to some build manual (if exists) or create one (in other case).

It's already there, on the wiki. :)

But indeed building from svn is very easy: - to clean and build ide without external components: make clean all - to clean and build ide with some external component: make clean bigide - to clean and build ide with all user component: make clean idepkg

Yup. I event made a simple script to automate the whole processes from updating my local SVN, make clean all, make install. It's done. If I run Lazarus after that, I have the latest Lazarus in front of me. Of course, if the whole processes are successful. Even if the new update is broken, I simply re-run the script to revert my SVN to the last working revision (if I remember the rev number). :-D

Nothing more and no need to download 40mb of snapshots every day. And also no need to reinstall that snapshots.

Exactly! That's why I wonder if there's regular users of Lazarus (not newcomers that come to try and leave) that still download 40mb of snapshots every day. :-D

-Bee-

No, I wasn't going to download 40mb every day (or even almost every day).

I was just considering downloading the snapshot from my work's bandwidth... but i'd rather just update my SVN on my linux machine and await 0.9.26 for windows.

That's why I want to have the 2 on the flash disk (if you see my other post).

Regards,
-Reenen

http://bugs.freepascal.org/view.php?id=11768

Scrolling with the mouse wheel can affect more than one window.

From short testing this seems to be a regression too. I can reproduce this, but only with SVN.
0.9.24 is not affected.

I have found some more info.

Assume the following layout: (O Object inspector / S Synedit / M MainBar)

MMMMMMMM
OO SSSSSSS
OO SSSSSSS
OO SSSSSSS
OO SSSSSSS

If the mouse is over the Synedit (relative X=50 y=90) and the absolute screen coordinate (50/90) is over the objInspector (a scrollable part of the oi, like the grid)

then the grid will scroll together with synedit.

in C:\lazarus_latest\lcl\interfaces\win32\win32callback.inc line 1803 ++

   WM_MOUSEWHEEL:
    begin
...
      with LMMouseEvent Do
      begin
        X := GET_X_LPARAM(LParam);
        Y := GET_Y_LPARAM(LParam);
        // check if mouse cursor within this window, otherwise send
message to window the mouse is hovering over
        P.X := X;
        P.Y := Y;
.......
        Windows.ScreenToClient(TargetWindow, P);

This last line seems to somehow be guilty

I observed the following, (with a breakpoint on this code)

- first entry:
X/Y GET_X_LPARAM are the screen coordinates

- 2nd entry
X/Y GET_X_LPARAM are the relative coordinates, as after the last Windows.ScreenToClient(TargetWindow, P);

I'll see if I can find more, but maybe someone more closer to the code, can use the above to more quickly find the issue

Can you find the exact svn revision number?

Mattias

Mattias Gaertner wrote

Can you find the exact svn revision number?

The problem is on my work PC. I'll try and find the exact revision on Monday.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Environment:
Ubuntu 8.04.1
XFCe
FPC 2.2.3
Lazarus r16444
GTK2
----------------------------------
Problem:
Tstream.readansistring is not ok!

affected:

TDBImage
Lazreport

------------------------------------------------------------------------
procedure TForm1.Button3Click(Sender: TObject);
var
st : Tstream;
s : string;
gc       : TGraphicClass;
AGraphic : TGraphic;
begin
gc := nil;
AGraphic := nil;
st := FBDataSet.CreateBlobStream(FBDataSetIMAG_IMAGEM,bmRead);
s := st.ReadAnsiString;
	try
          gc := GetGraphicClassForFileExtension(s);
          if assigned(gc) then // gc is never assigned
            begin
            AGraphic := gc.Create; // never executed
            AGraphic.LoadFromStream(st); // never executed
            Image1.Picture.Assign(AGraphic); // never executed
            end;
        finally
          if assigned(AGraphic) then
          AGraphic.Free;
          st.Free;
        end
end;

IMHO you should never do this.
ReadAnsiString expects the first 4 bytes to be the length of the ansistring. If the blob contains raw image data, then this will not give a valid string.

Michael.

If you want to convert raw data to a string you should assign the stream holding the data to a TStringStream.

ReadAnsiString can only read data written with WriteAnsiString (or if you took care to imitate it's format).

Thanks for all. Sorry my insistence.

Please see this code, it is original, it is in
http://fpc64.firmos.at:8060/browse/Lazarus/trunk/lcl/include/dbimage.inc?r1=9243&r2=10681

See, here, line 161:
161+ GraphExt := s.ReadAnsiString;
My picture is a jpeg image saved on a firebird database. GraphExt do not receive the extension as expected. So, this code never executed becose gc is never assigned in "gc := GetGraphicClassForFileExtension(GraphExt);":

          if assigned(gc) then            begin            AGraphic :=
gc.Create;            AGraphic.LoadFromStream(s);
            Picture.Assign(AGraphic);            end;

==================================

88132 procedure TDBImage.LoadPicture; [image:
<]<http://fpc64.firmos.at:8060/browse/Lazarus/trunk/lcl/include/dbimage.inc?r1=9243&r2=10681#seg7>[image:

]<http://fpc64.firmos.at:8060/browse/Lazarus/trunk/lcl/include/dbimage.inc?r1=9243&r2=10681#seg9>

133+
134+var s : Tstream; 135+ GraphExt : string; 136+ gc : TGraphicClass; 137+ AGraphic : TGraphic; 138+ 89139 begin [image:
<]<http://fpc64.firmos.at:8060/browse/Lazarus/trunk/lcl/include/dbimage.inc?r1=9243&r2=10681#seg8>[image:

]<http://fpc64.firmos.at:8060/browse/Lazarus/trunk/lcl/include/dbimage.inc?r1=9243&r2=10681#seg10>

90 - if not FPictureLoaded 91 - and (not Assigned(FDataLink.Field) or FDataLink.Field.IsBlob) then 92 - Picture.Assign(FDataLink.Field); 140
+ if not FPictureLoaded then 141+ begin 142+ FUpdatingRecord := True; 143+ if not assigned(FDatalink.Field) then Picture.Assign(FDatalink.Field) 144+ else 145+ if FDatalink.field.IsBlob then 146+ begin 147+ if FDatalink.field is TBlobField then 148+ begin 149+ if FDatalink.Field.IsNull then 150+ begin 151+ Picture.Clear; 152+ exit; 153+ end; 154+ s := FDataLink.DataSet.CreateBlobStream(FDataLink.Field,bmRead); 155+ if s.Size = 0 then 156+ begin 157+ Picture.Clear; 158+
exit; 159+ end; 160+ try 161+ GraphExt := s.ReadAnsiString; 162+

  163+          gc := GetGraphicClassForFileExtension(GraphExt);

164+
if assigned(gc) then 165+ begin 166+ AGraphic := gc.Create; 167+ AGraphic.LoadFromStream(s); 168+

  169+            Picture.Assign(AGraphic);   170+            end;

171+
finally 172+ if assigned(AGraphic) then AGraphic.Free; 173+
s.Free; 174+ end {try} 175+
176+ end 177+ else 178+
Picture.Assign(FDataLink.FField); 179+ 180+ end; 181+ FUpdatingRecord := False; 182+ end;
93183 end; 94184

==================================

2008/9/6 Felipe Monteiro de Carvalho

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080906/8b5c357e/attachment.html

The TDBImage code will work only if the image is added to the TDataset through a TDBImage control (it stores the extension before the image data). If the image is added through TGraphicField/TBlobField it will not work since it stores only the image data.

Good luck.

Luiz

This is also a Delphi (issue?) feature iirc.

Joao Morais

We use Lazarus 0.9.24 (mostly under Windows Vista) in our first-year programming education. It replaces Delphi 7, which we used in previous years, but which is no longer available to us.

There have been a number of problems, which are quite upsetting for beginning users.

Some of the issues have been hard to pinpoint exactly.

I have made a FAQ for our students to assist them in getting to grips with some problems. See

<http://www.win.tue.nl/~wstomv/edu/lazarus/>

It would be most helpful if the next Lazarus release behaves "more predictably". I have not yet tested 0.9.25 (for lack of time; I will see if I can find someone to do this for me).

However, here are some of these issues:

1. When the Environment > Environment options ... > Window > "Hide IDE windows on run" is checked, it would still be convenient (and expected) to get those windows back when single stepping through a program.

2. When running a program that produces a run-time error, a dialog window comes up stating that it cannot find system.inc (or such) and asks if you wish to look for it. (This happens in a default installation

     of the 0.9.24 release; apparently some path is not properly set;
     the FPC sources have been installed and are available.)

3. All too often Run fails (could be a Vista problem), and if one does not reset the debugger, the program will hang altogether.

Resetting the debugger after each run (even if the program was confirmed by the IDE to be stopped) is needed (and enough) to guarantee "proper" operation. But this is quite cumbersome.

It is not clear to me what is happening here. At this moment we work with console applications (no GUI). When a program is run, it can happen that the command window opens, but no output appears, and the program seems stuck.

4. Similar to 2. above, the first Step Over will ask you to locate system.inc. Step Over should not dive into system to stop there.

Actually, I would not expect the first Step Into to dive in the system routines and attempt to stop there, either.

Step Out would also be useful.

5. While stepping through a program, pointing at a variable in the Source Editor will not work reliably to show the variable's value. For some occurences of the variable it works, for others not. And for another variable it works for all occurrences (as expected). Using the Watch List is a workaround, but not convenient.

6. A few of the (around 80) Lazarus installations fail to work reliably. Even reinstallation did not help. Could this be a Vista-related problem?

7. Not easily solvable in the short term: the help system is too incomplete and erratic in coverage and requires web access in the default configuration.
N.B. Our students will not have web access when doing an exam for this course!

There are further issues, but these were attracting most attention.

Feedback would be appreciated.

Best regards,

Tom

My shortcuts in mainmenu do not ok!

Menu caption: &Menu1

but Alt+m or Alt+M not go!

2008/9/5 Paul Ishenin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080907/37538a9b/attachment.html

The problem is that there is no simple way to locate the correct include file.
I have an idea for a heuristic using an index. I don't know if I find the time to implement that soon.

[...]

Mattias

I've just cached the same error on WinXP Home.
Why not trying the default installation position first? Then using the supplied path and so on...

We are using Lazarus in an High School here in Italy with the very same usage problems pointed by Tom.

We are actually trying to use Lazarus as an ide for free pascal (not OO). We find it clumsy to create a project with a standard console program with .pas source code (create project, delete source and insert a blank .pas file in the project)...

On the other hand...it's a beautiful ide!!!

Sorry, my environment:
Ubuntu 8.04.1
FPC 2.2.3
Lazarus r16444 GTK2

Shortcuts in menu (mainmenu) do not act.

Like this: &File --> Alt+F

2008/9/7 Osvaldo Filho

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080908/ec79df1e/attachment.html

Marco Ciampa schreef:
We are actually trying to use Lazarus as an ide for free pascal (not OO).

We find it clumsy to create a project with a standard console program with .pas source code (create project, delete source and insert a blank .pas file in the project)...

Do you choose, Project -> New -> Program?

How would you perfect console application template look like?

Vincent

Vincent Snijders wrote

Do you choose, Project -> New -> Program? How would you perfect console application template look like?

If the default as mentioned above is not good enough, then install the Templates Package (I think it's going to be installed by default in the next release). You can then setup whatever template projects you want.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

For teaching it might be useful if the IDE starts with the template instead of the default 'new application'.
Maybe the checkbox 'open last project on start' should be extended with the possibility to select which project type to use on start.

Mattias

En/na Paul Ishenin ha escrit:

But indeed building from svn is very easy: - to clean and build ide without external components: make clean all

ok, this works

- to clean and build ide with some external component: make clean bigide

I'm currently under linux and it works, but IIRC I couldn't make it work under windows (maybe it was just a broken svn revision, I don't know)

- to clean and build ide with all user component: make clean idepkg

Never works after an svn update (btw, if you make clean it's *not* supposed to work, it's either "make idepkg" after "make clean all" or "make clean all idepkg"), however: under windows the configuration files (idepkg.cfg and another one I don't remember) are in the user profile and the makefile doesn't find them, once copied in the correct place (under linux they are already) the compilation fails. I *always* have to use "make clean all" and the use the ide itself to get my components.
E.g., currently under linux:

make clean all idepkg LCL_PLATFORM=gtk2

(first compilation of lazarus ok, enter the idepkg stage)

Compiling lazarus.pp
PPU Loading /home/luca/lazsvn/lazarus/components/rx/lib/apputils.ppu PPU Source: apputils.pp not found
Recompiling AppUtils, checksum changed for Grids
apputils.pp(74,12) Fatal: Can't find unit AppUtils used by rx Fatal: Compilation aborted
make[2]: *** [lazarus] Error 1
make[2]: se sale del directorio `/home/luca/lazsvn/lazarus/ide' make[1]: *** [idepkg] Error 2
make[1]: se sale del directorio `/home/luca/lazsvn/lazarus/ide' make: *** [idepkg] Error 2

(It may well be another unit)
Of course if I open the ide, rebuild my packages and *then* I "make idepkg" it works (since all units don't need to be recompiled), but what's the point?

Another gripe I have with svn, is that if I do an svn diff right after an update, all Makefile and Makefile.fpc, as well as many po files, are different, so I have to delete them and svn update again.

And the last one is the lrs files: since they should be generated by the lfm, why oh why are they under svn? (well, I know, because lazarus doesn't generate them automatically, but I think it should)

Bye

Delphi allows to set:

- The default project type
- Default main form
- Default new form.
(In the menu, select "Tools - Repository". Choose object that you want and set the appropriate checkbox)

I think this is a useful feature :-)

Michael.

An embedded and charset-unspecified text was scrubbed... Name: not available
Url: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080908/39dd22dd/attachment.pl

Sure. You can do that in delphi: right-click in the 'File - New' dialog, and you can select 'properties', which then takes you to the same dialog as 'Tools - Repository' does.

What features has Tools / Repository under Delphi?

Basically the above, and it allows to 'customize' the tree in File|New.

The repository is something like the 'project templates', but a bit standardized. It just copies a file from a designated directory, and renames the object inside. (that's of course a very rough description)

Michael.

What's the preferred FPC version for this?

You can use FPC 2.2.2.

make clean all
make clean all bigide

Don't use 'make idepkg' unless you know what you are doing. To build the IDE with packages use:

./lazbuild -B --build-ide=

Mattias

En/na Mattias Gaertner ha escrit:

Finally I know the magic incantation ;-)
however I had to add a "--widgetset=win32" under windows, otherwise it would fail compiling some gtk1 stuff.
Oh, and it didn't rename lazarus.new.exe to lazarus.exe.

Bye

En/na Luca Olivetti ha escrit:

No comments on these 2 issues?

Bye

How can make generate them?

Vincent

Luca Olivetti wrote

> Another gripe I have with svn, is that if I do an svn diff right after > an update, all Makefile and Makefile.fpc, as well as many po files, are > different, so I have to delete them and svn update again.

a simple: svn revert -R
should fix the issue. I don't really get that issue, but sometimes do with translation files (*.po), but I think they are auto generated in some make clean/build process, so I don't worry to much about it.

Note:
That will revert all local changes to *your* latest svn revision.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

En/na Vincent Snijders ha escrit:

I don't know, I'm not familiar enough with make, maybe it could be possible to first building an lfm to lrs converter, then using it to generate lrs files.
Anyway, I don't like the idea of having files in a SCM that are directly generated by other files (and, btw, could get out of sync). It appears that the same is happening with (at least some) of the Makefiles (they differ from the svn once you try and build the ide with your full set of components, using, e.g., lazbuild), i.e. they are somewhat regenerated during the build process.

Bye

An embedded and charset-unspecified text was scrubbed... Name: not available
Url: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080911/2edcccc8/attachment.pl

En/na Graeme Geldenhuys ha escrit:

Yes, I just found that it only happens if I rebuild lazarus from inside the ide.

Bye

En/na Luca Olivetti ha escrit:

It appears that the same is happening with (at least some) of the Makefiles (they differ from the svn once you try and build the ide with your full set of components, using, e.g., lazbuild)

Correction: it only happens if you rebuild lazarus from inside the ide.

Bye

En/na Mattias G?rtner ha escrit:

Done
http://bugs.freepascal.org/view.php?id=12124

Thank you!

Bye

lazarus-0.9.25-20080828 compiles and runs OK on NT4 SP6a and Linux (Debian "Sarge"). Compiler in both cases was FPC 2.2.2 on i386 using "make clean bigide".

Compiles for Linux (Debian "Etch") on SPARC using FPC 2.2.3 using either "make clean all" or ...bigide". However in this case the IDE runs but raises an exception while loading a project and/or closing an existing form. I need to check whether this fails with 2.2.0 of the compiler and with 2.2.3 with optimisation disabled since it might be a symptom of a known issue.

I'm trying to find time to test it running natively on ARM (little-endian) under Linux but am having a lot of difficulty fitting jobs into the available time.

I can confirm that 0.9.25 is broken on SPARC/Linux using 2.2.3 both with and without optimisation, and using 2.2.0 which successfully built 0.9.24.

What do I need to do or provide to help resolve this? Can somebody point me at any notes on generating backtraces for Lazarus or whatever's necessary?

http://wiki.lazarus.freepascal.org/Creating_a_Backtrace_with_GDB

Vincent

I think what I needed to know was that Lazarus is already compiled with debugging info etc.- somebody please correct me if I'm wrong and it needs additional options.

Using lazarus-0.9.25-20080828 compiled with FPC 2.2.0 which I believe is robust on SPARC, hosted on Debian "Etch" with KDE on an Ultra-60, I get:

(gdb) run
Starting program: /usr/local/share/lazarus-0.9.25/lazarus [Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 31206)]

Gdk-CRITICAL **: file gdkgc.c: line 502 (gdk_gc_set_function): assertion `gc != NULL' failed.

Gdk-CRITICAL **: file gdkdraw.c: line 381 (gdk_draw_pixmap): assertion `gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 288 (gdk_gc_unref): assertion `gc != NULL' failed.
TMainIDE.ParseCmdLineOptions:
PrimaryConfigPath="/home/markMLl/.lazarus"
SecondaryConfigPath="/etc/lazarus"
NOTE: miscellaneous options file not found - using defaults NOTE: codetools config file not found - using defaults NOTE: help options config file not found - using defaults TMainIDE.DoNewProject A
TCustomFormEditor.CreateComponent Form1:TForm1 False TMainIDE.DoNewEditorFile END unit1.pas

Program received signal SIGBUS, Bus error.
[Switching to Thread 16384 (LWP 31206)]
0x001821d0 in TPEN__FREEREFERENCE (this=0xf6f10430) at pen.inc:230 230 pen.inc: No such file or directory.
in pen.inc
(gdb) backtrace
#0 0x001821d0 in TPEN__FREEREFERENCE (this=0xf6f10430) at pen.inc:230 #1 0x001823e8 in TPEN__SETCOLOR (NEWCOLOR=8421504, NEWFPCOLOR= {RED = 32896, GREEN = 32896, BLUE = 32896, ALPHA = 65535}, this=0xf6f10430) at pen.inc:269
#2 0x00181ac4 in TPEN__SETCOLOR (VALUE=8421504, this=0xf6f10430) at pen.inc:47
#3 0x00167554 in TCUSTOMTREEVIEW__DOPAINT (this=0xf6fd12a0) at treeview.inc:4031
#4 0x00163a50 in TCUSTOMTREEVIEW__PAINT (this=0xf6fd12a0) at treeview.inc:2999
#5 0x001e862c in TCUSTOMCONTROL__PAINTWINDOW (DC=-144883680, this=0xf6fd12a0) at customcontrol.inc:127
#6 0x001ce9bc in TWINCONTROL__PAINTHANDLER (THEMESSAGE= {MSG = 66592, DC = -144883680, PAINTSTRUCT = 0xf6f15430, RESULT = 0}, this=0xf6fd12a0)
at wincontrol.inc:4239
#7 0x001d432c in TWINCONTROL__WMPAINT (MSG=
{MSG = 66592, DC = -144883680, PAINTSTRUCT = 0xf6f15430, RESULT = 0}, this=0xf6fd12a0)
at wincontrol.inc:6043
#8 0x001e8514 in TCUSTOMCONTROL__WMPAINT (MESSAGE= {MSG = 66592, DC = -144883680, PAINTSTRUCT = 0xf6f15430, RESULT = 0}, this=0xf6fd12a0)
at customcontrol.inc:107
#9 0x0002ca78 in SYSTEM_TOBJECT_$__DISPATCH$formal () #10 0x001ddec0 in TCONTROL__WNDPROC (THEMESSAGE=
{MSG = 66592, WPARAM = -144883680, LPARAM = -151956432, RESULT = 0, WPARAMHI = 63325, WPARAMLO = 16416, LPARAMHI = 63217, LPARAMLO = 21552, RESULTHI = 0, RESULTLO = 0}, this=0xf6fd12a0) at control.inc:1583 #11 0x001d070c in TWINCONTROL__WNDPROC (MESSAGE=
{MSG = 66592, WPARAM = -144883680, LPARAM = -151956432, RESULT = 0, WPARAMHI = 63325, WPARAMLO = 16416, LPARAMHI = 63217, LPARAMLO = 21552, RESULTHI = 0, RESULTLO = 0}, this=0xf6fd12a0) at wincontrol.inc:4749 #12 0x00166cd4 in TCUSTOMTREEVIEW__WNDPROC (MESSAGE= {MSG = 66592, WPARAM = -144883680, LPARAM = -151956432, RESULT = 0, WPARAMHI = 63325, WPARAMLO = 16416, LPARAMHI = 63217, LPARAMLO = 21552, RESULTHI = 0, RESULTLO = 0}, this=0xf6fd12a0) at treeview.inc:3884 #13 0x002ff950 in DELIVERMESSAGE (TARGET=0xf6fd12a0, AMESSAGE=void) at gtkproc.inc:3547
#14 0x0030ed48 in DODELIVERPAINTMESSAGE (TARGET=0xf6fd12a0, PAINTMSG= {MSG = 66592, DC = -144883680, PAINTSTRUCT = 0xf6f15430, RESULT = 0}) at gtkcallback.inc:50
#15 0x002e839c in TGTKWIDGETSET__SENDMESSAGE (HANDLEWND=14639848, MSG=66659, WPARAM=-153244864, LPARAM=28,
this=0xf7734020) at gtkwinapi.inc:8159
#16 0x002c4adc in TGTKWIDGETSET__APPPROCESSMESSAGES (this=0xf7734020) at gtkwidgetset.inc:1202
#17 0x000551dc in TAPPLICATION__HANDLEMESSAGE (this=0xf78ec020) at application.inc:980
#18 0x000556a4 in TAPPLICATION__RUNLOOP (this=0xf78ec020) at application.inc:1091
#19 0x000c1478 in TWIDGETSET__APPRUN (ALOOP=0x55648 <TAPPLICATION__RUNLOOP>, this=0xf7734020)
at interfacebase.inc:49
#20 0x00055640 in TAPPLICATION__RUN (this=0xf78ec020) at application.inc:1078
#21 0x0001a7b4 in main () at lazarus.pp:104
(gdb)

As a detail, until I quit out of the debugger the splash image appears on all desktops in front of anything else.

I notice that on x86 I do not get those initial assertions- before I even start trying to look at the source can anybody say whether that's significant?

Is there somewhere more appropriate that I should be posting or discussing this? I'm very inexperienced in the arcane ways of formal bug reports etc.

To me, this seems to be a compiler bug. Line 230 is:

   if not FReference.Allocated then Exit;

FReference is an object with a boolean property Allocated. I see no reason, why this should give a problem.

Can you try with fpc 2.2.2?

I notice that on x86 I do not get those initial assertions- before I even start trying to look at the source can anybody say whether that's significant?

I have no idea, maybe a gtk expert.

Is there somewhere more appropriate that I should be posting or discussing this? I'm very inexperienced in the arcane ways of formal bug reports etc.

For discussion bug, this is the best place. The bug tracker is a bit memory (it is easier to look up things), but not the right place for debugging.

Vincent

Using fpc 2.2.3 compiled without optimisation I appear to get the same:

(gdb) run
Starting program: /usr/local/bin/lazarus
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 25243)]

Gdk-CRITICAL **: file gdkgc.c: line 502 (gdk_gc_set_function): assertion `gc != NULL' failed.

Gdk-CRITICAL **: file gdkdraw.c: line 381 (gdk_draw_pixmap): assertion `gc != NULL' failed.

Gdk-CRITICAL **: file gdkgc.c: line 288 (gdk_gc_unref): assertion `gc != NULL' failed.
TMainIDE.ParseCmdLineOptions:
PrimaryConfigPath="/home/markMLl/.lazarus"
SecondaryConfigPath="/etc/lazarus"
NOTE: miscellaneous options file not found - using defaults NOTE: codetools config file not found - using defaults NOTE: help options config file not found - using defaults TMainIDE.DoNewProject A
TCustomFormEditor.CreateComponent Form1:TForm1 False TMainIDE.DoNewEditorFile END unit1.pas

Program received signal SIGBUS, Bus error.
[Switching to Thread 16384 (LWP 25243)]
0x001821d0 in TPEN__FREEREFERENCE (this=0xf6ec8610) at pen.inc:230 230 pen.inc: No such file or directory.
in pen.inc
(gdb) backtrace
#0 0x001821d0 in TPEN__FREEREFERENCE (this=0xf6ec8610) at pen.inc:230 #1 0x001823e8 in TPEN__SETCOLOR (NEWCOLOR=8421504, NEWFPCOLOR= {RED = 32896, GREEN = 32896, BLUE = 32896, ALPHA = 65535}, this=0xf6ec8610) at pen.inc:269
#2 0x00181ac4 in TPEN__SETCOLOR (VALUE=8421504, this=0xf6ec8610) at pen.inc:47
#3 0x00167554 in TCUSTOMTREEVIEW__DOPAINT (this=0xf6f792a0) at treeview.inc:4031
#4 0x00163a50 in TCUSTOMTREEVIEW__PAINT (this=0xf6f792a0) at treeview.inc:2999
#5 0x001e862c in TCUSTOMCONTROL__PAINTWINDOW (DC=-145145824, this=0xf6f792a0) at customcontrol.inc:127
#6 0x001ce9bc in TWINCONTROL__PAINTHANDLER (THEMESSAGE= {MSG = 66592, DC = -145145824, PAINTSTRUCT = 0xf6ecd610, RESULT = 0}, this=0xf6f792a0)
at wincontrol.inc:4239
#7 0x001d432c in TWINCONTROL__WMPAINT (MSG=
{MSG = 66592, DC = -145145824, PAINTSTRUCT = 0xf6ecd610, RESULT = 0}, this=0xf6f792a0)
at wincontrol.inc:6043
#8 0x001e8514 in TCUSTOMCONTROL__WMPAINT (MESSAGE= {MSG = 66592, DC = -145145824, PAINTSTRUCT = 0xf6ecd610, RESULT = 0}, this=0xf6f792a0)
at customcontrol.inc:107
#9 0x0002ca78 in SYSTEM_TOBJECT_$__DISPATCH$formal () #10 0x001ddec0 in TCONTROL__WNDPROC (THEMESSAGE=
{MSG = 66592, WPARAM = -145145824, LPARAM = -152250864, RESULT = 0, WPARAMHI = 63321, WPARAMLO = 16416, LPARAMHI = 63212, LPARAMLO = 54800, RESULTHI = 0, RESULTLO = 0}, this=0xf6f792a0) at control.inc:1583 #11 0x001d070c in TWINCONTROL__WNDPROC (MESSAGE=
{MSG = 66592, WPARAM = -145145824, LPARAM = -152250864, RESULT = 0, WPARAMHI = 63321, WPARAMLO = 16416, LPARAMHI = 63212, LPARAMLO = 54800, RESULTHI = 0, RESULTLO = 0}, this=0xf6f792a0) at wincontrol.inc:4749 #12 0x00166cd4 in TCUSTOMTREEVIEW__WNDPROC (MESSAGE= {MSG = 66592, WPARAM = -145145824, LPARAM = -152250864, RESULT = 0, WPARAMHI = 63321, WPARAMLO = 16416, LPARAMHI = 63212, LPARAMLO = 54800, RESULTHI = 0, RESULTLO = 0}, this=0xf6f792a0) at treeview.inc:3884 #13 0x002ff950 in DELIVERMESSAGE (TARGET=0xf6f792a0, AMESSAGE=void) at gtkproc.inc:3547
#14 0x0030ed48 in DODELIVERPAINTMESSAGE (TARGET=0xf6f792a0, PAINTMSG= {MSG = 66592, DC = -145145824, PAINTSTRUCT = 0xf6ecd610, RESULT = 0}) at gtkcallback.inc:50
#15 0x002e839c in TGTKWIDGETSET__SENDMESSAGE (HANDLEWND=14639392, MSG=66659, WPARAM=-153572208, LPARAM=28,
this=0xf76f4020) at gtkwinapi.inc:8159
#16 0x002c4adc in TGTKWIDGETSET__APPPROCESSMESSAGES (this=0xf76f4020) at gtkwidgetset.inc:1202
#17 0x000551dc in TAPPLICATION__HANDLEMESSAGE (this=0xf78ac020) at application.inc:980
#18 0x000556a4 in TAPPLICATION__RUNLOOP (this=0xf78ac020) at application.inc:1091
#19 0x000c1478 in TWIDGETSET__APPRUN (ALOOP=0x55648 <TAPPLICATION__RUNLOOP>, this=0xf76f4020)
at interfacebase.inc:49
#20 0x00055640 in TAPPLICATION__RUN (this=0xf78ac020) at application.inc:1078
#21 0x0001a7b4 in main () at lazarus.pp:104
(gdb)

If you want to spend some time on it and know a little assembler you can get the assembler source by using the -al compiler options.

So I would do the following:
* compile the LCL: make lcl
* remove the lcl/units/sparc-linux/graphics.ppu
* recompile the graphics unit: make lcl OPT="-al"
* inspect the graphics.s file and look for line 230 of pen.inc to see what causes the sigbus.

Vincent

Start with
run --g-fatal-warnings

Mattias

This GDB was configured as "sparc-linux-gnu"...Using host libthread_db library "/lib/v9/libthread_db.so.1".

(gdb) run --g-fatal-warnings
Starting program: /usr/local/bin/lazarus --g-fatal-warnings [Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 1950)]

Gdk-CRITICAL **: file gdkgc.c: line 502 (gdk_gc_set_function): assertion `gc != NULL' failed.
aborting...

Program received signal SIGABRT, Aborted.
[Switching to Thread 16384 (LWP 1950)]
0xf7a00e08 in kill () from /lib/v9/libc.so.6
(gdb) backtrace
#0 0xf7a00e08 in kill () from /lib/v9/libc.so.6
#1 0xf7b4d190 in pthread_kill () from /lib/v9/libpthread.so.0 #2 0xf7b4d1e4 in raise () from /lib/v9/libpthread.so.0 #3 0xf7a00a48 in raise () from /lib/v9/libc.so.6
#4 0xf7a02234 in abort () from /lib/v9/libc.so.6
#5 0xf7f99ea0 in g_logv () from /usr/lib/libglib-1.2.so.0 #6 0xf7f99ecc in g_log () from /usr/lib/libglib-1.2.so.0 #7 0xf7f51d0c in gdk_gc_set_function () from /usr/lib/libgdk-1.2.so.0 #8 0x002f8a00 in CREATEGDKMASKBITMAP (AIMAGE=-143031040, AMASK=-143031136) at gtkproc.inc:1333
#9 0x002d6014 in TGTKWIDGETSET__CREATEICONINDIRECT (ICONINFO=0xfff44fc0, this=0xf77a0020)
at gtkwinapi.inc:1919
#10 0x00192b34 in TICON__HANDLENEEDED (this=0xf7980120) at icon.inc:948 #11 0x0017f154 in TRASTERIMAGE__GETHANDLE (this=0xf7980120) at rasterimage.inc:757
#12 0x00192a10 in TICON__GETICONHANDLE (this=0xf7980120) at icon.inc:925 #13 0x00054b94 in TAPPLICATION__GETICONHANDLE (this=0xf7958020) at application.inc:896
#14 0x00054a3c in TAPPLICATION__ICONCHANGED (SENDER=0xf7980120, this=0xf7958020) at application.inc:880
#15 0x00176954 in TGRAPHIC__CHANGED (SENDER=0xf7980120, this=0xf7980120) at graphic.inc:67
#16 0x0017d888 in TRASTERIMAGE__CHANGED (SENDER=0xf7980120, this=0xf7980120) at rasterimage.inc:390
#17 0x0017dc14 in TRASTERIMAGE__LOADFROMSTREAM (ASTREAM=0xf7fcb0c0, ASIZE=19318, this=0xf7980120)
at rasterimage.inc:452
#18 0x0017d968 in TRASTERIMAGE__LOADFROMSTREAM (ASTREAM=0xf7fcb0c0, this=0xf7980120) at rasterimage.inc:412
#19 0x0017782c in TGRAPHIC__LOADFROMLAZARUSRESOURCE (RESNAME=0x965ddc, this=0xf7980120) at graphic.inc:252
#20 0x00052e68 in TAPPLICATION__INITIALIZE (this=0xf7958020) at application.inc:352
#21 0x0001a668 in main () at lazarus.pp:87
(gdb)

I'll see what I can do, but not necessarily this evening. My SPARC assembler is about as strong as hospital tea.

The "good" news is that this might be SPARC-specific- I've just got 0.9.25 compiled and apparently running on an ARM (little-endian) system, again based on Debian "Etch". However I can't do much real work on this platform- compilation on the hardware available is somewhat sluggish and while I've got some higher-spec boards (or could cross-compile) it all takes time which is in short supply.

I'd like to get a big-endian ARM system running as well but I can't promise this in finite time. Is anybody else currently testing Lazarus on a big-endian system?

Yes, powerpc-darwin is working.

Vincent