[Lazarus] IDE invocation of lhelp, probable endianness issue

[Mattias Gaertner]

On Wed, 22 Aug 2012 09:40:22 +0000
Mark Morgan Lloyd <markMLl.lazarus at telemetry.co.uk> wrote:

> Mattias Gaertner wrote:
> > On Wed, 22 Aug 2012 08:59:26 +0000
> > Mark Morgan Lloyd <markMLl.lazarus at telemetry.co.uk> wrote:
> > 
> >> On Linux running on either SPARC or PPC, trying to invoke 
> >> context-sensitive help (i.e. F1 key over a keyword) fails with a 
> >> dialogue e.g. "Unknown error showing 
> >> /forms/tapplication/initialize.html". There's no error addresses etc. on 
> >> the console, the exception doesn't break the IDE.
> > 
> > Sounds like a bug in lhelp. Can you start lhelp standalone and check?
> 
> With the dialogue displayed, the IDE is unresponsive but lhelp is 
> running. In that state, lhelp allows me to select a file but fails on 
> SPARC (not tested PPC, don't believe I see this on ARM) with a bus error.
> 
> Running lhelp from a shell using gdb gives me
> 
> Program received signal SIGBUS, Bus error.
> [Switching to Thread 16384 (LWP 25970)]
> 0x0038c844 in _$CHMREADER$_Ll594 () at src/chmreader.pas:1144
> 1144                        ind:=LEToN(plongint(head)^);

I'm not familiar with the chmreader code. 
Please create a bug report.


> Current language:  auto; currently pascal
> (gdb)
> (gdb)
> (gdb) bt
> #0  0x0038c844 in _$CHMREADER$_Ll594 () at src/chmreader.pas:1144
> #1  0x0038c400 in _$CHMREADER$_Ll561 () at src/chmreader.pas:1197
> #2  0x00365ed4 in TCHMCONTENTPROVIDER__FILLTOC (DATA=-153649120, 
> this=0xf7118140) at chmcontentprovider.pas:514
> #3  0x000d504c in TAPPLICATION__PROCESSASYNCCALLQUEUE (this=0xf7174030) 
> at ./include/application.inc:1087
> #4  0x000d2c48 in TAPPLICATION__PROCESSMESSAGES (this=0xf7174030) at 
> ./include/application.inc:386
> #5  0x003651c4 in TCHMCONTENTPROVIDER__DOLOADURI (URI=0xf71cd738, 
> ACHM=0x0, this=0xf7118140)
>      at chmcontentprovider.pas:334
> #6  0x003681ec in TCHMCONTENTPROVIDER__LOADURL (AURL=0xf71bc9d8, 
> ACONTEXT=-1, this=0xf7118140)
>      at chmcontentprovider.pas:1033
> #7  0x000e20ac in THELPFORM__OPENURL (AURL=0xf71bc9d8, ACONTEXT=-1, 
> this=0xf717d940) at lhelpcore.pas:596
> #8  0x000dff24 in THELPFORM__FILEMENUOPENITEMCLICK (SENDER=0xf6ea4160, 
> this=0xf717d940) at lhelpcore.pas:179
> #9  0x00202df8 in TMENUITEM__CLICK (this=0xf6ea4160) at 
> ./include/menuitem.inc:83
> #10 0x0020381c in TMENUITEM__DOCLICKED (MSG=void, this=0xf6ea4160) at 
> ./include/menuitem.inc:278
> #11 0x00035404 in _$SYSTEM$_Ll7225 () at 
> /usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/rtl/inc/objpas.inc:592
> #12 0x0029aa08 in DELIVERMESSAGE (TARGET=0xf6ea4160, AMESSAGE=void) at 
> lclmessageglue.pas:119
> #13 0x00261208 in DELIVERMESSAGE (TARGET=0xf6ea4160, AMESSAGE=void) at 
> gtk2proc.inc:3591
> #14 0x002e2cc4 in GTK2MENUITEMACTIVATE (WIDGET=0x6d00d0, 
> DATA=0xf6ea4160) at gtk2wsmenus.pp:138
> #15 0xf79887e8 in g_cclosure_marshal_VOID__VOID () from 
> /usr/lib/libgobject-2.0.so.0
> #16 0xf7979c0c in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
> #17 0xf798c73c in g_signal_chain_from_overridden () from 
> /usr/lib/libgobject-2.0.so.0
> #18 0xf798de6c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
> #19 0xf798e01c in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
> #20 0xf7cbc0ac in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0
> #21 0xf7bca5ac in gtk_menu_shell_activate_item () from 
> /usr/lib/libgtk-x11-2.0.so.0
> #22 0xf7bcbc4c in gtk_menu_shell_append () from /usr/lib/libgtk-x11-2.0.so.0
> #23 0xf7bcbc4c in gtk_menu_shell_append () from /usr/lib/libgtk-x11-2.0.so.0
> Previous frame identical to this frame (corrupt stack?)
> 
> Sorry about the delay getting this reported (see below).
> 
> >> I don't see this on x86 or ARM (Linux, not testing Windows). Seeing it 
> >> on PPC but not ARM suggests that it's an endianness rather than 
> >> alignment issue. I'm not yet able to test on SPARC Solaris due to the 
> >> slowness of fpdoc on that combination.
> > 
> > The chm files are the same on all platforms.
> 
> I was assuming that (but I was going to checksum them anyway). However 
> once the build had started I didn't want to interrupt it, my script 
> counts the number of lines output as reassurance during long builds and 
> I can see it's not far from complete.

There was a similar bug on x86_64. The chmwriter allocated too much
memory and the resulting chm was buggy.

Mattias