Lazarus

Programming => General => Topic started by: antispam88 on January 13, 2018, 10:57:35 am

Title: Lazbuild EAccessViolation
Post by: antispam88 on January 13, 2018, 10:57:35 am
Hi,

I'm having several packages and projects which I build using lazbuild.
The batch file works sometimes but more often I get exceptions:
Code: Pascal  [Select][+][-]
  1. An unhandled exception occurred at $771F1DCA:
  2. EAccessViolation: Access violation
  3. ...
  4. TProject.DoLoadStateFile Statefile not found: C:\src\bin\lib\x86_64-win64\project1.compiled
  5. An unhandled exception occurred at $004769EF:
  6. EAccessViolation: Access violation
  7. ...
  8. An unhandled exception occurred at $02D77993:
  9. EAccessViolation:
  10.  

The batch file looks as following:
Code: Pascal  [Select][+][-]
  1. lazbuild --add-package-link src\package1.lpk
  2. lazbuild --add-package-link src\package2.lpk
  3. lazbuild --add-package-link src\package3.lpk
  4. lazbuild -B --build-mode=Release src\project1.lpi
  5. lazbuild -B --build-mode=Release src\project2.lpi
  6.  

Has someone a hint regarding this error?
Or is there an option to get a detailed error log?

Best regards,
antispam88

Lazarus: 1.8.0
FPC: 3.0.4
Windows 10 pro 64 (x86_64-win64-win32/win64)
Windows 7 pro 32 (i386-win32-win32/win64)
Title: Re: Lazbuild EAccessViolation
Post by: balazsszekely on January 13, 2018, 11:12:22 am
Quote
Or is there an option to get a detailed error log?
Did you try --verbose or/and --verbose-pkgsearch right after -B. What happens if you build your project/package from lazarus?
Title: Re: Lazbuild EAccessViolation
Post by: antispam88 on January 13, 2018, 11:21:20 am
Thank you for the hint with the option --verbose, I will try it right now.

If I build those with lazarus everything works as expected.
Title: Re: Lazbuild EAccessViolation
Post by: antispam88 on January 13, 2018, 12:33:00 pm
I have tried it:
Code: Pascal  [Select][+][-]
  1. An unhandled exception occurred at $00007FFF5972BE4B:
  2. EAccessViolation: Access violation
  3. ...
  4. TProject.DoLoadStateFile Statefile not found: C:\src\bin\lib\i386-win64\project1.compiled
  5. !!!Hint: (lazarus) Project needs building: No state file for Project!!!
  6. An unhandled exception occurred at $0000000100095CE8:
  7. EAccessViolation: Access violation
  8. ...
  9. An unhandled exception occurred at $000000010044F010:
  10. EAccessViolation:
  11.  

Only the line "Hint: (lazarus) Project needs building: No state file for Project" appeared. What does this mean?

Another hint: I use several build modes (--build-mode) for several projects.

Best regards,
antispam88
Title: Re: Lazbuild EAccessViolation
Post by: balazsszekely on January 13, 2018, 12:51:39 pm
Are you cross compiling? It looks like you're using the wrong compiler. You should override the default one with  --compiler=<ppcXXX> , where ppc386 is for 32 bit and ppcx64 for 64 bit.
Title: Re: Lazbuild EAccessViolation
Post by: antispam88 on January 13, 2018, 12:56:26 pm
Yes I use cross compiling (win32 + win64).

Is this only an option for lazbuild or can I set this via lpi file?
Title: Re: Lazbuild EAccessViolation
Post by: antispam88 on January 13, 2018, 01:06:42 pm
Setting the --compiler option doesn't solve the problem :-(
Same errors as before.

My --compiler parameters:
C:\lazarus\fpc\3.0.4\bin\x86_64-win64\ppc386.exe for x86
C:\lazarus\fpc\3.0.4\bin\x86_64-win64\ppcx64.exe for x64
Title: Re: Lazbuild EAccessViolation
Post by: balazsszekely on January 13, 2018, 04:18:09 pm
Unfortunately I'm out of ideas. Maybe you should build your applications/packages with Lazarus.
Title: Re: Lazbuild EAccessViolation
Post by: antispam88 on January 13, 2018, 05:25:42 pm
The point is that we are using jenkins to build and test our software.
And as I mentioned in my first post, the exception occurs not always.

Is it possible that cleaning the unit output directory or some other directory after each build might help?
Or is there a possibility to use lazarus via command line?

