Bob Bailin wrote:
> "Roger Cornelius" <rac@tenzing.org> wrote in message
> news:1126184650.675059.174090@g49g2000cwa.googlegr oups.com...
> > Bob Bailin wrote:
> >> "Roger Cornelius" <rac@tenzing.org> wrote in message
> >> news:1126140401.425597.163360@g47g2000cwa.googlegr oups.com...
> >> > OSR6 with MP1
> >> >
> >> > Up until OSR6, I was still using the Xenix 386 sort, which runs
> >> > approximately 3 x faster than the Openserver sort. It doesn't run at
> >> > all on OSR6 though, and immediately fails with:
> >> >
> >> > sort: allocation error before sort
> >> >
> >> > I've tried running it under truss, but I don't see anything obviously
> >> > wrong. Would someone more knowledgable care to look at the truss
> >> > output and give their opinion? It can be seen here:
> >> >
> >> > http://tenzing.org/xenix-sort
> >> >
> >>
> >> There are still problems with xemul on OSR 6.0.0 w/MP1.
> >> Perhaps you've stumbled upon one of them. Could you post
> >> the sort.x386 binary on your webpage, along with the data file
> >> you're trying to sort and the exact command line you're
> >> using to invoke it? I would be happy to try it out using
> >> a newer version of xemul. (Or does the error occur
> >> simply by entering "sort.x386" at the command line with
> >> no arguments?)
> >
> > The error occurs whether or not I supply arguments to sort. To produce
> > the truss.out file, I called it with no arguments.
> >
> >> Please note that you can create a simple trace directly
> >> from xemul (instead of using truss), and there's also
> >> an option to more closely emulate OSR5 behavior.
> >> See man xemul.
> >
> > Setting XEMUL_OSR5 has no effect but I'm unable to convince xemul to
> > produce a trace file as described in the man page either. Does
> > XEMUL_TRACE require a particular value? The man page is unclear.
> >
>
> Use:
>
> XEMUL_TRACE=1 (simply setting it any value, e.g. 'TRUE', doesn't work)
> export XEMUL_TRACE

Kind of an important detail to leave out of the man page.

> The trace file will appear in the current directory, not /tmp as implied by
> the man page.
>
> xemul trace output (xtrace.21736):
> close(3) err #9 (EBADF)
> close(4) = 0
> close(5) err #9 (EBADF)
> [close(6) ... close(17)]
> close(18) err #9 (EBADF)
> ulimit(3, 0) err #22 (EINVAL)
> brk(0xfffffffc) err #22 (EINVAL)
> write(2, 0x188067c, 6) = 6
> write(2, 0x188008c, 28) = 28
> write(2, 0x188008a, 0) err #14 (EFAULT) [= 0 if XEMUL_OSR5=1 is
> set]
> write(2, 0x1880684, 1) = 1
> close(0) = 0
> close(1) = 0
> close(2) = 0
> exit(1)
>
> Not very useful. The error is being trapped and handled by
> the binary itself.
>
> Is the -y option for memory allocation the same in both Xenix & OSR?

The manual pages describe -y similarly for both but I have no idea how
they operate internally.