View Issue Details

IDProjectCategoryView StatusLast Update
0018437LazarusIDEpublic2011-01-24 10:54
ReporterSven BarthAssigned ToMattias Gaertner 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version0.9.29 (SVN)Product Build 
Target Version0.9.30Fixed in Version0.9.29 (SVN) 
Summary0018437: IDE needs a very long time to start if configuration directory is empty
DescriptionI've checked out today's fixes_0_9_30, compiled it and started it using a new empty configuration directory. Lazarus notified me of a not set source directory which I confirmed and then it just caused my disk access light to flash and do nothing else. After five or more minutes I killed the process.

This problem does not appear in trunk.
Additional InformationMaybe a regression of 0018078 (which was fixed around November) in that branch only?
TagsNo tags attached.
Fixed in Revision28940
LazTarget0.9.30
WidgetsetGTK 2
Attached Files

Relationships

related to 0018078 closedMattias Gaertner The IDE does not respond when FPC source dir is set to an empty string 

Activities

Vincent Snijders

2011-01-08 20:40

manager   ~0045000

The fixes branch was created from trunk revision 28809, so way after revision 28554.

Sven Barth

2011-01-09 11:41

manager   ~0045010

That's why I think it is strange ^^

Regards,
Sven

Vincent Snijders

2011-01-09 20:36

manager   ~0045023

When I ran it with empty new (not yet existing) config dir I got an AV sometimes, but not when run in gdb.

I ran it with valgrind and found this interesting:
NOTE: FPC source directory not set! (see Environment / Options ... / Environment / Files)
==10413== Syscall param stat64(file_name) points to unaddressable byte(s)
==10413== at 0x805E1A4: SYSTEM_FPSYSCALL$LONGINT$LONGINT$LONGINT$$LONGINT (in /home/vincent/src/lftest/lazarus)
==10413== by 0x805E3ED: SYSTEM_FPSTAT$PCHAR$STAT$$LONGINT (in /home/vincent/src/lftest/lazarus)
==10413== by 0x868A317: INITIALSETUPDLGS_SETUPFPCSOURCEDIRECTORY$BOOLEAN (initialsetupdlgs.pas:108)
==10413== by 0x80CA929: MAIN_TMAINIDE_$__INITCODETOOLBOSS (main.pp:13879)
==10413== by 0x809EB0F: MAIN_TMAINIDE_$__CREATE$TCOMPONENT$$TMAINIDE (main.pp:1315)
==10413== by 0x805DEE9: main (lazarus.pp:102)
==10413== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==10413==
==10413== Syscall param stat64(file_name) points to unaddressable byte(s)
==10413== at 0x805E1A4: SYSTEM_FPSYSCALL$LONGINT$LONGINT$LONGINT$$LONGINT (in /home/vincent/src/lftest/lazarus)
==10413== by 0x805E3ED: SYSTEM_FPSTAT$PCHAR$STAT$$LONGINT (in /home/vincent/src/lftest/lazarus)
==10413== by 0x8133F42: FILEUTIL_FILEGETATTRUTF8$ANSISTRING$$LONGINT (./include/unixfileutil.inc:328)
==10413== by 0x812EB3E: FILEUTIL_DIRPATHEXISTS$ANSISTRING$$BOOLEAN (./include/fileutil.inc:148)
==10413== by 0x8312A0B: LAZCONF_CHECKFPCSOURCEDIR$ANSISTRING$$BOOLEAN (lazconf.pp:419)
==10413== by 0x868A33B: INITIALSETUPDLGS_SETUPFPCSOURCEDIRECTORY$BOOLEAN (initialsetupdlgs.pas:114)
==10413== by 0x80CA929: MAIN_TMAINIDE_$__INITCODETOOLBOSS (main.pp:13879)
==10413== by 0x809EB0F: MAIN_TMAINIDE_$__CREATE$TCOMPONENT$$TMAINIDE (main.pp:1315)
==10413== by 0x805DEE9: main (lazarus.pp:102)
==10413== Address 0x0 is not stack'd, malloc'd or (recently) free'd

Vincent Snijders

2011-01-10 10:42

manager   ~0045037

I cannot reproduce the hang. Can you run lazarus in gdb and halt lazarus when it hangs are produce a backtrace? Maybe we can find out what it is doing.

Zeljan Rikalo

2011-01-10 12:33

developer   ~0045042