Best regards,
antispam88
Title: Re: Lazbuild EAccessViolation
Post by: JuhaManninen on January 13, 2018, 06:21:06 pm
Quote from: antispam88 on January 13, 2018, 10:57:35 am
Has someone a hint regarding this error?
Or is there an option to get a detailed error log?
It happens to others, too, but only seldom.
 https://bugs.freepascal.org/view.php?id=32340
We would need a proper debugger backtrace. Actually there is one from Benito van der Zander but it does not reveal any error in the code.
The problem with memory corruption and uninitialized variable issues is that they may trigger in different places.

There is a fundamental problem with LazBuild: it depends on LCL although it is not a GUI application.
Removing the dependency will require serious refactoring at some point.
Title: Re: Lazbuild EAccessViolation
Post by: antispam88 on January 13, 2018, 06:52:30 pm
Ok, can you tell me how to do a debugger backtrace of lazbuild?
Title: Re: Lazbuild EAccessViolation
Post by: JuhaManninen on January 13, 2018, 10:52:07 pm
Quote from: antispam88 on January 13, 2018, 06:52:30 pm
Ok, can you tell me how to do a debugger backtrace of lazbuild?
Run it under gdb and then type command "bt" after the crash happened.
LazBuild must be built with debug info.
Title: Re: Lazbuild EAccessViolation
Post by: antispam88 on January 14, 2018, 10:18:17 pm
Hi,

I compiled lazbuild in Debug mode.

When I start the gdb I get following output:
Code: Pascal  [Select][+][-]
  1. C:\daten\src\projects\yoda> C:\lazarus\mingw\x86_64-win64\bin\gdb.exe C:\lazarus\lazbuild.exe
  2. GNU gdb (GDB) 7.3.50.20110510-cvs
  3. Copyright (C) 2011 Free Software Foundation, Inc.
  4. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  5. This is free software: you are free to change and redistribute it.
  6. There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  7. and "show warranty" for details.
  8. This GDB was configured as "x86_64-w64-mingw32".
  9. For bug reporting instructions, please see:
  10. <http://www.gnu.org/software/gdb/bugs/>...
  11. Reading symbols from C:\lazarus\lazbuild.exe...Reading symbols from C:\lazarus\lazbuild.dbg...
  12. warning: section .gnu_debuglink not found in C:\lazarus\lazbuild.dbg
  13. done.
  14. done.

Does this warning "section .gnu_debuglink not found in C:\lazarus\lazbuild.dbg" indicates a problem?

Nevertheless I went on:
Code: Pascal  [Select][+][-]
  1. set args -B --build-mode=Release_32_1 --verbose --compiler="C:\lazarus\fpc\3.0.4\bin\x86_64-win64\ppc386.exe" src\project1.lpi
  2. run
  3. //worked
  4. set args -B --build-mode=Release_64_1 --verbose --compiler="C:\lazarus\fpc\3.0.4\bin\x86_64-win64\ppc386.exe" src\project1.lpi
  5. run
  6. //worked
  7. set args -B --build-mode=Release_32_2 --verbose --compiler="C:\lazarus\fpc\3.0.4\bin\x86_64-win64\ppc386.exe" src\project1.lpi
  8. run
  9. //broke

The end of the output was:
Code: Pascal  [Select][+][-]
  1. (1008) 11768 lines compiled, 0.7 sec
  2. (1021) 32 warning(s) issued
  3. (1022) 41 hint(s) issued
  4.  
  5. Program received signal SIGSEGV, Segmentation fault.
  6. [Switching to Thread 10128.0x2a08]
  7. 0x00007fff5972be4b in ?? ()

Command bt ouput was:
Code: Pascal  [Select][+][-]
  1. #0  0x00007fff5972be4b in ?? ()
  2. #1  0x0000000009037400 in ?? ()
  3. #2  0x000000000f0cfbe0 in ?? ()
  4. #3  0x0000000009037408 in ?? ()
  5. #4  0x5555555555555555 in ?? ()
  6. #5  0x5555555555555555 in ?? ()
  7. #6  0x5555555555555555 in ?? ()
  8. #7  0xffffffffffffffff in ?? ()
  9. #8  0x000000000037a000 in ?? ()
  10. #9  0x0000000009037408 in ?? ()
  11. #10 0x0000000000002a08 in ?? ()
  12. #11 0x0000000000000000 in ?? ()

