mem@zinn.MV.COM (Mark E. Mallett) (01/16/89)
In article <146@roberta.UUCP> michael@roberta.UUCP (Michael A. Moran ) writes: >In article <1989Jan9.134250.27793@ateng.ateng.com>, chip@ateng.ateng.com (Chip Salzenberg) writes: >> >> >I think it hits the top of memory (my system has 2048K, with 1402K as >> >the maximum user process size) and tries to swap. Maybe it is a system bug. >> >> Well, I have 3.5M. Perhaps that's it. > >And you are very close to the limit where pathalias will fail. Running Xenix >on a '286 with 3 Megs I can build a pathalias file with about 9800 sites. >With 2.5 Megs I can build a pathalias file with about 7500 sites. My problem with pathalias is not in how much memory I have (by the way, 3.5 megabytes for 11,000 nodes works out to over 300 bytes per node: I hope that pathalias doesn't have that kind of overhead). Recent breakdowns in my pathalias processing caused me to look at the source. It (pathalias) allocates symbol tables as big monolithic arrays of pointers to elements. When a table gets full, a bigger one is allocated and the smaller table is copied into it. The problem is that my Microport System V/AT system doesn't support allocation of bigger than 64K blocks, yet the situation has reached the point where pathalias has tried to expand to an array that takes 84K. Pushed into the 16 bit int for call to malloc, very bad things happen. My though has been to try to rewrite the symbol management to accomodate this restriction. If anyone has already done it, please drop me a note. I'm cross-posting this over to microport, where it probably has more relevance (in my situation). Thanks, -mm- -- Mark E. Mallett Zinn Computer Co/ PO Box 4188/ Manchester NH/ 03103 Bus. Phone: 603 645 5069 Home: 603 424 8129 BIX: mmallett uucp: mem@zinn.MV.COM ( ...{decvax|elrond|harvard}!zinn!mem ) Northern MA and Southern NH consultants: Ask me about MV.COM