Frank,
Hard to tell without seeing anything of your code.
yes - I know. But since the (final) error occurs in the string.pas which in fact is from the gpc sources (I have built gpc from source) I was wondering, if someone knows what is going on in this routines.
I don't know ddd well, but in gdb, `info stack' shows the active stack frames, i.e. the sequence of routines called when the crash occurred.
Program received signal SIGSEGV, Segmentation fault. 0x52c00 in Kludgestreq (S1=0xff3f00d0, L1=10, S2=0xa49b8, L2=10) at /home/AIDA301/eicksch/gpc/gcc-2.95.2/gcc/p/rts/string.pas:813 813 KludgeStrEQ := StrEQ (s1^[1 .. l1], s2^[1 .. l2]) (gdb) info stack #0 0x52c00 in Kludgestreq (S1=0xff3f00d0, L1=10, S2=0xa49b8, L2=10) at /home/AIDA301/eicksch/gpc/gcc-2.95.2/gcc/p/rts/string.pas:813 Cannot access memory at address 0xff3effc4.
This might give a hint as to where the problem is. (It's not impossible that the bugs really is in GPC, but it might just as well be in your code, and without more information, I could only guess.)
I know ;( Please, let me know, what infos - and how to gather them - you would need and I will try to get them out of this lousy box...
One obvious difference between Sparc and IA32 is endianness, so if the code contains any low-level tricks (which is not uncommon in BP code), you might want to check them out if they implicitly assume little-endian or something like that.
Hmmm - as far as I see from the code there are no operations using byte arithmetics. The program reads an ASCII and makes _many_ sorting operations on it. I fear that the seg fault results from a memory overflow / too small sized arrays or something like that...
Stephan