Doesn't seem to be very helpful. Have I made an error?

Best regards,
antispam88
Title: Re: Lazbuild EAccessViolation
Post by: antispam88 on January 17, 2018, 09:33:58 pm
Hi,

does anyone have a suggestion do get a better error analyse?
Are my steps correct?

Best regards,
antispam99
Title: Re: Lazbuild EAccessViolation
Post by: JuhaManninen on January 18, 2018, 12:39:54 am
Your backtrace looks like there is no debug info.
Does the problem happen only with a certain program? Then you should upload it here to be tested.
Title: Re: Lazbuild EAccessViolation
Post by: antispam88 on January 18, 2018, 11:35:24 pm
As I mentioned before I have always the same list of projects with different targets (use jenkins to build them all). Sometimes it is working but most of the time I'm getting the errors descibed above.

These are my steps to get my output:
I used Lazarus to open C:\la zarus\ide\lazbuild.lpi, changed the build mode to debug and used Run -> Clean up and Build ...
After that I started gbd with C:\lazarus\mingw\x86_64-win64\bin\gdb.exe C:\lazarus\lazbuild.exe.
In the gdb bash I first set the parameters with "set args -B --build-mode=Release_32_1 --verbose --compiler="C:\lazarus\fpc\3.0.4\bin\x86_64-win64\ppc386.exe" src\project1.lpi" and then used "run" do start.
When the error occured I used "bt" to get the backtrace.

Have I missed something to get debug info?

Best regards,
antispam88
Title: Re: Lazbuild EAccessViolation
Post by: Arvur on January 17, 2019, 03:48:03 pm
Same error here running lazbuild from Jenkins on Mac OS X (Lazarus 2.0 RC3).
Can I help providing some logs?

Code: Pascal  [Select][+][-]
  1. TProject.DoLoadStateFile Statefile not found: /Users/Administrator/Build/dcu/i386-darwin/bssPluginHost.compiled
  2.  
  3. An unhandled exception occurred at $00000000:
  4. EAccessViolation: Access violation
  5. An unhandled exception occurred at $A7A1A530:
  6. EAccessViolation: Access violation
  7.   $A7A1A530
  8.   $001DE23B
  9.   $0003DD58
  10.   $0003DAC8
  11.   $0002C6CA
  12.   $0052D097
  13.   $0052E09D
  14.   $0002B4A6
  15.  
  16. An unhandled exception occurred at $000C6181:
  17. EAccessViolation: Access violation
  18.   $000C6181
  19.   $000C626D
  20.   $000CAD3F
  21.   $00190BE1
  22.   $00191190
  23.   $00013F48
  24.   $00013431
  25.   $00011E53
  26.   $000167CC
Title: Re: Lazbuild EAccessViolation
Post by: Xor-el on January 17, 2019, 05:05:54 pm
I have experienced same issue when using lazbuild in Travis CI but unfortunately cannot consistently reproduce it.
I just restart my build when the error happens and after 2 or 3 tries, it suddenly works.  ::)
Title: Re: Lazbuild EAccessViolation
Post by: antispam88 on January 17, 2019, 08:43:41 pm
Hi,

we are using lazbuild in jenkins environment.
Because we have still no real solution for our problem, we just use a loop with 10 tries.
With that approach lazbuild is "working".
I know that this couldn't be the final solution, but because the use is in our case not time critical, it is ok.

This is our script for linux arm:
Quote
if [ -e bin/project1 ]
then
   rm bin/project1;
   err=$?
   if [ $err -ne 0 ]; then exit $err; fi
fi
for i in {1..10..1}
do
   /home/pi/fpupdeluxe/lazarus/lazbuild /home/pi/project1/project1.lpi
   if [ -e bin/project1 ]
   then
      echo lazbuild bin/project1 OK
      exit 0
   else
      echo attempt $i failed: $?
   fi
done

Best regards,
antispam88
Title: Re: Lazbuild EAccessViolation
Post by: Arvur on January 17, 2019, 09:15:05 pm
That's really strange. We have Jenkins on another machine. It just starts lazbuild over ssh with plink.exe from Putty. And the same way - no errors after re-run.
Title: Re: Lazbuild EAccessViolation
Post by: valdir.marcos on January 17, 2019, 09:40:59 pm
I have just opened a ticket about a minor problem I had found in lazbuild:
0034892: (lazbuild) package not found: c:\lazarus\source\lazarus\examples\hello.lp
https://bugs.freepascal.org/view.php?id=34892



