Hi all,
I am a little bit in trouble with gpc on solaris
gpc -v
Reading specs from /home/GFZS1/gnu/gpc/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/specs gpc version 20010924, based on 2.95.2 19991024 (release)
uname -a
SunOS aida3 5.8 Generic sun4u sparc SUNW,Ultra-5_10
The program is compiled and linked without any problems.
gpc -g -o antdb3 antdb3.pas
But running it yields to core dumps... I tried to investigate on it with ddd but unfortunatly, I get stucked right after the starting shot. I have to mention, that I did not write the program on my own - and I am not a pascal hacker. I used to code in pascal some years ago, but "switched" to C.
Maybe some of the wizards out there is able to help me to find the "malicious" code? As far as I know, the program was original written for BorlandPascal and then transferred to AIX using "extended syntax" (?). I tested it at home on ly linux box with gpc and everything works fine. So I installed gpc on our sun's but now I am in trouble...
###############################
DDD 3.0 (sparc-sun-solaris2.5.1), by Dorothea Luetkehaus and Andreas Zeller. Copyright (c) 1998 Technische Universitaet Braunschweig, Germany. (gdb) file /home/AIDA102/eicksch/bin/antdb3 Reading symbols from /home/AIDA102/eicksch/bin/antdb3...done. (gdb) set args (gdb) run Starting program: /home/AIDA102/eicksch/bin/antdb3 warning: Unable to find dynamic linker breakpoint function. warning: GDB will be unable to debug shared library initializers warning: and track explicitly loaded dynamic code.
Program received signal SIGSEGV, Segmentation fault. 0x52bb8 in Kludgestreq (S1=0xff3f00c8, L1=10, S2=0xa49b8, L2=10) at /home/AIDA301/eicksch/gpc/gcc-2.95.2/gcc/p/rts/string.pas:813 (gdb)
---- snip: string.pas -------------------------------------
807 function KludgeStrEQ (s1: PCharsKludge; l1: Integer; s2: PCharsKludge; l2: Integer): Boolean; asmname '_p_eq'; 808 function KludgeStrEQ (s1: PCharsKludge; l1: Integer; s2: PCharsKludge; l2: Integer): Boolean; 809 var c1, c2: Char; 810 begin 811 { @@ kluuuuuudge } if l1 < 0 then begin l1 := 1; c1 := Chr (PtrInt (s1)); s1 := PCharsKludge (@c1) end; 812 if l2 < 0 then begin l2 := 1; c2 := Chr (PtrInt (s2)); s2 := PCharsKludge (@c2) end; 813 KludgeStrEQ := StrEQ (s1^[1 .. l1], s2^[1 .. l2]) 814 end;
---- snap ------------------------------------------------
Any suggestion highly appreciated,
Stephan
Stephan Eickschen wrote:
But running it yields to core dumps... I tried to investigate on it with ddd but unfortunatly, I get stucked right after the starting shot. I have to mention, that I did not write the program on my own - and I am not a pascal hacker. I used to code in pascal some years ago, but "switched" to C.
Maybe some of the wizards out there is able to help me to find the "malicious" code? As far as I know, the program was original written for BorlandPascal and then transferred to AIX using "extended syntax" (?). I tested it at home on ly linux box with gpc and everything works fine. So I installed gpc on our sun's but now I am in trouble...
Hard to tell without seeing anything of your code. 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. 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.)
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.
Frank
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
Stephan Eickschen wrote:
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.
Well, this routine compares strings. As I said, it's not impossible that it contains a bug, but I can't see any in it. :-)
Perhaps the strings passed to it are invalid (dereference of an invalid pointer) or something.
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...
Optimally, the complete source of the program (if it's large, not posted to the list, but perhaps put on a web site) and instructions how to reproduce the bug.
If that's not possible, you could try to reduce the program to a simple and as short as possible program that still shows the bug. In this process, maybe you will find the cause of the problem in the program, or reduce it to a short case that help us find and fix a bug in GPC, if any.
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...
Might be. Oh, thinking of it, a typical mistake is:
var p: ^String;
GetMem (p, Length (foo) + 1); p^ := foo;
This works with BP's "short strings", but not with GPC's (EP schema) strings (use `New (p, Length (foo))' instead). If there are any occurrences of `GetMem' etc. in the program, check them carefully. You might also want to look at the chapter about BP in the GPC manual.
Frank
Optimally, the complete source of the program (if it's large, not posted to the list, but perhaps put on a web site) and instructions how to reproduce the bug.
You can find the complete source code at ftp://ftp.dfd.dlr.de/put/eicksch/GPC/antdb.pas The core dump happens some where around line 520. The file processed is "./sp21_22/ROCK00.E00", name1 is "sp21_22", kbd is "."
The output is like that:
---- snip ----------------------------------------------- ROCK00.AAT gefunden, anzparam = 14, lds = 224, anzds = 1802 ... Suche PAT suchstr = ROCK00.PAT ls = 10 (...) -2.4382450E+06 1.5352708E+06-2.4382450E+06 1.5352708E+06 -2.4382450E+06 1.5352708E+06-2.4382450E+06 1.5352708E+06 31269 806-2.5239723E+06 1.5353111E+06 Segmentation fault (core dumped) ---- snap -----------------------------------------------
So I searched for the line which causes the core dump:
grep -n 31269 sp21_22/ROCK00.E00
29874: 31269 806-2.5239723E+06 1.5353111E+06 42988: 5.7757500E+04 9.5319818E+02 806 31269rocks
and I searched for the line containing "suchstr":
grep -n ROCK00.PAT sp21_22/ROCK00.E00
42177:ROCK00.PAT XX 5 5 26 1245
ls -l sp21_22/ROCK00.E00
-rw-r--r-x 1 eicksch GFZ 2323977 Jul 11 2000 sp21_22/ROCK00.E00
If that's not possible, you could try to reduce the program to a simple and as short as possible program that still shows the bug. In this process, maybe you will find the cause of the problem in the program, or reduce it to a short case that help us find and fix a bug in GPC, if any.
If 60 lines are not too much: You will find an excerpt from the source code - including declarations and the 20 lines around the malicious code - at the end of mail.
You might also want to look at the chapter about BP in the GPC manual.
I will have a look at it...
Stephan
Stephan Eickschen wrote:
writeln('Suche PAT'); {PAT finden} reset(dat4,kbd3+'/'+name1+'.E00'); suchstr:=name1+'.PAT'; ls:=length(suchstr); writeln('suchstr = ', suchstr, ' ls = ',ls); repeat readln(dat4,zeile2); writeln(zeile2); repeat if length(zeile2)<ls then readln(dat4,zeile2); writeln(zeile2); until (length(zeile2)>(ls-1)); until (substr(zeile2,1,ls)=suchstr); writeln(suchstr, ' gefunden'); readstr(trim(substr(zeile2,36,3)),anzparama); readstr(trim(substr(zeile2,44,3)),ldsa); readstr(trim(substr(zeile2,48,9)),anzdsa); writeln(suchstr, ' gefunden, anzparama = ', anzparama, ', ldsa = ', ldsa, ', anzdsa = ', anzdsa, ' ... ');
This might be a case of a known GPC problem that causes a stack overflow if the loop runs very often. If it's that, than the crash should occur sooner or later depending on the stack limit set.
A work-around in this case could be to assign the loop condition (substr(zeile2,1,ls)=suchstr) to a Boolean variable and test this in the `until'.
Frank
Frank,
This might be a case of a known GPC problem that causes a stack overflow if the loop runs very often. If it's that, than the crash should occur sooner or later depending on the stack limit set.
A work-around in this case could be to assign the loop condition (substr(zeile2,1,ls)=suchstr) to a Boolean variable and test this in the `until'.
Thanks a lot! The program seems to work now...
Stephan
Stephan Eickschen wrote:
This might be a case of a known GPC problem that causes a stack overflow if the loop runs very often. If it's that, than the crash should occur sooner or later depending on the stack limit set.
A work-around in this case could be to assign the loop condition (substr(zeile2,1,ls)=suchstr) to a Boolean variable and test this in the `until'.
Thanks a lot! The program seems to work now...
Fine. The GPC bug might be fixed in the not too distant future, but I don't want to promise too much.
Frank
Russell Whitaker wrote:
On Tue, 27 Nov 2001, Stephan Eickschen wrote:
---- snip: source code ------------------------------------
[..]
type extended = real; longint = integer; byte =integer;
Is that ok??
If he wants the types like that, why not. However, GPC supports these types predefines (with different sizes; also different from BP).
Frank
-
Frank Heckenbach -
Russell Whitaker -
Stephan Eickschen