On Sun, Sep 14, 2003 at 02:57:09PM +0200, Florian Schaefer wrote:
> over the last weeks the same thing happened here several times, venus
> 6.0.2 got a "fatal signal (11)". Every time I just did a "venus -init"
> and everything worked again.

I can't really tell anything from the logs, but the backtrace shows that
it is at least a crash in venus itself and not a shared library.

However, without symbols it is hard to tell where exactly, it does seem
to match the venus binary on our webserver somewhat.

It doesn't look like it has anything to do with RVM though.

Jan

> (gdb) bt
> #0  0x4019c944 in sigsuspend () from /lib/libc.so.6
> #1  0x080b7f38 in strcpy ()
    sighand.cc:259  SigExit

> #2  <signal handler called>
> #3  0x08070518 in strcpy ()
    fso_cfscalls2.cc:100  fsobj::Open(int, int, int, venus_cnode*, unsigned int)

> #4  0x081324f0 in ?? ()
    Strangely enough this is not within the venus binary...

> #5  0x080b1ad3 in strcpy ()
    vproc_vfscalls.cc:238  vproc::open(venus_cnode*, int)

> #6  0x080b6a16 in strcpy ()
    worker.cc:1339  worker::main()

> #7  0x080acf25 in strcpy ()
    vproc.cc:126  VprocPreamble(Lock*)

And most of these actually look pretty reasonable except for the point
where it 'supposedly' got the segfault. As we're testing a field in the
flags of the current fso, there is no strange pointer dereference...

Ok, I looked a bit further and if we are opening this object for
writing, then this is probably the first place that we actually look at
the current object within the fsobj::Open function. So that would
indicate that vproc::open tried to invoke f->Open(...) on a bad 'f', but
then we would have already died in an earlier f->Access, f->IsDir or
f->IsFile call.

So I don't really know how or why this could be happening. The secret is
probably hidden within that strange frame #4, I can see the call from
vproc::open to fsobj::Open, but there should not be anything in between.

Jan