View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0034318||Lazarus||IDE||public||2018-09-21 12:52||2018-10-23 00:43|
|Reporter||Theo van Oosten||Assigned To||Juha Manninen|
|Product Version||1.8.2||Product Build|
|Target Version||Fixed in Version|
|Summary||0034318: Application.Title:='My Application'; inserted before Application:=TMyApplication.Create(nil); causing SIGSEGV.|
|Description||When Lazarus inserts the line "Application.Title:='My Application';" at another moment then the creation of a new project, it does this as the first line.|
Because this is before the initialization by calling TMyApplication.Create, Application will be nill and the programm crashes with a SIGSEGV fault.
|Steps To Reproduce||Create a new project, select 'console application' and accept the defaults.|
Uncomment the line "Application.Title:='My Application';" using Cntrl-/ or remove the line completely.
Select 'Project options' from the 'Project' menu and close again by pressing OK (not CANCEL or the cross at the top of the window, then nothing happens).
Because "Main unit has Application.Title statement" is checked, Lazarus will add that statement to the code. Unfortunately at the wrong line.
|Additional Information||This happened to me before, many versions of Lazarus back in time. At that time I could not reproduce what happened, so I thought it was a single incident.|
Now I see this problem has been there since ??? At least the problem is not related to version 1.8.2
|Tags||No tags attached.|
|Fixed in Revision||r59147, r59156|
In trunk I get this (as expected):
Application := TMyApplication.Create(nil);
Application.Title := 'My Application';
In ide/projectdefs.pas (both 1.8.2 and 1.8.4) the code that generates this does:
1651 NewSource.Add(' Application:='+C+'.Create(nil);');
1652 If (T<>'') then
1656 NewSource.Add(' Application.Title:='''+T+''';');
1658 NewSource.Add(' Application.Run;');
1659 NewSource.Add(' Application.Free;');
So, how this happens to you is a mystery to me.
Yes it happens here, too.
Maybe Bart got confused because the Steps to Reproduce have an error. It says:
Uncomment the line "Application.Title:='My Application';"
while it should say:
Comment the line "Application.Title:='My Application';"
Also happens in trunk.
function TStandardCodeTool.SetApplicationStatement(const APropertyName,
NewCode: string; SourceChangeCache: TSourceChangeCache): boolean;
end else begin
// insert as first line in program begin..end block
It's called from
function TCodeToolManager.SetApplicationTitleStatement(Code: TCodeBuffer;
const NewTitle: string): boolean;
||B.t.w. If someone commented out that line (on purpose we can assume), should codetools re-insert that at all in this case?|
Note: The auto instertion of Application.Title assignment is controlled by the Project / Project Options / Miscellaneous / Main unit has Application.Title statement, not by comments in the code.
Maybe codetools should be extended to check for "Application:=" as well to find a nice insert position.
||Should CodeTools change anything if the user did not change an (or that) option in that dialog?|
@Bart: Sorry for the mistake. But the part saying "or remove the line completely" should make clear what I said to do.
To find a nice insert position: how about looking for TApplication.Create and insert on the next line?
The commenting out of the .title line was the shortest way of demonstrating.
The same happens if you decide NOT to have a title at project creation time (make the title box blank) and then later on check the box "Main unit has Application.Title statement". At first nothing happens, so you think you're OK. Then you decide to change the project title on the first screen of project options and then it hits you. And you did not see that coming, because all you did was change its name?
The change has to be at least 2 characters. Just deleting the 1 from project1 did not do the trick???
I improved the logic a little in r59147. Now the Application.Title assignment line gets also deleted when you uncheck the relevant CheckBox.
The original bug still remains.
function TStandardCodeTool.SetApplicationStatement() should indeed find the TApplication.Create line and insert stuff behind it.
> The change has to be at least 2 characters.
Theo, what do you mean by that?
Mattias, I don't fully understand why Application's title must be managed this way. It is already set in project options and saved to .lpi.
Where exactly does the managed line in .lpr file make a difference?
||@Juha: do you mean the Application.Title statement is not needed anymore?|
Mattias, maybe Application.Title statement is needed but I fail to see why.
Anyway, I am fixing the actual bug. It is rather easy.
||Fixed, please test.|
@Juha: I tried to get the behavior by removing 1 character from the title: change it from 'project1' to 'project', but nothing happened. But when I removed the 't' also (change title to 'projec') then the new statement appeared. I mentioned it has to be at least 2 characters to prevent that you see nothing happening.
But you fixed it, so it's not relevant anymore.
When I upgraded to Mint 19 and installed Lazarus 1.8.4, MintUpdate kept complaining there is a newer version of fpc in the repository, so to stop this, I installed Lazarus from the repository and got version 1.8.2
For me that is good enough, but it means slower fixes because the repositories are not updated very frequently.
When do you expect that your fix will be in the repository?
I am not sure if I understand you. Does it work or not?
Theo, you must obviously get Lazarus trunk to test. Getting it from SVN server is so super easy that I always wonder why people want to struggle with the repositories of their Debian and Ubuntu derivatives.
Just "svn checkout ..." and "make". Install only FPC from Mint repo.
Theo, ping ...
Does it work or not?
Juha, it works.
Sorry for my late respons. Two years ago monitoring stopped working, so I do not get a mail anymore if there is something new in the bugreport.
About struggle with repositories: I used to install Lazarus from the latest .DEB file, but then I got problems: It complained that installing FPC was breaking the install of FPC (????) and that there was a newer version in the repositories. And I am using Lazarus professionally, so I can't afford that a new installation causes problems, so I only install new versions if I really must.
Getting trunk from the SVN server is not as easy as you think, if you have not done it before. Lots of confusing remarks, like "just download the fpcup image" (from where? No web page was specified) etc. But I got it to work in a virtualbox computer. Next time will be easy, yes.
> Lots of confusing remarks, like "just download the fpcup image"
Fpcup image, WTF! Did I tell you to use fpcup? No I didn't. I told you to use "svn checkout ..." and "make". Later you can update the latest changes with "svn up". It cannot be difficult for a professional developer.
You have been mislead by other people if they recommend fpcup for getting Lazarus trunk.
There are hundreds of forum threads complaining about the same problems. For some weird reason people want to get Lazarus using the most complex and error-prone ways. Why can't they use the most obvious and simple way?
This advice written by me was provably tried only by one person. For him it worked at once.
Resolving this issue.
Juha, I am a oldschool developer. In my days there was no Github, Subversion or cloud. You installed the tools you need, do your thing and backup on another computer via the network. No such thing as an external harddisk etc.
You send me an URL about getting Lazarus. There is the reference to fpcup, so indirectly you pointed me in that direction. I wil NEVER just follow instructions, I investigate and look at alternatives, as what works well for somebody else might not fit my needs.
My experience in the 40 years I am working with computers, is that every (ever so tiny) change can have unintended side-effects. I am starting a company that will migrate OpenVMS software 1-on-1 to Linux. What do you think would happen when I have finished a project, but before showing it to the customer, I install a new version of Lazarus and then the software behaves just a little different? I will loose the contract and my startup. I can't afford that. So I rather use a version of my tools that is outdated, but it does exactly what I expect, then using cutting edge software and having to fix every small thing that changed after the latest install. Even worse: you might not even see the change, but be confronted with it on a later, very inconvenient moment (example: This bugreport! You have no idea how much time I have spend to find why my software that worked perfectly yesterday, isn't working today, while I did not change anything, at least I thought I didn't).
I believe that you should use the repositories to install sotware and the repositories should be updated faster. But in an unpaid open source environment one cannot demand something. So as an alternative you can use .deb files to install software. That should be save and straight forward and should NEVER be broken by software from the repositories. Manual install has a higher priority then automated updates and the updates should be manually too. The fact that the update software thinks that something in the repositories is newer, even when it is the exact same version, points to an inconsistency. INCONSISTENCY IS A KILLER. And should be prevented at all cost. So the procedures around populating the repositories should be improved and not starting to advice everybody to use the sources to build your tools yourself. That is the way we used to do things in the 20th century. Today it is 2018. We only build our tools ourselfs as a last resort. Or to check if a bug is fixed :).
As an experienced private teacher I like to say to you: Never loose your cool, or you will loose your audience.
Many thanks for what you did to fix the bug. Keep up the good work. I will try to contribute too, by improving the wiki and adding some examples with great detail. I'll just have to find how one can do that. (Old, but still a newby, lol).
The URL for getting Lazarus was to section "Development_version_of_Lazarus" which tells you to run one "svn co" command.
I removed now a mention of fpcup in the Scripts section to make sure nobody picks it in a wrong context.
Yes I can see you NEVER follow instructions but you should. At least please don't complain about instructions if you don't want to follow them.
I also have almost 40 years experience with computers (since 1982) but I am able to take advice from others for things I don't otherwise know. Being an oldschool developer does not justify behaving like a dumb-ass.
You write about unrelated things like you didn't understand much. I did NOT tell you to use Lazarus trunk for your customers obviously.
|2018-09-21 12:52||Theo van Oosten||New Issue|
|2018-09-21 18:24||Bart Broersma||Note Added: 0110933|
|2018-09-21 18:35||Bart Broersma||Note Added: 0110934|
|2018-09-21 20:44||Juha Manninen||LazTarget||=> -|
|2018-09-21 20:44||Juha Manninen||Note Added: 0110939|
|2018-09-21 20:44||Juha Manninen||Assigned To||=> Juha Manninen|
|2018-09-21 20:44||Juha Manninen||Status||new => confirmed|
|2018-09-21 20:44||Juha Manninen||Assigned To||Juha Manninen =>|
|2018-09-21 22:34||Bart Broersma||Note Added: 0110946|
|2018-09-21 22:40||Bart Broersma||Note Added: 0110947|
|2018-09-21 22:42||Bart Broersma||Note Edited: 0110947||View Revisions|
|2018-09-22 12:17||Bart Broersma||Note Added: 0110950|
|2018-09-23 08:49||Mattias Gaertner||Note Added: 0110966|
|2018-09-23 12:06||Bart Broersma||Note Added: 0110971|
|2018-09-23 12:14||Theo van Oosten||Note Added: 0110973|
|2018-09-23 12:21||Theo van Oosten||Note Edited: 0110973||View Revisions|
|2018-09-23 13:20||Juha Manninen||Note Added: 0110975|
|2018-09-23 13:33||Mattias Gaertner||Note Added: 0110976|
|2018-09-24 10:28||Juha Manninen||Assigned To||=> Juha Manninen|
|2018-09-24 10:28||Juha Manninen||Status||confirmed => assigned|
|2018-09-24 10:29||Juha Manninen||Note Added: 0110991|
|2018-09-24 14:12||Juha Manninen||Fixed in Revision||=> r59147, r59156|
|2018-09-24 14:12||Juha Manninen||Note Added: 0110993|
|2018-09-24 14:12||Juha Manninen||Status||assigned => resolved|
|2018-09-24 14:12||Juha Manninen||Resolution||open => fixed|
|2018-09-26 13:05||Theo van Oosten||Note Added: 0111028|
|2018-09-26 16:55||Juha Manninen||Note Added: 0111035|
|2018-09-26 16:55||Juha Manninen||Status||resolved => assigned|
|2018-09-26 16:55||Juha Manninen||Resolution||fixed => reopened|
|2018-09-26 16:56||Juha Manninen||Status||assigned => feedback|
|2018-09-30 23:59||Juha Manninen||Note Added: 0111136|
|2018-10-11 10:15||Theo van Oosten||Note Added: 0111364|
|2018-10-11 10:15||Theo van Oosten||Status||feedback => assigned|
|2018-10-11 10:43||Juha Manninen||Note Added: 0111366|
|2018-10-11 10:44||Juha Manninen||Status||assigned => resolved|
|2018-10-11 10:44||Juha Manninen||Resolution||reopened => fixed|
|2018-10-14 12:40||Theo van Oosten||Note Added: 0111393|
|2018-10-22 23:14||Theo van Oosten||Status||resolved => closed|
|2018-10-23 00:43||Juha Manninen||Note Added: 0111517|
|2018-10-23 00:43||Juha Manninen||Status||closed => assigned|
|2018-10-23 00:43||Juha Manninen||Resolution||fixed => reopened|
|2018-10-23 00:43||Juha Manninen||Status||assigned => resolved|
|2018-10-23 00:43||Juha Manninen||Resolution||reopened => fixed|
|2018-10-23 00:43||Juha Manninen||Status||resolved => closed|