[Lazarus] Access violation in build_lcl_docs --outfmt chm

Mattias Gaertner nc-gaertnma at netcologne.de
Wed Mar 7 09:22:00 CET 2012


On Tue, 06 Mar 2012 22:23:07 -0500
Andrew Haines <AndrewD207 at aol.com> wrote:

> 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:
> >>
> >>> Hello,
> >>>
> >>> 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
> > OPT=-gl
> > 
> > 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.
> 
> commit b36ea3c90ec702643aa0505799683a3b7f9c3ce1
> 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.
> 
>     git-svn-id: http://svn.freepascal.org:/svn/fpc/trunk@20196
> 3ad0048d-3df7-0310-abae-a5850022a9f2
> 
> 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.

The chm units uses ansi and widestrings. FPC now has string encodings,
so you now have to be more careful when mixing strings of different
kind. For performance and avoiding conversion bugs it is better
to use only one type of strings.

Mattias




More information about the Lazarus mailing list