Hi all,
A while ago, while working on btfs, I stumbled upon some sort of
overflow (http://9fans.net/archive/2009/07/77) which was in fact due
to the thread STACK being too small (and hence if I understood
correctly things would get written out of it, in the heap).
To be on the safe side, I have it
> A while ago, while working on btfs, I stumbled upon some sort of
> overflow (http://9fans.net/archive/2009/07/77) which was in fact due
> to the thread STACK being too small (and hence if I understood
> correctly things would get written out of it, in the heap).
> To be on the safe side, I have i
also if you're using bio(8) notice that a biobuf is >8kb
On Wed, May 19, 2010 at 6:20 AM, Sape Mullender
wrote:
>> A while ago, while working on btfs, I stumbled upon some sort of
>> overflow (http://9fans.net/archive/2009/07/77) which was in fact due
>> to the thread STACK being too small (and h
I've found it useful to use the testing of the program to also
force it to get into what I think is a worst case and then printing the
stack size (doing this is simple by printing argument addresses).
hth
On Wed, May 19, 2010 at 11:55 AM, Federico G. Benavento
wrote:
> also if you're using bio(8
On 19 May 2010, at 05:37, David Leimbach wrote:
On Tue, May 18, 2010 at 7:13 PM, ron minnich
wrote:
On Wed, May 19, 2010 at 1:54 AM, David Leimbach
wrote:
> Were all of the binaries within recompiled against this code?
Running 9vx
> on my iMac is pretty smooth!
Hm, not sure what
> As a general rule in threaded programs, avoid declaring local arrays
> or large structs. Instead, malloc them and free them when you're done.
> A file server, as an example, should never allocate an 8K message
> buffer on the stack. If you can manage to obey the rule of not having
> arrays on t
> [3] The execution that fails is actually a crucial
> part of the `make install' process. I've attached
> the whole output of the build and install
> processes.
The problem is in /sys/src/ape/lib/ap/stdio/vfscanf.c -- semantics of
"%n" is incorrect if an item is terminated by EOF (i.e. end of str
On Tue, May 18, 2010 at 10:40 PM, Bakul Shah wrote:
> term% 8.out -c /bin/echo Boo!
> 511 echo Brk 0x3233 b450 = 0 "" 0x11af077310cde470
> 0x11af077310d0da40
> 511 echo Pwrite 0x31d6 1 a458/"Boo!." 5 -0x1Boo!
> = 5 "" 0x11af07731e11e758 0x11af077326aed448
> 511 echo Op
On Tue, May 18, 2010 at 10:45 PM, erik quanstrom wrote:
> ron, please enlighten the ignorant. could you constrast this with
> truss? or maybe there's a man page?
I need to write one.
The biggest diff from truss is that the program itself is dead simple,
since most of the work is done by the k
hi,
The wheel on my Logitech USB mouse does not work. Injection of a few
debug prints in /sys/src/cmd/usb/kb/kb.c:/^ptrwork revealed that wheel
events are not available on ptrfd at all.
what may be wrong here?
thanks.
On Wed, 19 May 2010 08:09:50 PDT ron minnich wrote:
>
> The format arose out of discussions with nemo and others.
>
> It is a straight text layout of system call params and return. The =
> separates the params and return. The format is:
> pid textname syscall-name pc [params] = retval errstr
>
On Wed, May 19, 2010 at 10:18 AM, Bakul Shah wrote:
> 0. Name syscalltrace is too long :-)
pick a name and I'll change it.
> 1. Curiously, an actual errstr is not enclosed in "..".
that goes on the bug list. If you want, use the bugtracker at
bitbucket.org, on my rminnich/vx32 project, and add
> > if (cmd[0] != '/') {
> > char* pcmd = malloc(strlen(cmd) + 5);
> > sprintf(pcmd, "/bin/%s", cmd);
> > exec(pcmd, args);
> > }
shouldn't that be
I'll only take that patch if it does NOT include stdio.h.
As for output ... I'm conflicted on output on 1 vs. 2. But it is nice
that you can see normal output of the traced process. But, hmm, if
traced process prints on 2, well ... you'll lose it.
So, my feeling is, if you are *really* concerned
On Wed, May 19, 2010 at 10:51 AM, erik quanstrom
wrote:
>> > if (cmd[0] != '/') {
>> > char* pcmd = malloc(strlen(cmd) + 5);
>> > sprintf(pcmd, "/bin/%s", cmd);
>> > exec(pcmd, args);
>> >
On Wed, 19 May 2010 10:41:26 PDT ron minnich wrote:
> On Wed, May 19, 2010 at 10:18 AM, Bakul Shah wrote
>
> > 0. Name syscalltrace is too long :-)
>
> pick a name and I'll change it.
I used strace but don't really care what you call it as long
as it is short! How about ratrace (Ron's ascii
> Ok! I don't feel strongly either way. But I hope you do
> consider counted bytestrings to represent random memory.
> It is cheap to parse and produce and doesn't lose info.
no keep it text. plan 9 wins this way. "bytestrings"
(it seems to me that byte strings are neither) would require
knowle
On Wed, May 19, 2010 at 11:23 AM, Bakul Shah wrote:
> Ok! I don't feel strongly either way. But I hope you do
> consider counted bytestrings to represent random memory.
> It is cheap to parse and produce and doesn't lose info.
bear in mind that 99.999% of the time (well, that's an
exaggerat
On Wed, 19 May 2010 10:53:59 PDT ron minnich wrote:
> I'll only take that patch if it does NOT include stdio.h.
Well, you have the trivial diff so do what you want.
> As for output ... I'm conflicted on output on 1 vs. 2. But it is nice
> that you can see normal output of the traced process. Bu
On Wed, May 19, 2010 at 2:23 PM, Bakul Shah wrote:
> On Wed, 19 May 2010 10:41:26 PDT ron minnich wrote:
>> On Wed, May 19, 2010 at 10:18 AM, Bakul Shah
>> wrote
>>
>> > 0. Name syscalltrace is too long :-)
>>
>> pick a name and I'll change it.
>
> I used strace but don't really care what you
On Wed, May 19, 2010 at 11:43 AM, Bakul Shah wrote:
> BTW, truss does the same thing (output to stderr). ktrace on
> FreeBSD finesses by just dumping trace output to a file and
> then kdump is used to show it.
>
strace on linux sends to stderr as well.
OK, you win, I'll change that one. It bot
> strace on linux sends to stderr as well.
>
> OK, you win, I'll change that one. It bothers me to lose error output however.
if you really need bug-for-bug compatability,
you can always ratrace >[1=2] | ...
- erik
On Wed, 19 May 2010 11:33:24 PDT ron minnich wrote:
> On Wed, May 19, 2010 at 11:23 AM, Bakul Shah
> wrote:
>
> > Ok! I don't feel strongly either way. =A0But I hope you do
> > consider counted bytestrings to represent random memory.
> > It is cheap to parse and produce and doesn't lose info.
On Wed, May 19, 2010 at 1:30 PM, Bakul Shah wrote:
> You write "startsyscall" to /syscall for every trace
> buffer read -- don't quite understand why that is needed.
It gives you the option of not restarting the system call until later.
There could be more complex usage scenarios.
But it's a v
On Wed, May 19, 2010 at 9:36 AM, Arvindh Rajesh Tamilmani
wrote:
> acme-sac on windows is my development environment too.
>
> b2 on 'win os cmd' gives a cmd.exe window. i prefer sh(1),
> so i use just 'win' and access the windows files from /n/C.
> i have shell functions defined in $home/lib/func
1.name changed to ratrace
2. output now to stderr
3. phooey. For some reason when a syscall fails the errstr prints an
empty string. 9vx/trap.c: any suggestions?
ron
On Wed, 19 May 2010 13:38:36 PDT ron minnich wrote:
> On Wed, May 19, 2010 at 1:30 PM, Bakul Shah wro=
> te:
>
> > You write "startsyscall" to /syscall for every trace
> > buffer read -- don't quite understand why that is needed.
>
> It gives you the option of not restarting the system call un
On Wed, May 19, 2010 at 3:02 PM, Bakul Shah wrote:
>> It gives you the option of not restarting the system call until later.
>> There could be more complex usage scenarios.
>
> I don't understand this.
You read the "start of the system call" message. The process is
stopped. It has not run the sy
On Wed, May 19, 2010 at 2:48 PM, ron minnich wrote:
> 3. phooey. For some reason when a syscall fails the errstr prints an
> empty string. 9vx/trap.c: any suggestions?
Fixed.
Ron
2010/5/19 ron minnich :
> On Wed, May 19, 2010 at 3:02 PM, Bakul Shah wrote:
>
>>> It gives you the option of not restarting the system call until later.
>>> There could be more complex usage scenarios.
>>
>> I don't understand this.
>
> You read the "start of the system call" message. The process
You THINK you have lots of control when you're dropping 'into' acid.
Ah! Thank you for this!
The initialization works
perfectly now.
I wonder, however, if there
is another problem around
z38.c:254, like the one you
have mentioned here?
I get the following (extra
debugging info removed)
when I try to do
cpu% cd doc/slides
cpu% lout -r2 all > slides.ps
cm: line
On Wed, 19 May 2010 15:25:52 PDT ron minnich wrote:
> On Wed, May 19, 2010 at 3:02 PM, Bakul Shah wrote
> :
>
> >> It gives you the option of not restarting the system call until later.
> >> There could be more complex usage scenarios.
> >
> > I don't understand this.
>
> You read the "start o
On Wed, May 19, 2010 at 5:26 PM, Bakul Shah wrote:
> time ratrace -o /dev/null -c mk # about 19.67 seconds
did you want [2]>/dev/null?
> mk clean
> time mk # about 0.88 seconds
>
> And here I thought naming it ratrace would make it go faster.
Speed is left as an exercis
How do you folks using acme-sac on Windows deal with the line-ending
issue? I've been using P9P acme on linux (at work) since Russ announced
it, but I consider the line-ending issue a show-stopper on Windows.
While the cr displayed at the end of every line is annoying, I could
probably learn to l
On my cpu server, replica seems to be confused over its current
point in time.
When I first ran it today, I got a bunch of (correct) local
conflicts, and several files were updated. I resolved a few of
the local conflicts and re-ran, and while several things worked
fine, some odd behavior started
On Wed, May 19, 2010 at 10:08 PM, wrote:
> I'm stumped. Anyone have any ideas?
Yes, what I have done is stop using replica. I pull source from
bitbucket.org and build.
Replica is an interesting idea that does not work in the wide area. At
least not for me ...
ron
I had a question from someone about the syscalltrace. It has not
relationship to the earlier devtrace work that Floren and I did.
Thanks
ron
> How do you folks using acme-sac on Windows deal with the line-ending
> issue?
pipefs(4) can be used to filter windows directory trees:
http://groups.google.com/group/acme-sac/msg/973e8c67b33a7976
and also to filter /chan/snarf (in $home/lib/profile):
http://groups.google.com/group/acme-sac/msg/
39 matches
Mail list logo
