Gpc

gpc@gnu.de

5400 discussions

Re: list trouble solved
by Toby Ewing 24 Jun '02

24 Jun '02

Finally got it. In the end the problem wasn't in the list work at all. Way earlier in the program, I'd allocated memory for an array [1..x], then accessed it as [0..x]. On freeing the memory, I guess something funny was set up in the memory manager that came back to bite me way later. So... is there a compiler option I could have set that would have told me about this illegal memory access? well, now perhaps I can sleep. Toby

4 8

Installing GPC on HP-UX 11.0
by Nick Ioffe 24 Jun '02

24 Jun '02

Hi! I'm trying to install GPC on HP-UX 11.00 machine I've got GPC and gcc-core.2.95.x sources from the archive site and tried to build it. After several failures I've tried to build GCC only and then failed again. Then I've checked the GCC site at gcc.gnu.org and that is what it says: http://gcc.gnu.org/install/specific.html#hppa*-hp-hpux11 GCC 3.0 and up support HP-UX 11. You must use GNU binutils 2.11 or above on this platform. Thread support is not currently implemented for this platform, so --enable-threads does not work. See http://gcc.gnu.org/ml/gcc-prs/2002-01/msg00551.html and http://gcc.gnu.org/ml/gcc-bugs/2002-01/msg00663.html. GCC 2.95.x is not supported under HP-UX 11 and cannot be used to compile GCC 3.0 and up. Refer to binaries for information about obtaining precompiled GCC binaries for HP-UX. I wonder whether I can build the GPC in such a case??? Also what if I'll download gcc-core.3.x instead of gcc-core.2.95.x? Will I be able to build GPC in such a case??? Sincerely, Nick

1 0

Re: list trouble solved
by da Silva, Joe 24 Jun '02

24 Jun '02

To quote Frank on 2002/04/09 : The memory leak is not in the unit, but in GPC itself. It's a known problem with some string operations (especially concatenation) in a loop. (If you can read /proc/n/maps, you'll see that it's the stack, not the heap that grows.) Moving the thing out of the loop (syntactically, e.g. in a subroutine) is a work-around. Joe. > -----Original Message----- > From: CBFalconer [SMTP:cbfalconer@yahoo.com] > Sent: Monday, June 24, 2002 12:45 PM > To: gpc(a)gnu.de > Subject: Re: list trouble solved > > "da Silva, Joe" wrote: > > > > I don't want to enter a debate over this, since clearly not everyone has > > the same concerns/priorities. However, I regard string handling memory > > leakage to be more serious than lack of range checking - but that's just > > my opinion, FWIW. (Which is not to say that range checking isn't also > > important, of course.) > > Are there such leaks, and how do they get triggered (if you know). > > -- > Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) > Available for consulting/temporary embedded and systems. > <http://cbfalconer.home.att.net> USE worldnet address! > >

1 0

Re: list trouble solved
by da Silva, Joe 24 Jun '02

24 Jun '02

