[9fans] Plan 9 stack limit?

[9fans] Plan 9 stack limit?

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

I have an application that is crashing on Plan 9.  Now, it could be a bug in
the code, but in the past, similar problems with the same code base on other
platforms have always been caused by the system stack being blown out, and
in a less rare case, the systems running out of process space.  The crashes
are happening on 9vx.OSX (which is currently the only place it can be tested
on our systems).   Does 9vx have any such limitations and/or does Plan 9 in
general have any such limits?  And if so, can they be changed?   I see some
of the threading calls have stack size requests possible, but don't see any
such concerns as a consequence of a fork, though I'm sure fork is
semantically equivalent to some other calls when all is said and done.
Like I said, it could be a bug in the code, but I'd like to approach it from
this level first assuming there is any such interaction that even exists so
any insights would be appreciated.

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 1419 bytes --]

Re: [9fans] Plan 9 stack limit?

[ron minnich]

the app crashes or 9vx blows up?

You might consider ratrace. It helps me a lot with this stuff.

ron

Re: [9fans] Plan 9 stack limit?

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

On Tue, Sep 6, 2011 at 6:39 PM, ron minnich <rminnich@gmail.com> wrote:

> the app crashes or 9vx blows up?
>
> You might consider ratrace. It helps me a lot with this stuff.
>

9vx can blow up too but not related to this problem, so in this case it's
the app I'm talking about, or at least, appears to be the app.  Might get
something like "1476 TheApp fault 0x4 no segment"

Typing ratrace at the command line does not find it.  I'll try to locate it
on the ISO, or do I need to pick it up online?   It's for Plan 9 right, and
not to run 9vx "under it" on OSX?

- Greg
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 1316 bytes --]

Re: [9fans] Plan 9 stack limit?

[ron minnich]

OK, you're working from an old root if you can't find ratrace :-)

9fs sources, go grab it in sys/src/cmd, build and install it.

ratrace -c your-command-line

ron
p.s. First thing I do with a new 9vx is get all the sources down and
rebuilt all lib/bin from scratch. It's worth it.

Re: [9fans] Plan 9 stack limit?

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

On Wed, Sep 7, 2011 at 11:46 AM, ron minnich <rminnich@gmail.com> wrote:

> OK, you're working from an old root if you can't find ratrace :-)
>
> 9fs sources, go grab it in sys/src/cmd, build and install it.
>
> ratrace -c your-command-line
>
> ron
> p.s. First thing I do with a new 9vx is get all the sources down and
> rebuilt all lib/bin from scratch. It's worth it.
>

I think I tried something like that a few months back and could not seem to
be successful.  No doubt I did something wrong though at the time it was not
obvious what.   Where is the most current source I should be getting the
bytes from?

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 1323 bytes --]

Re: [9fans] Plan 9 stack limit?

[David du Colombier]

> I think I tried something like that a few months back and could not
> seem to be successful.  No doubt I did something wrong though at the
> time it was not obvious what.   Where is the most current source I
> should be getting the bytes from?

Why don't you simply extract the full content from the current
Plan 9 CD image?

http://plan9.bell-labs.com/plan9/download/plan9.iso.bz2

Don't forget to mount the CD image with 9660srv from plan9port to
preserve file names.

--
David du Colombier

Re: [9fans] Plan 9 stack limit?

[erik quanstrom]

> ron
> p.s. First thing I do with a new 9vx is get all the sources down and
> rebuilt all lib/bin from scratch. It's worth it.

is this plan9's version of gentoo?

- erik

Re: [9fans] Plan 9 stack limit?

[Mathieu Lonjaret]

maybe slightly relevant:
http://9fans.net/archive/2010/05/446
(see also answers from others as well afterwards).

On Wed, Sep 7, 2011 at 12:30 AM, Comeau At9Fans <comeauat9fans@gmail.com> wrote:
> I have an application that is crashing on Plan 9.  Now, it could be a bug in
> the code, but in the past, similar problems with the same code base on other
> platforms have always been caused by the system stack being blown out, and
> in a less rare case, the systems running out of process space.  The crashes
> are happening on 9vx.OSX (which is currently the only place it can be tested
> on our systems).   Does 9vx have any such limitations and/or does Plan 9 in
> general have any such limits?  And if so, can they be changed?   I see some
> of the threading calls have stack size requests possible, but don't see any
> such concerns as a consequence of a fork, though I'm sure fork is
> semantically equivalent to some other calls when all is said and done.
> Like I said, it could be a bug in the code, but I'd like to approach it from
> this level first assuming there is any such interaction that even exists so
> any insights would be appreciated.
>
> --
> Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
> Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
> World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
> Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
>

