On Wed, 22 Aug 2012 09:40:22 +0000 Mark Morgan Lloyd <[email protected]> wrote:
> Mattias Gaertner wrote: > > On Wed, 22 Aug 2012 08:59:26 +0000 > > Mark Morgan Lloyd <[email protected]> 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 -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