Since some of you are using Jenkins or Travis CI on a regular basis for continuous integration, can you collect more data (logs) to strip down this randomly strange behavior of lazbuild?

Maybe something similar to:
Code: Bash  [Select][+][-]
  1. if [ -e bin/project1 ]
  2. then
  3.         rm bin/project1;
  4.         err=$?
  5.         if [ $err -ne 0 ]; then exit $err; fi
  6. fi
  7. for i in {1..10..1}
  8. do
  9.         # /home/pi/fpupdeluxe/lazarus/lazbuild /home/pi/project1/project1.lpi
  10.         /home/pi/fpupdeluxe/lazarus/lazbuild   --version   --verbose   --verbose-pkgsearch   /home/pi/project1/project1.lpi   1> lazbuild."`date +%Y%m%d_%H%M%S`".log.txt   2> lazbuild."`date +%Y%m%d_%H%M%S`".error.log.txt
  11.         if [ -e bin/project1 ]
  12.         then
  13.                 echo lazbuild bin/project1 OK
  14.                 exit 0
  15.         else
  16.                 echo attempt $i failed: $?
  17.         fi
  18. done
  19.  
Title: Re: Lazbuild EAccessViolation
Post by: Arvur on February 15, 2019, 10:05:28 am
Here are two slightly different logs. Moreover - once I've seen this error without Jenkins.

Lazarus 2.0RC3, Mac OS X Mojave 10.14.3
Title: Re: Lazbuild EAccessViolation
Post by: Arvur on February 15, 2019, 10:38:51 am
And I've got just same error with lazbuild in Mac OS Terminal right now! It has more info:
Quote
An unhandled exception occurred at $0001B943:
EAccessViolation: Access violation
  $0001B943
  $005C6334
  $005C7703
  $0002CB46

TProject.DoLoadStateFile Statefile not found: /Users/Administrator/Build/dcu/i386-darwin/bssPluginHost.compiled
An unhandled exception occurred at $000CD0F1:
EAccessViolation: Access violation
  $000CD0F1
  $000D1C8B
  $005DA155
  $005D9525
  $001B3AE2
  $00014881
  $00013AA5
  $000120E6
  $00017986

