chip@killer.UUCP (Chip Rosenthal) (12/15/87)
Has anybody out there brought up pathalias under SCO XENIX? I get a
segmentation violation if I try to run enough map data through it. Moving
up in compiler models (M->L->H) and disabiling Peter's malloc stuff forstalls
the dump, but it still occurs. The dump occurs in hash() when it makes its
probe into the hash table:
.
.
>>> while ((n = Table[probe]) != 0) {
if (unique)
goto skip;
.
.
The "probe" value looks reasonable and is within the value of "Tabsize".
I haven't looked any further than this. If anybody has found what it
takes to get this up, I'd really like to see what you did. Thanks.
--
Chip Rosenthal chip@vector.UUCP | But if you want to sing the
Dallas Semiconductor (214) 450-0400 | blues, then boy you better
{texsun,codas,ihnp4}!killer!vector!chip | learn how to lose.honey@umix.cc.umich.edu (Peter Honeyman) (12/16/87)
the maps are up to about 15,000 hosts and 40,000 links. it costs 16 bytes per link, 40 bytes per host. (as i recall ... citi is down, so i don't have def.h in front of me.) multiplying out, that's a megabyte or so. can sco xenix handle > 1M address space? i'm surprised mymalloc() failed before malloc(). i'd have thought that was impossible. peter
jpp@slxsys.specialix.co.uk (John Pettitt) (12/19/87)
In article <2472@killer.UUCP> chip@killer.UUCP (Chip Rosenthal) writes: >Has anybody out there brought up pathalias under SCO XENIX? I get a >segmentation violation if I try to run enough map data through it. Moving > . >>>> while ((n = Table[probe]) != 0) { > if (unique) > goto skip; > . >Chip Rosenthal chip@vector.UUCP | But if you want to sing the >Dallas Semiconductor (214) 450-0400 | blues, then boy you better >{texsun,codas,ihnp4}!killer!vector!chip | learn how to lose. I decided to post rather than mail as this is probably of interest to Xenix users in general. The problem is that ptr != int. Table is declared extrn node **Table; Comparing this to 0 will not work in 286 Large model. If the 0 is changed to NULL - declared in stdio.h as ((char *) 0) and disable the malloc stuff. It will work. You will also need -Ml and -F 4000 otherwise you will run out of stack. -- John Pettitt UUCP :{backbone}!mcvax!ukc!pyrltd!slxsys!jpp Specialix Systems Domain :jpp%slxsys@pyra.co.uk London, UK. (Where else ? :-) Voice : +44 1 398 9422 (GMT) rn: core dumped
jack@turnkey.TCC.COM (Turnkey Software Developer) (12/20/87)
In article <2472@killer.UUCP> chip@killer.UUCP (Chip Rosenthal) writes: >Has anybody out there brought up pathalias under SCO XENIX? I get a >segmentation violation if I try to run enough map data through it. Moving >up in compiler models (M->L->H) and disabiling Peter's malloc stuff forstalls >the dump, but it still occurs. The dump occurs in hash() when it makes its >probe into the hash table: The problem arises from the hash table exceeding a segment size. For anyone interested an altered version of the new pathalias is available for uucp on the system turnkey. This code was made available by Greg Laskin of gryphon. CTS.COM and it works wonderfully. It took the whole world maps without any complaint. Many thanks to Greg for his efforts!! For those interested in obtaining the archive, call turnkey at (714)662-7450 and login as 'nuucp'. The default baud rate is 2400, if you call at 1200 it will be necessary to send a return to cause the uugetty to cycle down to 1200. The archive path is "/usr/spool/uucppublic/palias.tar.Z". The archive includes both the source code and a compiled binary (under SCO Xenix 2.2.1) of pathalias for those that don't want the hassle of compiling it. All the best, -- Jack F. Vogel Turnkey Computer Consultants, Costa Mesa, CA UUCP: ...!uunet!turnkey!jack Internet: jack@turnkey.TCC.COM
jack@turnkey.TCC.COM (Turnkey Software Developer) (12/20/87)
In article <3146@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes: >the maps are up to about 15,000 hosts and 40,000 links. it costs 16 >bytes per link, 40 bytes per host. (as i recall ... citi is down, so >i don't have def.h in front of me.) multiplying out, that's a megabyte >or so. can sco xenix handle > 1M address space? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Really, you can't be serious about that question?!? But assuming you are Xenix 286 addresses 16M (the address space of the 80286), and Xenix386 handles 4 Gigabyes in unsegmented mode. As I indicated in a previous posting the problem with pathalias arises because of the segmentation on the 286 machine. Greg Laskin (greg@gryphon.CTS.COM) has ported the pathalias code to Xenix 286 and it handles the complete world maps flawlessly. For anyone that missed that article the altered archive can be obtained uucp from the system turnkey at (714) 662-7450. Login is nuucp, if you call at 1200 send an initial character or return to cyle uugetty down to 1200 baud. Request the file "/usr/spool/uucppublic/palias.tar.Z". It includes both a compiled binary and the source code. Best of luck, Jack -- Jack F. Vogel Turnkey Computer Consultants, Costa Mesa, CA UUCP: ...!uunet!turnkey!jack Internet: jack@turnkey.TCC.COM
honey@umix.cc.umich.edu (Peter Honeyman) (12/27/87)
In article <116@slxsys.specialix.co.uk> jpp@slxsys.UUCP (John Pettitt) writes: >The problem is that ptr != int. Table is declared > >extrn node **Table; > >Comparing this to 0 will not work in 286 Large model. > >If the 0 is changed to NULL - declared in stdio.h as ((char *) 0) >and disable the malloc stuff. It will work. according to the c reference manual, section 7.7, paragraph 2, your compiler is broken. peter
chip@ateng.UUCP (Chip Salzenberg) (12/27/87)
In article <2472@killer.UUCP> chip@killer.UUCP (Chip Rosenthal) writes: >Has anybody out there brought up pathalias under SCO XENIX? I get a >segmentation violation if I try to run enough map data through it. Moving > . > while ((n = Table[probe]) != 0) { > if (unique) > goto skip; > . In article <116@slxsys.specialix.co.uk> jpp@slxsys.UUCP (John Pettitt) writes: >The problem is that ptr != int. Table is declared >extrn node **Table; >Comparing this to 0 will not work in 286 Large model. This is not true; any pointer may be compared to 0 without problem. In fact, the only correct declaration of NULL is 0. (See K&R) On the other hand, passing 0 as a function parameter in the place of a pointer is not portable, and will not work in large model. All NULL function arguments should be casted (if you want a portable program :-)). For example: "setbuf(stdout, NULL);" is not portable. On the other hand, "setbuf(stdout, (char *)NULL);" is portable. (If you doubt this, consider medium model, where function pointers and data pointers have different sizes. No one value for NULL will work when used as the second parameter of both setbuf() and signal().) Microsoft, among others, has sullied K&R's simple definition of NULL in an attempt to make incorrect programs work. Oh well. -- Chip Salzenberg "chip@ateng.UUCP" or "{codas,uunet}!ateng!chip" A T Engineering My employer's opinions are not mine, but these are. "Gentlemen, your work today has been outstanding, and I intend to recommend you all for promotion -- in whatever fleet we end up serving." - JTK