Re: directory listing problem

["Sandro Magi" <naasking@hotmail.com> writes:]

>> rm -f ls
>> gcc -o ls ls.o /vsta/src/lib/libc_s.a
>At this point I run into a problem. gcc exits and pukes out this message:
> ls.o(.text+0xeb):undefined reference to cvt_id
> gcc: Internal Compiler error:program got fata signal 1

Hmmm, add "-lusr" to the end of the "gcc" command line. Or, actually, do a
"make ls" first and see what *it* links in as auxiliary libraries. But I'm
pretty sure it's "-lusr".

>I also ran into another interesting problem. I was logged in as root and all
>the source files had rw capabilities for sys.sys, and nothing for anyone
>else(this is what I could interpret given my current knowledge of VSTa). So
>I tried editing the file, but as soon as I typed 'i' in vi to insert some
>text, it dropped into the debugger. I quit that and it returned me to the
>command line, but when I tried typing in commands, I just got 'error 22'(or
>something similar) as my only response.

Did it say which process had died? I'm guessing DOS, since vim tries to
create a checkpoint file when you first make a change.

>I'm guessing server that handles the disk or filesystem exited because of
>permission violation. Am I close? Wouldn't better behaviour be to simply
>deny writing out the file, or is this a symptom of a deeper problem/bug?

Yes, in the normal circumstance that's what happens (DOS filesystems don't
have any actual protection labeling, so the VSTa DOS server acts as if
everything is globally readable and only writable by sys.sys). Having the
filesystem server barf usually means Something Bad. If you're on console 0
(the initial one) I'd be curious if a syslog message comes up saying
something about it. Also, do a "tf" while in the kernel debugger, and see
if it faulted on a segv, or trap type 255 (syscall)--i.e., a voluntary exit.
You can also get a stack backtrace of the dying user process; see:

        http://www.vsta.org/mail/2/0020.html

(Ignore the part about debug32--that's ancient history; but the stack
backtrace collection still works.) If you get the program counter values,
you can then go into /vsta/src/srv/dos, edit the makefile to have -g added
to COPTS, do "make", and then you can gdb the executable and turn those PC
values into source references.

There's definitely something funny going on with your filesystem. I just
can't guess what it is yet....

Andy Valencia
Received on Sun Feb 11 21:12:54 2001