Marked memory at $042C5BA0 invalid
Wrong signature $AAAAAAAA instead of 4A31CCE6
Title: Re: Lazbuild EAccessViolation
Post by: Arvur on February 15, 2019, 11:25:05 am
And Call Stack from lazbuild ran in IDE:
Quote
#0 FPC_CHECK_OBJECT_EXT at :-1
#1 SETTHREAD(0x07745f60, 0x00000000) at exttools.pas:403
#2 SETTOOL(0x0764b030, 0x00000000) at exttools.pas:1307
#3 DESTROY(0x0764b030, 0x00000001) at exttools.pas:1596
#4 SYSTEM$_$TOBJECT_$__$$_FREE at :-1
#5 CLASSES_$$_THREADFUNC$POINTER$$LONGINT at :-1
#6 CTHREADS_$$_THREADMAIN$POINTER$$POINTER at :-1
#7 _pthread_body at :-1
#8 _pthread_start at :-1
#9 thread_start at :-1
Title: Re: Lazbuild EAccessViolation
Post by: Arvur on February 15, 2019, 12:03:34 pm
Upgraded to Lazarus 2.0 Release. The problem is still here (((
Title: Re: Lazbuild EAccessViolation
Post by: Arvur on February 26, 2019, 12:50:03 pm
I've found the reason :o It is relative(?) path to unit in lpr-file uses clause:
Code: Pascal  [Select][+][-]
  1. uses
  2.   Interfaces,
  3.   Unit1 in '..\..\<Path>\Unit1.pas',
  4.   Unit2;
  5.  
This bug is not stable. But with 100+ paths in lpr it fails always! :D
Title: Re: Lazbuild EAccessViolation
Post by: valdir.marcos on March 14, 2019, 03:08:50 am
Quote from: Arvur on February 26, 2019, 12:50:03 pm
I've found the reason :o It is relative(?) path to unit in lpr-file uses clause:
Code: Pascal  [Select][+][-]
  1. uses
  2.   Interfaces,
  3.   Unit1 in '..\..\<Path>\Unit1.pas',
  4.   Unit2;
  5.  
This bug is not stable. But with 100+ paths in lpr it fails always! :D
I have created a new simple project (attached) with 100+ forms on a 10-level deep path and it's not enough to confirm your report.
I have build it successfully on Windows with command:
Code: Text  [Select][+][-]
  1. C:\lazarus>c:\lazarus\lazbuild.exe  --lazarusdir=c:\lazarus\  --verbose  --verbose-pkgsearch  -B  C:\teste\Project_Lazbuild_EAccessViolation2\project1.lpi

The only difference, I have realized so far is LPR file does not show path information for units:
Code: Pascal  [Select][+][-]
  1. program project1;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. uses
  6.   {$IFDEF UNIX}{$IFDEF UseCThreads}
  7.   cthreads,
  8.   {$ENDIF}{$ENDIF}
  9.   Interfaces, // this includes the LCL widgetset
  10.   Forms, Unit1, Unit2, Unit3, Unit4, Unit5, Unit6, Unit7, Unit8, Unit9, Unit10,
  11.   Unit11, Unit12, Unit13, Unit14, Unit15, Unit16, Unit17, Unit18, Unit19,
  12.   Unit20, Unit21, Unit22, Unit23, Unit24, Unit25, Unit26, Unit27, Unit28,
  13.   Unit29, Unit30, Unit31, Unit32, Unit33, Unit34, Unit35, Unit36, Unit37,
  14.   Unit38, Unit39, Unit40, Unit41, Unit42, Unit43, Unit44, Unit45, Unit46,
  15.   Unit47, Unit48, Unit49, Unit50, Unit51, Unit52, Unit53, Unit54, Unit55,
  16.   Unit56, Unit57, Unit58, Unit59, Unit60, Unit61, Unit62, Unit63, Unit64,
  17.   Unit65, Unit66, Unit67, Unit68, Unit69, Unit70, Unit71, Unit72, Unit73,
  18.   Unit74, Unit75, Unit76, Unit77, Unit78, Unit79, Unit80, Unit81, Unit82,
  19.   Unit83, Unit84, Unit85, Unit86, Unit87, Unit88, Unit89, Unit90, Unit91,
  20.   Unit92, Unit93, Unit94, Unit95, Unit96, Unit97, Unit98, Unit99, Unit100,
  21.   Unit101, Unit102, Unit103, Unit104, Unit105, Unit106, Unit107, Unit108,
  22.   Unit109, Unit110, Unit111, Unit112, Unit113, Unit114, Unit115, Unit116,
  23.   Unit117, Unit118, Unit119, Unit120, Unit121
  24.   { you can add units after this };
  25.  
  26. {$R *.res}
  27.  
  28. begin
  29.   RequireDerivedFormResource := True;
  30.   Application.Initialize;
  31.   Application.CreateForm(TForm1, Form1);
  32.   ...
  33.   Application.CreateForm(TForm121, Form121);
  34.   Application.Run;
  35. end.



But both LPI and LPS do:
Code: XML  [Select][+][-]
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <CONFIG>
  3.   <ProjectOptions>
  4.     <Version Value="10"/>
  5.     <PathDelim Value="\"/>
  6.     <General>
  7.       <SessionStorage Value="InProjectDir"/>
  8.       <MainUnit Value="0"/>
  9.       <Title Value="project1"/>
  10.       <ResourceType Value="res"/>
  11.       <UseXPManifest Value="True"/>
  12.       <Icon Value="0"/>
  13.     </General>
  14.     <VersionInfo>
  15.       <StringTable ProductVersion=""/>
  16.     </VersionInfo>
  17.     <BuildModes Count="1">
  18.       <Item1 Name="Default" Default="True"/>
  19.     </BuildModes>
  20.     <PublishOptions>
  21.       <Version Value="2"/>
  22.     </PublishOptions>
  23.     <RunParams>
  24.       <local>
  25.         <FormatVersion Value="1"/>
  26.       </local>
  27.     </RunParams>
  28.     <RequiredPackages Count="1">
  29.       <Item1>
  30.         <PackageName Value="LCL"/>
  31.       </Item1>
  32.     </RequiredPackages>
  33.     <Units Count="122">
  34.       <Unit0>
  35.         <Filename Value="project1.lpr"/>
  36.         <IsPartOfProject Value="True"/>
  37.       </Unit0>
  38.       <Unit1>
  39.         <Filename Value="unit1.pas"/>
  40.         <IsPartOfProject Value="True"/>
  41.         <ComponentName Value="Form1"/>
  42.         <ResourceBaseClass Value="Form"/>
  43.         <UnitName Value="Unit1"/>
  44.       </Unit1>
  45.       <Unit2>
  46.         <Filename Value="folder01\folder02\folder03\folder04\folder05\folder06\folder07\folder08\folder09\folder10\unit2.pas"/>
  47.         <IsPartOfProject Value="True"/>
  48.         <ComponentName Value="Form2"/>
  49.         <ResourceBaseClass Value="Form"/>
  50.         <UnitName Value="Unit2"/>
  51.       </Unit2>
  52.       <Unit3>
  53.         <Filename Value="folder01\folder02\folder03\folder04\folder05\folder06\folder07\folder08\folder09\folder10\unit3.pas"/>
  54.      
  55.       ...
  56.      
  57.       <Unit121>
  58.         <Filename Value="folder01\folder02\folder03\folder04\folder05\folder06\folder07\folder08\folder09\folder10\unit121.pas"/>
  59.         <IsPartOfProject Value="True"/>
  60.         <ComponentName Value="Form121"/>
  61.         <ResourceBaseClass Value="Form"/>
  62.         <UnitName Value="Unit121"/>
  63.       </Unit121>
  64.     </Units>
  65.   </ProjectOptions>
  66.   <CompilerOptions>
  67.     <Version Value="11"/>
  68.     <PathDelim Value="\"/>
  69.     <Target>
  70.       <Filename Value="project1"/>
  71.     </Target>
  72.     <SearchPaths>
  73.       <IncludeFiles Value="$(ProjOutDir)"/>
  74.       <OtherUnitFiles Value="folder01\folder02\folder03\folder04\folder05\folder06\folder07\folder08\folder09\folder10"/>
  75.       <UnitOutputDirectory Value="lib\$(TargetCPU)-$(TargetOS)"/>
  76.     </SearchPaths>
  77.     <Linking>
  78.       <Options>
  79.         <Win32>
  80.           <GraphicApplication Value="True"/>
  81.         </Win32>
  82.       </Options>
  83.     </Linking>
  84.   </CompilerOptions>
  85.   <Debugging>
  86.     <Exceptions Count="3">
  87.       <Item1>
  88.         <Name Value="EAbort"/>
  89.       </Item1>
  90.       <Item2>
  91.         <Name Value="ECodetoolError"/>
  92.       </Item2>
  93.       <Item3>
  94.         <Name Value="EFOpenError"/>
  95.       </Item3>
  96.     </Exceptions>
  97.   </Debugging>
  98. </CONFIG>



Code: Pascal  [Select][+][-]
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <CONFIG>
  3.   <ProjectSession>
  4.     <PathDelim Value="\"/>
  5.     <Version Value="10"/>
  6.     <BuildModes Active="Default"/>
  7.     <Units Count="122">
  8.       <Unit0>
  9.         <Filename Value="project1.lpr"/>
  10.         <IsPartOfProject Value="True"/>
  11.         <IsVisibleTab Value="True"/>
  12.         <TopLine Value="4"/>
  13.         <CursorPos X="20" Y="14"/>
  14.         <UsageCount Value="20"/>
  15.         <Loaded Value="True"/>
  16.       </Unit0>
  17.       <Unit1>
  18.         <Filename Value="unit1.pas"/>
  19.         <IsPartOfProject Value="True"/>
  20.         <ComponentName Value="Form1"/>
  21.         <HasResources Value="True"/>
  22.         <ResourceBaseClass Value="Form"/>
  23.         <UnitName Value="Unit1"/>
  24.         <EditorIndex Value="1"/>
  25.         <TopLine Value="17"/>
  26.         <CursorPos X="23" Y="34"/>
  27.         <UsageCount Value="20"/>
  28.         <Loaded Value="True"/>
  29.         <LoadedDesigner Value="True"/>
  30.       </Unit1>
  31.       <Unit2>
  32.         <Filename Value="folder01\folder02\folder03\folder04\folder05\folder06\folder07\folder08\folder09\folder10\unit2.pas"/>
  33.         <IsPartOfProject Value="True"/>
  34.         <ComponentName Value="Form2"/>
  35.         <HasResources Value="True"/>
  36.         <ResourceBaseClass Value="Form"/>
  37.         <UnitName Value="Unit2"/>
  38.         <EditorIndex Value="2"/>
  39.         <UsageCount Value="20"/>
  40.         <Loaded Value="True"/>
  41.         <LoadedDesigner Value="True"/>
  42.       </Unit2>
  43.      
  44.       ...
  45.      
  46.       <Unit121>
  47.         <Filename Value="folder01\folder02\folder03\folder04\folder05\folder06\folder07\folder08\folder09\folder10\unit121.pas"/>
  48.         <IsPartOfProject Value="True"/>
  49.         <ComponentName Value="Form121"/>
  50.         <HasResources Value="True"/>
  51.         <ResourceBaseClass Value="Form"/>
  52.         <UnitName Value="Unit121"/>
  53.         <EditorIndex Value="121"/>
  54.         <UsageCount Value="20"/>
  55.         <Loaded Value="True"/>
  56.         <LoadedDesigner Value="True"/>
  57.       </Unit121>
  58.     </Units>
  59.     <JumpHistory HistoryIndex="-1"/>
  60.   </ProjectSession>
  61. </CONFIG>



Quote from: Arvur on February 26, 2019, 12:50:03 pm
This bug is not stable. But with 100+ paths in lpr it fails always! :D
Can you provide a simple sample project that shows that error?
Title: Re: Lazbuild EAccessViolation
Post by: valdir.marcos on March 14, 2019, 07:34:37 am
Quote from: JuhaManninen on January 18, 2018, 12:39:54 am
Your backtrace looks like there is no debug info.
Does the problem happen only with a certain program? Then you should upload it here to be tested.
Juha, when I put "--version" on a Lazbuild command, it just shows the version of Lazbuild ignoring all the rest.
Should this be the expected behaviour?
Code: Text  [Select][+][-]
  1. C:\lazarus>c:\lazarus\lazbuild.exe  --version  --lazarusdir=c:\lazarus\  --verbose  --verbose-pkgsearch  -B  C:\teste\Project_Lazbuild_EAccessViolation2\project1.lpi

But without the "--version", the command works properly:
Code: Text  [Select][+][-]
  1. C:\lazarus>c:\lazarus\lazbuild.exe  --lazarusdir=c:\lazarus\  --verbose  --verbose-pkgsearch  -B  C:\teste\Project_Lazbuild_EAccessViolation2\project1.lpi
Title: Re: Lazbuild EAccessViolation
Post by: Arvur on March 14, 2019, 03:47:15 pm
Quote from: valdir.marcos on March 14, 2019, 03:08:50 am
I have build it successfully on Windows
I've never seen this error on Windows. Mac OS X only!

Quote from: valdir.marcos on March 14, 2019, 03:08:50 am
The only difference, I have realized so far is LPR file does not show path information for units:
The main point is paths in lpr )) When I remove them all works fine on Mac OS too.

Quote from: valdir.marcos on March 14, 2019, 03:08:50 am
Can you provide a simple sample project that shows that error?
I did not manage to reproduce it on an clean empty project. One hundred units with paths in lpr and empty search path in lpi, some uses, relative folders and... it still works. There must be something else.
Title: Re: Lazbuild EAccessViolation
Post by: JuhaManninen on March 15, 2019, 02:02:13 am
Quote from: valdir.marcos on March 14, 2019, 07:34:37 am
Juha, when I put "--version" on a Lazbuild command, it just shows the version of Lazbuild ignoring all the rest.
Should this be the expected behaviour?
Yes, that's how it is implemented. TLazBuildApplication.ParseParameters has:
Code: Pascal  [Select][+][-]
  1. if HasOption('v','version') then begin
  2.   writeln(VersionStr);
  3.   exit;
  4. end;
It could be changed if needed, but would it make sense?
You don't need the version when actually building something.
Title: Re: Lazbuild EAccessViolation
Post by: Arvur on March 20, 2019, 03:26:31 pm
Today I've catched this problem again on a project without paths in lpr. Twice. Fixed with Mac OS reboot.

It seems paths are not the only reason. But I have no idea how to investigate it deeper :-[
Title: Re: Lazbuild EAccessViolation
Post by: JuhaManninen on March 20, 2019, 06:16:14 pm
There is a bug report about a crash in LazBuild.
 https://bugs.freepascal.org/view.php?id=32340
Nobody could figure out the reason yet.
TinyPortal © 2005-2018