` Segment errors - cause and ways to help (Robert Zaunere) - Icetips Article
Icetips - Templates, Tools & Utilities for Clarion Developers

Templates, Tools and Utilities
for Clarion Developers

Icetips Article

Back to article list   Search Articles     Add Comment     Printer friendly     Direct link  

Clarion Environment (IDE etc.): Segment errors - cause and ways to help
2004-01-21 -- Robert Zaunere
 
Newsgroups: softvelocity.public.clarion6 There are many theories floating about with regard to this "limit", unfortunately none of them are accurate. There is a Zero correlation to any 16bit issue in C6 with this topic of SEGDEFs, as 16bit is not even supported for compilations, and the segment limit has not changed from C5x. As explanation as to what does happen, the linker must collect information about object and resource files to be linked into the target. The limit for number of segments per object file is ~16k. The compiler produces segments for things like: - Every Procedure or ROUTINE is a separate segment; - Every static variable or constant string is a separate segment; - Every FILE structure produces 5 segments, plus if the FILE declaration has NAME, OWNER or driver string, one segment per every for one of these strings, plus one possible segment if FILE is threaded, every KEY, every Memo, every VIEW, every QUEUE, etc. etc. So in general, the current linker limit means that a single source file can have _thousands of declared (and used in the program) variables. The most probable ways to get the "too many SEGDEF..." error are: 1- to include too many INCLUDEs that declare variables; solution is to include files on the module level rather than globally everywhere where it is possible 2- to declare too many FILEs with large number of KEYs and/or MEMOs in one source file (the main source file, as a rule); #1 is your control. As for #2 its also in your control, but we'll be providing template support in C6.1 that will allow you to easily split the file structs generated from extremely large DCTs (those with with many hundreds of files defined in them) into > 1 source modules. That means that when such DCTs produce an excess of the ~16000 segment limit you can get past it. However, there are other alternatives you can take right now, like reducing the # of files declared in a single DCT to something more in line with what Files are really being used in the APP, or to declare files on the member module level if this is possible (i.e. the FILE is only used in particular procedure ). But the template solution will be forthcoming. Regards, Robert Zaunere SoftVelocity Inc. On Wed, Jan 21 2004 12:02 pm, Robert Wagner said: >Trevor: > >Sounds like your saying that the problem is the number of files >actually used in an app. Could you give me a feeling as to where >(number of files) you've hit this problem? > >I've got a dictionary with about 600 files, used by about 100 apps. >The nature of the beast is that any one app probably doesn't use more >than 100 files (but I haven't checked). Just want to know if I should >be getting nervous. Or maybe I should say, more nervous than I >already am. > >The obvious solution is a 32 bit IDE, and multiple dictionarys per >app. But I guess that isn't obvious to everyone. > > >On 21 Jan 2004 05:27:44 -0500, trevor cocks > wrote: > >>Robert >> >>I don't know the limit. But I have hit it several times. >> >>I don't think it a a DCT/Dictionary Editor size limit per-say, it is a >>compiler limit. The DCT Editor will let you create a DCT of virtually any >>size/complexity. When the app compiles it creates all the file-defs in CLW >>files.. the compiler cannot handle more than a certain number of "symbols". >>You will see the error: >> >>"Invalid handle... too many SEGDEF,4000" - or something similar. >> >>If you have alot of Aliases you might get this because they are treated as >>"proper" files. The only cure I have found is to start rationalising the DCT >>and getting rid of Aliases hat I don't really need. >> >>My gut feeling is it is a 16bit thing. >> >>The window/Report formatters do have a finite limit on field equate labels >>at design time. If you hit this it is when you spend 1 hour design your >>window, then Save & Exit the formatter and C5.5 will crash with a >>"memory/heap overflow" error. You have then lost all your window changes, >>forever. > >

Today is April 24, 2024, 7:55 am
This article has been viewed 35119 times.
Google search has resulted in 203 hits on this article since January 25, 2004.


Back to article list   Search Articles   Add Comment   Printer friendly

Login

User Name:

Password:


Gold Subscription
Buy Now
Silver Subscription
Buy Now
Solo Subscription
Buy Now
Multiple Copy Pricing
Renew Subscription