Re: [9fans] Plan 9 stack limit?

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Tue, Sep 6, 2011 at 7:10 PM, Mathieu Lonjaret <mathieu.lonjaret@gmail.com
> wrote:

> maybe slightly relevant:
> http://9fans.net/archive/2010/05/446
> (see also answers from others as well afterwards).
>
>
Thanks, I'll take a look.

- Greg
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 1030 bytes --]

Re: [9fans] Plan 9 stack limit?

[erik quanstrom]

On Tue Sep  6 19:10:46 EDT 2011, mathieu.lonjaret@gmail.com wrote:
> maybe slightly relevant:
> http://9fans.net/archive/2010/05/446
> (see also answers from others as well afterwards).
> 
> On Wed, Sep 7, 2011 at 12:30 AM, Comeau At9Fans <comeauat9fans@gmail.com> wrote:
> > I have an application that is crashing on Plan 9.  Now, it could be a bug in
> > the code, but in the past, similar problems with the same code base on other
> > platforms have always been caused by the system stack being blown out, and
> > in a less rare case, the systems running out of process space.  The crashes
> > are happening on 9vx.OSX (which is currently the only place it can be tested
> > on our systems).   Does 9vx have any such limitations and/or does Plan 9 in
> > general have any such limits?  And if so, can they be changed?   I see some
> > of the threading calls have stack size requests possible, but don't see any
> > such concerns as a consequence of a fork, though I'm sure fork is
> > semantically equivalent to some other calls when all is said and done.
> > Like I said, it could be a bug in the code, but I'd like to approach it from
> > this level first assuming there is any such interaction that even exists so
> > any insights would be appreciated.

good reference.

it's worth noting that a gsoc student (venkatesh srinivas) extended the plan 9
segment model to allow an arbitrary number of them.  this was fairly interesting,
but not of much practical interest.  then he implemented the concept of "segment
group".  group segments alter the address space of each process in the group.
then (here's the neat part) the thread library was modified to make two adjacent
group segments for each stack.  the lower one is not mapped and will always fault
on reference.  the upper one is grow-down, zero-and-map on reference,
so there's not much penalty for making your thread stacks a little too large.
the main limit is deference to machines with a punny 32-bit address space.

i really need to take another look at this and see about merging it into my kernel.
thread library stacks are a big debugging hassle.

- erik

Re: [9fans] Plan 9 stack limit?

[Russ Cox]

On 9vx the entire address space for
a running process is 256 MB.  The heap
grows up and the stack grows down.
It is easy to believe you could have blown
out the stack.

Is it just the program you ran that crashed
or is it all of 9vx?

The fact that you said '9vx.OSX' makes me
think you might be running one of the
pre-compiled binaries, which are unfortunately
a bit old.  If it's not a stack overflow problem,
you might have better luck with
http://swtch.com/~rsc/9vx.OSX.gz, which I just
compiled from the latest sources.

Russ

Re: [9fans] Plan 9 stack limit?

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

On Tue, Sep 6, 2011 at 8:00 PM, Russ Cox <rsc@swtch.com> wrote:

> On 9vx the entire address space for
> a running process is 256 MB.  The heap
> grows up and the stack grows down.
> It is easy to believe you could have blown
> out the stack.
>

Ok.


> Is it just the program you ran that crashed
> or is it all of 9vx?
>

The app.  9vx will continue to run after it.  It give a little dump thing on
the screen with "1476 The.App fault 0x4 no segment" send to the shell
account 9vx was started from.  Running acid on the app does not appear to
bring up a line of code that should really be having a problem (though of
course if it's a bug I could be wrong).



> The fact that you said '9vx.OSX' makes me
> think you might be running one of the
> pre-compiled binaries, which are unfortunately
> a bit old.  If it's not a stack overflow problem,
> you might have better luck with
> http://swtch.com/~rsc/9vx.OSX.gz, which I just
> compiled from the latest sources.


I'll give it a try.   What will be the difference in this version in regards
to a problem like the one I'm seeing?


--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 2180 bytes --]

Re: [9fans] Plan 9 stack limit?

[Russ Cox]

On Wed, Sep 7, 2011 at 9:43 AM, Comeau At9Fans <comeauat9fans@gmail.com> wrote:
> The app.  9vx will continue to run after it.  It give a little dump thing on
> the screen with "1476 The.App fault 0x4 no segment" send to the shell
> account 9vx was started from.  Running acid on the app does not appear to
> bring up a line of code that should really be having a problem (though of
> course if it's a bug I could be wrong).

regs() might be interesting, along with asm(*PC).
If I remember the output format correctly that looks
like it faulted accessing 0x4, which seems more likely
a null pointer deref than stack overflow.

>  What will be the difference in this version in regards to a problem
> like the one I'm seeing?

Probably nothing at all.  If 9vx had been crashing then
the difference would hopefully have been '9vx doesn't
crash anymore'.  :-)

Russ

Re: [9fans] Plan 9 stack limit?

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

On Wed, Sep 7, 2011 at 10:05 AM, Russ Cox <rsc@swtch.com> wrote:

> On Wed, Sep 7, 2011 at 9:43 AM, Comeau At9Fans <comeauat9fans@gmail.com>
> wrote:
> > The app.  9vx will continue to run after it.  It give a little dump thing
> on
> > the screen with "1476 The.App fault 0x4 no segment" send to the shell
> > account 9vx was started from.  Running acid on the app does not appear to
> > bring up a line of code that should really be having a problem (though of
> > course if it's a bug I could be wrong).
>
> regs() might be interesting, along with asm(*PC).
> If I remember the output format correctly that looks
> like it faulted accessing 0x4, which seems more likely
> a null pointer deref than stack overflow.
>
> >  What will be the difference in this version in regards to a problem
> > like the one I'm seeing?
>
> Probably nothing at all.  If 9vx had been crashing then
> the difference would hopefully have been '9vx doesn't
> crash anymore'.  :-)


huh, oh ok :)  I'll be giving it a whirl shortly...

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 1847 bytes --]

Re: [9fans] Plan 9 stack limit?

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 1702 bytes --]

