[Lazarus] Access violation in build_lcl_docs --outfmt chm
AndrewD207 at aol.com
Wed Mar 7 04:23:07 CET 2012
On 03/01/12 18:15, Andrew Haines wrote:
> On 03/01/12 13:51, Mattias Gaertner wrote:
>> On Thu, 01 Mar 2012 17:31:47 +0100
>> Thomas Moritz <thm_ml at thmoritz.de> wrote:
>>> this is the output:
>>> HTML Files written. Collecting other files and compressing...this could take some time
>>> Generating Table of contents...
>>> Generating Index...
>>> Finishing compressing...
>>> Exception at 00000000004FFF6F: EAccessViolation:
>>> Access violation.
>>> 'lcl.chm' has 0 Byte
>>> openSUSE 12.1 x86_64
>>> fpc 2.7.1 svn 20450
>>> lazarus svn 35641
>> It is a bug in the 2.7.1 version of the chmwriter.
>> Can you create a backtrace?
>> Maybe Andrew Haines can help.
> I managed to reproduce this. I cannot look into it for a couple of days
> though. I wonder if something has changed in fpc because it worked until
> I updated all of fpc but my chm folder was already up to date.
> I got a backtrace by compiling the packages/chm and util/fpdoc with make
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000005072e5 in WRITEHEADER (this=0x7ffff33f9c80,
> ISPLACEHOLDER=false) at src/chmfiftimain.pas:291
> 291 FHeaderRec.LeafNodeCount := TLeafNode(FActiveLeafNode).LeafNodeCount;
Ok I used Graeme's fpc git repo and git bisect and was able to find the
revision that now causes chmwriter to crash
Revision 20196 is the culprit.
Author: Sergei Gorelkin <sergei at freepascal.org>
Date: Mon Jan 30 09:09:49 2012 +0000
* Changed generic StrCopy and StrECopy to use IndexByte+Move:
o Makes behavior predictable in cases when source and destination
strings happen to overlap.
o Removes need in CPU-specific implementations, at least for CPUs
having optimized IndexByte and Move implementations.
I can't look at this further today but will keep looking when I have
some time in a few days. Maybe the answer is obvious to someone else.
More information about the Lazarus