[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Tux-T9 crashes under load



Ingo,

>     /usr/sbin/tux -t $TUXTHREADS -r $DOCROOT $EXTRAOPTS $TUXMODULES
>

That works very nicely.  I get the following:

Starting tux: opening shared library /var/www/spec/user_modules/CAD_u.tux.so
handle: 0x1201089f0
TUXAPI_init: 0x200007d0eb0
TUXAPI_handle_events: 0x200007d0ce0
register {CAD_u.tux} - TUX returned 0...
waiting for TUX thread 0.
start - TUX 0 returned 0...
tux() returned: 2!
---=> send_err(), from 0x200007d0a4c: CAD: error while sending object file!

<=---
last event: -1.
TUX thread 0 returned with status 0.


This error occurs in CAD_send:

CAD_u:
/*
 * Send a dynamicly generated buffer. (this is the typical
 * CAD case) Every reply is generated dynamically based on
 * the template and cookie values. The template is scanned
 * for every send.
 */
static int CAD_send (user_req_t *req)
{
...
                ret = tux(TUX_ACTION_SEND_OBJECT, req);
                if (ret != TUX_RETURN_USERSPACE_REQUEST) {
                        printf("tux() returned: %d!\n", ret);
                        return send_err(req, "CAD: error while sending object file!\n");
..
}

This was expecting a TUX_RETURN_USERSPACE_REQUEST, but instead received a
TUX_RETURN_SIGNAL.

Is this consistent with a SEGFAULT?

Are there any other cases where tux should return "TUX_RETURN_SIGNAL"?

How should my application handle it?


> additionally you might want to attach to the first TUX worker thread via
> gdb, to catch SIGSEGVs on the spot.

That's a good idea.  We had been trying to use "CAD_u.so" as the image.

/usr/sbin/tux works much better... ;-)

(I've just tried it, when the process stops, I get the following:
reading register pc (#64): No such process.

I'll have to dig deeper...
)


> is a "killall -9 tux" and "tux stop" shutting down TUX properly?
>
> 	Ingo

Yep.


Thanks for all the help,
--Phil

Compaq:  High Performance Server Division/Benchmark Performance Engineering
---------------- Alpha, The Fastest Processor on Earth --------------------
Phillip.Ezolt@compaq.com        |C|O|M|P|A|Q|        ezolt@perf.zko.dec.com
------------------- See the results at www.spec.org -----------------------

On Wed, 21 Mar 2001, Ingo Molnar wrote:

>
> On Mon, 19 Mar 2001, Phillip Ezolt wrote:
>
> > When running the SPECWeb99 workload against linux-2.4.2-tuxT9-kgdb, it
> > crashs in the middle of the test.
>
> your messages file shows that TUX does not crash - your TUX thread exit()s
> (or SEGFAULTs), possibly in the userspace module, due to a bug in
> userspace. I'd suggest for you to run TUX 'directly' so that all module
> messages go to the console. Replace this line in /etc/rc.d/init.d/tux:
>
>     daemon /usr/sbin/tux -d -t $TUXTHREADS -r $DOCROOT $EXTRAOPTS $TUXMODULES
>
> with this line:
>
>     /usr/sbin/tux -t $TUXTHREADS -r $DOCROOT $EXTRAOPTS $TUXMODULES
>
> additionally you might want to attach to the first TUX worker thread via
> gdb, to catch SIGSEGVs on the spot.
>
> > The logger remains, and the only hint of the problem is in
> > /var/log/messages.
>
> is a "killall -9 tux" and "tux stop" shutting down TUX properly?
>
> 	Ingo
>
>
>
> _______________________________________________
> tux-list mailing list
> tux-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/tux-list
>
>





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []