From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Date: Fri, 18 Jun 2004 09:06:16 +0000 From: Bengt Kleberg Message-ID: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit References: , <200406172135.i5HLZQQ18405@zamenhof.cs.utwente.nl> Subject: Re: [9fans] any success with current plan9port on sunos5.8? Topicbox-Message-UUID: a5b73a7e-eacd-11e9-9e20-41e7f4b1d025 Axel Belinfante wrote: >>Give up on _EXTENSIONS_ whatever that means. >>Yield is a function provided by a system library. >>The right fix is to rename the one the Plan 9 libraries >>are calling. #defining random things to make yield >>disappear from view only makes the compiler think >>there is no problem; it does not fix the problem. > > > right. well put. thanks! > done that, and seems things are ok again. > that means, there are still a few things that fail, > but they failed with a previous ports version in > the same way. > I'm sorry, but I simply do not see why or how they > are failing, (maybe that's just because I don't know > much about multi-threading?) so I'm posting this > followup also to ask if someone has an explanation? > Any insight would be appreciated. > > Axel. > > Details: > > > the sort command called by ps sometimes gives me > 'sort: note: sys: child' followed by Abort > where does a SIGCHILD come from in this case? > (I mean, I don't see a fork; is this from some > thread related 'magic'?) > > > when I do 'ls -lrt' I often get a bus error. > it seems to be caused by an array bound read error > in qsort (that's what purify and dbx tell me) > but I miss to see how it is caused. > > > In case it helps someone to understand (or explain) > I'm including some purify output for the ls failure. > Note: to avoid a name clash I slightly changed ls.c > so line numbers will be off. i have not experienced any name clash. i have not changed ''dirbuf''. i do not get any bus error from ''ls''. an hypotetical reason for the bus error as described by you would be that the real size of dirbuf is smaller than the ''book keeping size'' (ndir). despite the attempt to make this possible (dirbuf gets it size changes independent of the changes to ndir), there is no place in the code where ndir can be bigger than the real size. as far as i can see. bengt