I don't want to enter a debate over this, since clearly not everyone has the same concerns/priorities. However, I regard string handling memory leakage to be more serious than lack of range checking - but that's just my opinion, FWIW. (Which is not to say that range checking isn't also important, of course.) Joe. > -----Original Message----- > From: Maurice Lombardi [SMTP:Maurice.Lombardi@ujf-grenoble.fr] > Sent: Saturday, June 22, 2002 6:48 PM > To: gpc(a)gnu.de > Subject: Re: list trouble solved > > Toby Ewing wrote: > > > Finally got it. > > > > In the end the problem wasn't in the list work at all. Way earlier in > the > > program, I'd allocated memory for an array [1..x], then accessed it as > [0..x]. > > On freeing the memory, I guess something funny was set up in the memory > > > manager that came back to bite me way later. > > > > So... is there a compiler option I could have set that would have told > me about > > this illegal memory access? > > > > _No array index checking_ in gpc up to now unfortunately > > > Franck, > > You have said some time ago that check of array addresses was not so > important ... > > You said also in an other mail that you were not fond of numeric analysis > ... > > The two are closely related because this kind of lost of days of time is > by > far the most important for anybody who does numeric analysis programs... > > Correcting this is in my opinion the most urgent thing to do after the 2.1 > release. > > > Maurice > > -- > Maurice Lombardi > Laboratoire de Spectrometrie Physique, > Universite Joseph Fourier de Grenoble, BP87 > 38402 Saint Martin d'Heres Cedex FRANCE > Tel: 33 (0)4 76 51 47 51 > Fax: 33 (0)4 76 63 54 95 > mailto:Maurice.Lombardi@ujf-grenoble.fr >

3 2

GPC libraries
by Kasper Souren 23 Jun '02

23 Jun '02

Hi, I'm working on a library for GPC, and I want to make it available to the public. But I don't know in which way. At the moment the library contains some wrappers to other libraries (libao, libsndfile, libggi and libfreetype) and some other functionality (loading/saving .ppm files (graphics)). The largest part of the wrappers is done in C, and then there is some Pascal to wrap that. If you want to take a look at the stuff, you can download http://industree.org/libguakagpc/download/PASCAL-0.20020619.tar.bz2 I don't know what would be a good place to put the files. And maybe I need to work with units, but I'm not a very experienced Pascal programmer, so I don't have experience with units. (I started doing Pascal just for this project actually.) What happens if you do a "uses GPC" or "uses GMP"? Are the files supposed to go into a directory like /usr/lib/gcc-lib/i386-linux/2.95.4/units/? Could this stuff also be incorporated into the GPC distribution? Just like GMP? One 'problem' might be that I don't provide all the functionality of the libraries in the wrappers. I'm writing it for someone who will never use all the available functionality, so right now that's a good idea. If it will become available to more people, it might be a good idea to make stuff more general. greetz, Kasper

2 2

Data structure like file system
by Preben Mikael Bohn 22 Jun '02

22 Jun '02

Hi all, this is not a GPC-specific question, but here it goes anyway... :-) I need a data structure or object in Pascal that basically can hold a file-system. Only difference between this and an ordinary filesystem is that permissions, timetags, etc, are not needed, "only" the directories and filenames as well as ~10-20 bytes storage for each file. Any idea how this could be accomplished, or pointers to already existing source? Best regards Preben Bohn ===== Computers are like airconditioners: They stop working properly if you open windows. __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

3 3

FSF directory
by Maurice Lombardi 22 Jun '02

22 Jun '02

Hi all While browsing informations on the Free software directory I have found the page http://www.gnu.org/directory/Software_development/Compilers/freePascal.html where there is complete confusion between FPC and GPC. One should ask to have two different pages for the two compilers. But who is entitled to ask for rectification and where to do that ? Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

3 2

Re: list trouble
by Toby Ewing 22 Jun '02

22 Jun '02

Hi, again CBFalconer wrote: > Simplify your basic list handling and publish the whole thing. It > is highly suspect, because you are in the habit of making copies > of pointers in a rather undisciplined manner. You are not working > with the lists you think you are. I have to admit that everything I (formally) learned about programming I learned in Fortran on punch cards. But I didn't think my pointer work was all that bad! Below is the program, stripped of everything but the list handling. Now it works perfectly, of course. But perhaps the error is still lurking? I'd appreciate any suggestions. I'm flummoxed. The basic idea is that I start with a list with a bunch of entries. I pass through the list, using information in it to generate a new list. Each record I examine, I dispose. I then pass the new list to the old one (pointer), and repeat. Eventually, there are no more entries, and the program moves on to the next realization (main loop). I thought perhaps there was a systematic memory leak, so I have two simple detection schemes. One is that I print out the starting address of the list for each realization (no trend, just random drift). The other is that each pass through the first list should generate the same number of records that is deleted on the next pass (this is the countIn, countOut, prevIn stuff - it also checks out). regards, Toby ------------------------ Program Snowbird; Const Realize = 20; initial = 6500; Type PRec = ^Rec; Rec = record rx, ry, rz : shortCard; check : PtrCard; next : PRec; end; var r : shortCard; PrevIn : medCard; {________________________________________________ } Procedure NumLatt(var PrevIn : medCard); var Root : PRec; countIn : medCard; i : shortCard; {-----------------------} Procedure LInsert(var Root : PRec; x, y, z : shortCard); var temp : PRec; begin New(temp); with temp^ do begin rx := x; ry := y; rz := z; check := PtrCard(temp); next := Root; end; Root := temp; end; {LInsert} {-----------------------} Procedure Advance(var Root : PRec; var countIn, PrevIn : medCard); var LNext, PSelf : PRec; i, countOut : medCard; begin LNext := Nil; countOut := 0; while (Root <> Nil) do begin {walk through Root list} for i := 1 to trunc(2.98*random) do begin {build LNext list} inc(countIn); LInsert(LNext, i, 2*i, 3*i); end; PSelf := Root; {destroy Root in passing} Root := Root^.next; inc(countOut); Dispose(PSelf); PSelf := Nil; end; Root := LNext; {give LNext to Root} LNext := Nil; if (countOut <> PrevIn) then begin {do numbers balance?} writeln('error: countOut = ', countOut:1, ', PrevIn = ', PrevIn:1); readln; end; PrevIn := countIn; end; {Advance} {-----------------------} begin {NumLatt} Root := Nil; LInsert(Root, 1, 2, 3); writeln('Root starts at ', Root^.check:1); for i := 2 to Initial do LInsert(Root, i, 2*i, 3*i); repeat countIn := 0; Advance(Root, countIn, PrevIn); until (countIn = 0); end; {________________________________________________ } begin {Main Program} writeln; writeln('List checking'); writeln; Randomize; for r := 1 to Realize do begin write('Realization ', r:2, ': '); PrevIn := Initial; NumLatt(PrevIn); end; end.

