On Tue Mar 29 16:07:39 EDT 2011, fors...@terzarima.net wrote:
> >also, since this is the kernel, you either get a 4k or a 4k - sizeof(Mach)
> >structure (depending on if up is set or not), so the maximum sprint
> >to something on the stack is always going to be < 4k.
>
> that's fine, but the spri
On Tue, Mar 29, 2011 at 1:25 PM, Charles Forsyth wrote:
>one question is: why does the 9vx environment
> make the original version of sprint fail?
I'm glad you asked that question :-)
I ran out of time to track it down. It's got something to do with how
the address space is set up in 32-bit 9vx
>I'm still not sure a length limit on the string of 1 Gbyte makes
>sense, and I have no idea if 64K is too low, but the 64k-limit patch
>does make it all work. I'm going to try to apply it tomorrow and see
>what shakes.
at some point, a value
ep = bp + lim
will be formed. if bp+lim is too
>also, since this is the kernel, you either get a 4k or a 4k - sizeof(Mach)
>structure (depending on if up is set or not), so the maximum sprint
>to something on the stack is always going to be < 4k.
that's fine, but the sprint is the one from the c library
which needs to support more than that. t
On Tue, Mar 29, 2011 at 12:05 PM, erik quanstrom
wrote:
> On Tue Mar 29 12:48:21 EDT 2011, fors...@terzarima.net wrote:
>> in fact, even 64k might be too big a value for the given buf if it's near the
>> top of memory (eg, a local variable on a stack that's in high memory);
>> the PowerPC referenc
On Tue Mar 29 12:48:21 EDT 2011, fors...@terzarima.net wrote:
> in fact, even 64k might be too big a value for the given buf if it's near the
> top of memory (eg, a local variable on a stack that's in high memory);
> the PowerPC reference in the original comment is misleading because that
> was jus
My bet here is that if you build yiyus or ron tree and force 32-bit,
it will fail on a 64-bit system, no idea why. if you build with 64-bit
on yiyus tree, it will work.
In other words, I think the issue crops up on 32-bit 9vx on 64-bit
environments. At least that is how it seems to work.
I'm stil
2011/3/29 ron minnich :
> On Tue, Mar 29, 2011 at 8:42 AM, Mathieu Lonjaret
> wrote:
>> Well, since Ron's tree is based on Yiyus', and Ron's doesn't have that
>> patch, I think that means Yiyus' doesn't have it either. And yet,
>> Yiyus' works for me, so I doubt this bug was the culprit for me. Mo
in fact, even 64k might be too big a value for the given buf if it's near the
top of memory (eg, a local variable on a stack that's in high memory);
the PowerPC reference in the original comment is misleading because that
was just a particular system where the general problem appeared.
>+ n = vsnprint(buf, 65536, fmt, args);
...
>Note the len = 1 << 30; why was that ever done? I never figured that out
there is nothing to limit the length of a string to 64k bytes
On Tue, Mar 29, 2011 at 6:09 PM, ron minnich wrote:
> On Tue, Mar 29, 2011 at 8:42 AM, Mathieu Lonjaret
> wrote:
>> Well, since Ron's tree is based on Yiyus', and Ron's doesn't have that
>> patch, I think that means Yiyus' doesn't have it either. And yet,
>> Yiyus' works for me, so I doubt this b
On Tue, Mar 29, 2011 at 8:42 AM, Mathieu Lonjaret
wrote:
> Well, since Ron's tree is based on Yiyus', and Ron's doesn't have that
> patch, I think that means Yiyus' doesn't have it either. And yet,
> Yiyus' works for me, so I doubt this bug was the culprit for me. More
> like a 64 bits issue as Yi
Well, since Ron's tree is based on Yiyus', and Ron's doesn't have that
patch, I think that means Yiyus' doesn't have it either. And yet,
Yiyus' works for me, so I doubt this bug was the culprit for me. More
like a 64 bits issue as Yiyus mentionned earlier, no?
On Tue, Mar 29, 2011 at 5:06 PM, Chri
This one is extremely weird.
On Tue, Mar 29, 2011 at 2:00 AM, Mathieu Lonjaret
wrote:
> Hi all,
>
> this is probably trivial; this is what I get when trying to start 9vx:
>
> Warning! factotum can't protect itself from debugging: '#p/5' file does not
> exist
> init: warning: can't open #p/2/ctl:
Hello,
Mathieu Lonjaret wrote:
this last error keeps on repeating.
as a plan 9 tree I'm using the same old one that I kept using with rsc's
9vx (minimal tree provided by rsc, and later filled with more plan 9
stuff), could that be the issue? if yes, what do you guys for a tree
with ron's 9vx?
Good call; yours starts without a problem, thanks.
On Tue, Mar 29, 2011 at 11:47 AM, yy wrote:
> ron's 9vx and mine are compiled differently in 64bits systems, so you
> can try mine and see if there is any difference, but I don't really
> know. I don't have any x86_64 system I can use to test 9vx
ron's 9vx and mine are compiled differently in 64bits systems, so you
can try mine and see if there is any difference, but I don't really
know. I don't have any x86_64 system I can use to test 9vx, so please
let me know if things get better (or worse). If you don't want to
download the whole vx32 t
I don't know enough about the causes to be of much help. Ron, Yiyus or
Russ might know.
Noah
On Tue, Mar 29, 2011 at 11:25 AM, Mathieu Lonjaret
wrote:
> Nothing remote or fancy here, just starting 9vx locally (-u glenda -r
> plan9vx) after having built it.
> However, it is a 64 bits linux and
Nothing remote or fancy here, just starting 9vx locally (-u glenda -r
plan9vx) after having built it.
However, it is a 64 bits linux and I haven't done anything special or
set any flag when building (cd src; make; make install). Should I?
On Tue, Mar 29, 2011 at 11:18 AM, Noah Evans wrote:
> I've
I've seen this behavior before, once using 9vx on a remote xsession
and once when using strace on a (broken) 9vx that was compiled for
32bit on a 64bit linux. Are there any mitigating factors that could be
causing your problem?
Noah
On Tue, Mar 29, 2011 at 11:00 AM, Mathieu Lonjaret
wrote:
> H
Hi all,
this is probably trivial; this is what I get when trying to start 9vx:
Warning! factotum can't protect itself from debugging: '#p/5' file does not
exist
init: warning: can't open #p/2/ctl: '#p/2' file does not exist
init: starting /bin/rc
FAILED
Warning! auth/factotum can't protect its
21 matches
Mail list logo