@Sven, can you try "strace ./lazarus" ? and see where it waits ? maybe it'll show problem faster than gdb.

Sven Barth

2011-01-10 19:53

manager   ~0045052

I have found part of the cause: this only has a significant impact if you run from a different directory than Lazarus' directory that also has many directories/files in it (e.g. your home directory or the root of a disk).

I found this through the following:
I was in my home directory and started Lazarus using strace:
strace /mnt/data/applications/lazarus/0.9.30/lazarus --pcp=/home/sven/.lazarus/0.9.30
I confirmed the "missing FPC sources" dialog, waited some time (harddisk access light flashing) and then killed strace using Ctrl+C and looked at its output. Lazarus somewhere after the dialog does a change of the working directory back to "/home/sven" (where I started it from) and then searches every single directory in there for something.

Lazarus also does this when I start from /mnt/data/applications/lazarus/0.9.30, but there it searches only below that directory and thus it starts faster.

Note: before the change back to the "old" working directory Lazarus checked for the existence of the main directories (components, ide, lcl, etc.) in the Lazarus directory as well.

I'll try to use GDB for more details (I can't sent you the strace output, because some filenames are a bit too private ^^).

Regards,
Sven

Sven Barth

2011-01-10 19:59

manager   ~0045053

Btw: Now that I know what influences the problem I can also reproduce it with trunk.

Regards,
Sven

Sven Barth

2011-01-10 20:28

manager   ~0045055

Ok, I have found a bit more:

The problem appears inside UnitSetCache.Init which is called in ide/buildmanager.pas line 649. More precisely: after some debugging one lands inside components/codetools/definetemplates.pas line 8723. This is the first line of TFPCUnitSetCache.GetUnitToSourceTree.

Now GetSourceCache is called and to my surprise FPCSourceDirectory is not empty, but set to the current working directory! Thus in Caches.SourceCaches.Find every file below this "source directory" is added.

I have yet to investigate where the current working directory is assigned, but this seems to be the spot.

Regards,
Sven

Sven Barth

2011-01-10 20:42

manager   ~0045057

I have found the problem:

In TFPCUnitSetCache.SetFPCSourceDirectory (in components/codetools/definetemplates.pas line 8584) the function CleanAndExpandDirectory is called. At the end this boils down to ExpandFileName in SysUtils, which returns the current directory if you pass an empty string (verified with test application).

So maybe it should be checked first whether AValue is empty and then do CleanAndExpandDirectory.

Regards,
Sven

Sven Barth

2011-01-15 14:18

manager   ~0045206

Works as expected now. Thank you.

Regards,
Sven

Issue History

Date Modified Username Field Change
2011-01-08 16:52 Sven Barth New Issue
2011-01-08 16:52 Sven Barth Widgetset => GTK 2
2011-01-08 20:38 Vincent Snijders Relationship added related to 0018078
2011-01-08 20:40 Vincent Snijders Note Added: 0045000
2011-01-09 11:41 Sven Barth Note Added: 0045010
2011-01-09 20:36 Vincent Snijders Note Added: 0045023
2011-01-10 10:42 Vincent Snijders Note Added: 0045037
2011-01-10 10:49 Vincent Snijders LazTarget => 0.9.30
2011-01-10 10:49 Vincent Snijders Status new => acknowledged
2011-01-10 10:49 Vincent Snijders Target Version => 0.9.30
2011-01-10 12:33 Zeljan Rikalo Note Added: 0045042
2011-01-10 12:33 Zeljan Rikalo Status acknowledged => feedback
2011-01-10 19:53 Sven Barth Note Added: 0045052
2011-01-10 19:59 Sven Barth Note Added: 0045053
2011-01-10 20:28 Sven Barth Note Added: 0045055
2011-01-10 20:42 Sven Barth Note Added: 0045057
2011-01-10 21:41 Mattias Gaertner Fixed in Revision => 28940
2011-01-10 21:41 Mattias Gaertner Assigned To => Mattias Gaertner
2011-01-10 21:41 Mattias Gaertner Status feedback => resolved
2011-01-10 21:41 Mattias Gaertner Resolution open => fixed
2011-01-15 14:18 Sven Barth Status resolved => closed
2011-01-15 14:18 Sven Barth Note Added: 0045206
2011-01-24 10:54 Vincent Snijders Fixed in Version => 0.9.29 (SVN)