1 0

Re: list trouble
by da Silva, Joe 21 Jun '02

21 Jun '02

Speaking of optimization, are you using any "heavy" optimization settings that may be giving side-effects? Joe. > -----Original Message----- > From: CBFalconer [SMTP:cbfalconer@yahoo.com] > Sent: Friday, June 21, 2002 5:59 AM > To: gpc(a)gnu.de > Subject: Re: list trouble > > Toby Ewing wrote: > > CBFalconer wrote: > > > Toby Ewing wrote: > > > > > > > > I'm having trouble with list management again. > > ... snip ... > > > > It's probably an obvious problem, and I'm hoping fresh eyes can see > it. > > > > > > All I have done below is reformat, so I could follow it, and > > > separate out the mundane operations into a local procedure, so > > > that the actual list manipulation stands alone, and also because I > > > have no idea what that piece of code is doing. Many variables > > > should be moved into the local, and the item to manipulate should > > > be passed into it, but that is another matter. > > > > It's a trade-off between clarity and speed. The loop will execute > > several billions of times, and the run time is several days. I try not > > to call functions or procedures from inner loops. But as you say, > > that's a whole other discussion. > > You are doing enough in that routine that there should be no > perceptible difference in speed. The first rule of optimization > is don't. The second is profile first. > > > > > >Now go to the end > > > > > > > Procedure Advance(VAR Root : PRec; {rx, ry, rz: medcard; next: > PRec} > > > > VAR Latt : PPLary; (3D lattice in schema format} > > > > VAR here, > > > > count : medCard); > > > > {Local to NumLatt. > > > > 1. Identify adjacent, accessible sites. > > > > 2. if sites are unoccupied, insert them into LNext. > > > > 3. Delete Self from Root. > > > > 4. Set Root = Lnext.} > > > > > > > > VAR > > > > LNext, > > > > PSelf : PRec; > > > > lx, ly, lz, {neighboring locations} > > > > dir : medCard; {directions} > > > > Conduct : boolean; {=accessible site} > > > > > > > > (* 2--------------------2 *) > > > > > > > > PROCEDURE operate; > > > > > > > > BEGIN (* operate *) > ... snip ... > > > > END; (* operate *) > > > > > > > > (* 2--------------------2 *) > > > > > > > > BEGIN (* advance *) > > > > LNext := Nil; > > > > WHILE (Root <> Nil) DO BEGIN > > > > PSelf := Root; > > > > operate; > > > > Root := Root^.next; {advance through > list} > > > > write('a'); > > > > dispose(PSelf); { <<=== program crashes here } > > > > write('b. '); > > > > END; (* while *) > > > > Root := LNext; > > > > END; {Advance} > > > > > > The above makes it pretty obvious that the problem is NOT in the > > > operate action, but in the list itself. The fact that dispose > > > crashes shows that PSelf is not a valid pointer to a record, which > > > includes *the fact that the record was created with new* > > > > I agree that the problem is that PSelf is apparently not a valid > > pointer. I don't understand what you're saying about New. Is New not > > stable or trustworthy? > > Perfectly stable and trustworthy. > > > > > > I think you should look into the areas where the list is created. > > > You may have a global instance of an element, for example, that > > > you are incorporating into the list somehow. > > > > The list is created by > > 1) declaring the variable Root : PRec (outside procedure Advance), and > > 2) using the procedure LInsert to add elements to the list. > > LInsert is: > > > > Procedure LInsert(var Root : PRec; > > var x, y, z : medCard); > > var temp : PRec; > > begin > > new(temp); > > with temp^ do begin > > rx := x; > > ry := y; > > rz := z; > > next := Root; > > end; > > Root := temp; > > end; > > > > The only list manipulation is the LInsert procedure, and the dispose > > line that sometimes crashes the program. All records in the list come > > from LInsert. What I find disturbing is that this is a very simple > > piece of list work. The program sometimes runs through over 2,000,000 > > records without crashing - and sometimes crashes after about 100 > > records. Frustrating. > > > > CBFalconer continues: > > > GPC new/dispose is dependant on the C malloc, I believe. If you > > > are using DJGPP you can probably use my nmalloc, available on my > > > site, which provides some hooks for examining the allocation > > > chains and also detects most illegal frees. If it is linked ahead > > > of the runtime library it will replace the library malloc stuff. > > > But that should be only a last resort. > > > > Yes, I'm using DJGPP and will check out your nmalloc. I'm also > > installing GPC on a Linux box so I can try te program there. Because > > this is memory weirdness, I'm wondering if at heart it's a windows > > problem. > > I assume you have a declaration somewhere like: > > TYPE > prec = ^rec; > rec = RECORD > ... > next : prec; > END; > > and I was envisioning you had done something like declare > > VAR > root : rec; > ... > > but you say not. Have you ever initialized root to be NIL? > > VAR > root : prec; > > .... > root := NIL; (* <---- absolutely crucial *) > WHILE whatever DO linsert(root, ...); > .... > > If you don't have ECC memory it is conceivable you have hardware > problems. Another possibility is some bad indexing fouling the > chains (gpc doesn't have range checking :-[) where the nmalloc > stuff might come in handy. > > You could build a list validator, which only walks the list from > root to final NIL. To use it add a field set to a constant value, > and the validator checks that value is there for each entry. > Should be quite fast, and you can then call it here and there in > the program. This would give an early indication of fouled > storage. > > CONST > VALIDMARK = 1234; > > TYPE > rec = RECORD > validation : integer; > .... > END; > > PROCEDURE linsert(....) > .... > new(temp); > temp.validation := VALIDMARK; > ... > > PROCEDURE listvalidate(calledfrom : integer); > > LABEL 10; > > VAR temp : prec; > > BEGIN (* listvalidate *) > temp := root; > WHILE temp <> NIL DO > IF temp.validation <> VALIDMARK THEN BEGIN > takesomeaction(calledfrom); > goto 10; END; > 10: END; (* listvalidate *) > > (you may notice I don't believe in using things outside of ISO7185 > without very good reasons, none of which I see here <g>) > > If all else fails see line 2 of the sig. > > -- > Chuck F (cbfalconer@yahX-Mozilla-Status: 0009rldnet.att.net) > Available for consulting/temporary embedded and systems. > <http://cbfalconer.home.att.net> USE worldnet address!

3 2

Re: list trouble
by Toby Ewing 20 Jun '02

20 Jun '02

Hi again CBFalconer sent me a list validating procedure, which I stuck into the program. I actually made two versions, one to check the immediate record, and one to check the entire list. I ran it in many ways, but the results are always the same. The checker says everything is fine, and then the program still crashes as before. Checking the record pointed at by PSelf, immediately before disposing it, finds nothing. I modified the checker procedure so it would write a new value (0) to the validation mark, then write the validmark again. Same result. Now here's the twister. I tried running the program on a linux machine - same code, same version of gpc. It crashed in a different place, but also on a dispose statement. In that case, it was disposing a schema (array). Any suggestions? I'm starting to get worried that this code will never work! regards, Toby

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc