Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2012-08

IDE invocation of lhelp, probable endianness issue

9 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Mark Morgan Lloyd

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.

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.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Mattias Gaertner
to Mark Morgan Lloyd
Show quoted text 5 lines
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?

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.

Mattias

Reply by email

Mark Morgan Lloyd
to Mattias Gaertner
Mattias Gaertner wrote 10 lines
On Wed, 22 Aug 2012 08:59:26 +0000 Mark Morgan Lloyd 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)^); 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).

Show quoted text 6 lines
> 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.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Mark Morgan Lloyd
to Mark Morgan Lloyd
Mark Morgan Lloyd wrote 15 lines
Mattias Gaertner wrote: > On Wed, 22 Aug 2012 08:59:26 +0000 > Mark Morgan Lloyd 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.

On PPC (Mac G3 running Debian "Lenny") I get the "Unknown..." exception in the IDE but don't get an error in lhelp.

I see neither error on ARM (Debian "Squeeze"). However this is an armv5tejl as implemented by Qemu emulation, and it might not be as touchy on alignment issues as something like a genuine armv5tel or there might be better OS-level handling.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Mattias Gaertner
to Mark Morgan Lloyd: With the dialogue displayed, the IDE is unresponsive but lhelp is running. In that state,…
Show quoted text 22 lines
Mattias Gaertner wrote: > On Wed, 22 Aug 2012 08:59:26 +0000 > Mark Morgan Lloyd 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.

Show quoted text 61 lines
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

Reply by email

Sven Barth
to Mattias Gaertner
Mattias Gaertner wrote 28 lines
On Wed, 22 Aug 2012 09:40:22 +0000 Mark Morgan Lloyd wrote: > Mattias Gaertner wrote: >> On Wed, 22 Aug 2012 08:59:26 +0000 >> Mark Morgan Lloyd 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.

At least it's a pointer dereference... so there must indeed be some misalignment going on...

Regards,
Sven

Reply by email

Mark Morgan Lloyd
to Mattias Gaertner: On Wed, 22 Aug 2012 09:40:22 +0000 I'm not familiar with the chmreader code. Please…
Mattias Gaertner wrote 26 lines
On Wed, 22 Aug 2012 09:40:22 +0000 Mark Morgan Lloyd wrote: > Mattias Gaertner wrote: >> On Wed, 22 Aug 2012 08:59:26 +0000 >> Mark Morgan Lloyd 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.

I've raised the IDE exception (SPARC and PPC Linux but not SPARC Solaris) as http://mantis.freepascal.org/view.php?id=22696

I've raised the lhelp exception (SPARC Linux plus SPARC Solaris 10) as http://mantis.freepascal.org/view.php?id=22697

Unfortunately, I've put gdb output in #22696 which isn't relevant: that error is silent apart from the modal dialogue and the output is relevant to #22697. My apologies for the mess and any confusion caused.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Marco van de Voort
to Sven Barth: At least it's a pointer dereference... so there must indeed be some misalignment going…
Sven Barth wrote 13 lines
>> >> 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. At least it's a pointer dereference... so there must indeed be some misalignment going on...

I think a lot of internal records are read that way. Arbitrary pointers are pointed to records in buffers (decompressed datastructures), and then iterated like this.

So there might be hundreds of such cases. Afaik alignment is hardly tested, and endianess only quick.

Reply by email

Mark Morgan Lloyd
to Marco van de Voort
Marco van de Voort wrote 18 lines
On Wed, Aug 22, 2012 at 02:35:47PM +0200, Sven Barth wrote: >>> 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. > At least it's a pointer dereference... so there must indeed be some > misalignment going on... I think a lot of internal records are read that way. Arbitrary pointers are pointed to records in buffers (decompressed datastructures), and then iterated like this. So there might be hundreds of such cases. Afaik alignment is hardly tested, and endianess only quick.

I'm happy to help with the testing of this on SPARC and PPC, even if my ability to fix it is limited due to lack of familiarity with the guts.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email