On Wed, Sep 7, 2011 at 12:38 PM, Comeau At9Fans <comeauat9fans@gmail.com>wrote:

> On Wed, Sep 7, 2011 at 10:05 AM, Russ Cox <rsc@swtch.com> wrote:
>
>> On Wed, Sep 7, 2011 at 9:43 AM, Comeau At9Fans <comeauat9fans@gmail.com>
>> wrote:
>> > The app.  9vx will continue to run after it.  It give a little dump
>> thing on
>> > the screen with "1476 The.App fault 0x4 no segment" send to the shell
>> > account 9vx was started from.  Running acid on the app does not appear
>> to
>> > bring up a line of code that should really be having a problem (though
>> of
>> > course if it's a bug I could be wrong).
>>
>> regs() might be interesting, along with asm(*PC).
>> If I remember the output format correctly that looks
>> like it faulted accessing 0x4, which seems more likely
>> a null pointer deref than stack overflow.
>>
>> >  What will be the difference in this version in regards to a problem
>> > like the one I'm seeing?
>>
>> Probably nothing at all.  If 9vx had been crashing then
>> the difference would hopefully have been '9vx doesn't
>> crash anymore'.  :-)
>
>
> huh, oh ok :)  I'll be giving it a whirl shortly...
>

Hmm, I downloaded the new 9vx.OSX, recompiled the app, and don't seem to be
able to get it to fail anymore.  Unless this 9vx is known to fix issues such
as this, I've been around the block enough to be suspect I may not have
really solved the problem, so will do more testing.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 2550 bytes --]

Re: [9fans] Plan 9 stack limit?

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

On Wed, Sep 7, 2011 at 4:12 PM, Comeau At9Fans <comeauat9fans@gmail.com>wrote:

> Hmm, I downloaded the new 9vx.OSX, recompiled the app, and don't seem to be
> able to get it to fail anymore.  Unless this 9vx is known to fix issues such
> as this, I've been around the block enough to be suspect I may not have
> really solved the problem, so will do more testing.
>

Threw a lot more at it and it seemed ok, until just now.  This time, for the
first time (with this problem) the app did not crash but 9vx.OSX crashed and
gave:

  libvx32/emu.c:1668: failed assertion `(void*)extra < (void*)codetab'

Any thoughts?

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 1323 bytes --]

Re: [9fans] Plan 9 stack limit?

[Russ Cox]

On Wed, Sep 7, 2011 at 9:18 PM, Comeau At9Fans <comeauat9fans@gmail.com> wrote:
> Threw a lot more at it and it seemed ok, until just now.  This time, for the
> first time (with this problem) the app did not crash but 9vx.OSX crashed and
> gave:
>   libvx32/emu.c:1668: failed assertion `(void*)extra < (void*)codetab'
>
> Any thoughts?

Honestly, it's magical to me that 9vx works as well as it does.
If you really want to debug your program and not a VM,
I would suggest grabbing VMware Player and booting the ISO.
9vx was and remains an amazing hack, but I don't think it's
really a solid piece of software.

Russ