[Lazarus] RE : FPC_REQUIRES_PROPER_ALIGNMENTdefinedonSolariscausescrash in lazarus

[Mark Morgan Lloyd]

Ludo Brands wrote:
>> Still working on the problem in StdCodeTools.
>>
> 
> Attached patches to http://bugs.freepascal.org/view.php?id=19109. I suggest
> you keep this bug open for a while and that we attach alignment fixes as we
> encounter them.
> 
> Just found another possible problematic piece of code in jitforms.pp in
> function ClassTypeInfoAsString. Others in ide\emptymethodsdlg.pas and
> ideintf\propedits.pp ... 

With those three patches applied basic operation appears OK, but I might 
now be seeing different behavior on the three systems I'm testing.

First, on ARM Linux (Debian "Squeeze") running in the context of Qemu I 
am able to build a non-trivial program (several units, background 
thread, database access) which runs successfully. I've not yet tested 
debugger access etc.

Second, on SPARC Linux (Debian "Lenny") running on a Sun Ultra-1 with a 
minimal project (button on form -> close) I get this during "Build All":

Compiling project1.lpr
Compiling unit1.pas
unit1.pas(16,25) Hint: Parameter "Sender" not used
Assembling unit1
Assembling project1
Compiling resource /home/markMLl/lib/sparc-linux/project1.or

Program received signal SIGBUS, Bus error.
[Switching to Thread 0xf7fa5aa0 (LWP 3925)]
0x00686ee8 in TREGEXPR__EMITNODE (OP=6 #6, this=0xf6129660) at 
synregexpr.pas:1507
1507         PRENextOff (regcode)^ := 0; // Next "pointer" := nil
(gdb) bt
#0  0x00686ee8 in TREGEXPR__EMITNODE (OP=6 #6, this=0xf6129660) at 
synregexpr.pas:1507
#1  0x00687b3c in TREGEXPR__PARSEBRANCH (FLAGP=0, this=0xf6129660) at 
synregexpr.pas:1820
#2  0x00687790 in TREGEXPR__PARSEREG (PAREN=0, FLAGP=1, this=0xf6129660) 
at synregexpr.pas:1756
#3  0x006873d4 in TREGEXPR__COMPILEREGEXPR (EXP=0xf5d700d0 'Unit 
"[a-z_0-9]+" not used in [a-z_0-9]+',
     this=0xf6129660) at synregexpr.pas:1669
#4  0x00686b3c in TREGEXPR__COMPILE (this=0xf6129660) at synregexpr.pas:1423
#5  0x00686c74 in TREGEXPR__ISPROGRAMMOK (this=0xf6129660) at 
synregexpr.pas:1448
#6  0x0068e588 in TREGEXPR__EXECPRIM (AOFFSET=1, this=0xf6129660) at 
synregexpr.pas:3453
#7  0x0068e550 in TREGEXPR__EXECPOS (AOFFSET=1, this=0xf6129660) at 
synregexpr.pas:3414
#8  0x007f6638 in SYNREMATCHES (
     THETEXT=0xf5a81e78 'Compiling resource 
/home/markMLl/lib/sparc-linux/project1.or',
     REGEXPR=0xfab824 'Unit "[a-z_0-9]+" not used in [a-z_0-9]+', 
MODIFIERSTR=0xf48388 'I', STARTPOS=1)
     at sourceeditprocs.pas:729
#9  0x0057be58 in REMATCHES (
     THETEXT=0xf5a81e78 'Compiling resource 
/home/markMLl/lib/sparc-linux/project1.or',
     REGEXPR=0xfab824 'Unit "[a-z_0-9]+" not used in [a-z_0-9]+', 
MODIFIERSTR=0xf48388 'I', STARTPOS=1)
     at texttools.pas:121
#10 0x005d8560 in TIDEMSGQUICKFIXITEM__ISAPPLICABLE (LINE=0xf613b820, 
this=0xf65c9f60) at idemsgintf.pas:450
#11 0x008570ec in TMESSAGESVIEW__UPDATEMSGICONS (this=0xf60b1b70) at 
msgview.pp:1185
#12 0x008562e4 in TMESSAGESVIEW__IDLETIMER1TIMER (SENDER=0xf600b220, 
this=0xf60b1b70) at msgview.pp:957
#13 0x0025ad0c in TCUSTOMTIMER__DOONTIMER (this=0xf600b220) at 
customtimer.pas:181
#14 0x0025ac30 in TCUSTOMTIMER__TIMER (this=0xf600b220) at 
customtimer.pas:156
#15 0x00327028 in GTKTIMERCB (DATA=0xf61c2c20) at gtk2callback.inc:2406
#16 0xf787cb40 in ?? () from /usr/lib/libglib-2.0.so.0
#17 0xf787cb40 in ?? () from /usr/lib/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I don't know what to make of the "corrupt stack" messages which resemble 
something from an older version which had debugging record errors. They 
might be a red herring since lazbuild and generated code are OK on this 
system.

Third, on ARM Linux (Debian "Lenny") running natively on an NSLU2 "Slug" 
I appear to get a failure building a program. This is using Lazarus 
built on the Qemu system (building natively takes an unacceptable length 
of time), I don't yet have a backtrace etc. on account of slow operation 
on this system (work continues).

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]