Re: more probs

Date view Thread view Subject view Author view

From: Tim Wilkinson (tim@transvirtual.com)
Date: Thu Feb 11 1999 - 18:04:33 EST


Godmar,

Well ... if you don't have EAGAIN (or EWOULDBLOCK since they're the same) in
jthreadedTimedRead then when read returns EAGAIN more than once (and this appears to
happen) it will timeout - even though it doesn't actually timeout (because the
timeout is zero). It would appear that the socket becomes ready even when their's
nothing to read (possibly because the connection has been made but no data sent).
You may be right that the timeout never works with my fix (checking now) but some
kind of fix is required here.

... time passes ...

Your right that soTimeout fails and throws a null pointer exception ....

Perhaps block on file should return true/false depending on whether it timed out or
not?

Tim

> >
> > Well appart from the fact that I'm an idiot and got one = in rather than
> > two (it should be == EAGAIN) - this problem came up on some socket tests
> > where I'd get EAGAIN on my Linux box and I wasn't doing any kind of
> > timeout thingy.
> >
>
> That fix doesn't change anything, IMO.
> You will never timeout then because EWOULDBLOCK==EAGAIN.
> Does your version pass SoTimeout.java on Linux?
>
> In fact, it still segfaults:
>
> (gdb) run
> Starting program: /x/gback/transvirtual/install-intrp/libexec/Kaffe SoTimeout
> Success 1.
> Success 2.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x2ee7f in virtualMachine (meth=0x164980, arg=0xefbfcd30, retval=0xefbfcfe0,
> tid=0x1317f0) at ../../../../kaffe/kaffe/kaffevm/intrp/../kaffe.def:2173
> 2173 load_offset_ref(mtable, stack(idx), method_dtable_offset);
> (gdb) bt
> #0 0x2ee7f in virtualMachine (meth=0x164980, arg=0xefbfcd30,
> retval=0xefbfcfe0, tid=0x1317f0)
> at ../../../../kaffe/kaffe/kaffevm/intrp/../kaffe.def:2173
> #1 0x28f14 in callMethodV (meth=0x164980, func=0x164980, obj=0x0,
> args=0xefbfd080 "\001", ret=0xefbfcfe0)
> at ../../../kaffe/kaffe/kaffevm/support.c:544
> #2 0x232d8 in Kaffe_CallStaticVoidMethodV (env=0x4cda0, cls=0x164910,
> meth=0x164980, args=0xefbfd07c "\200·\026")
> at ../../../kaffe/kaffe/kaffevm/jni.c:2282
> #3 0x23331 in Kaffe_CallStaticVoidMethod (env=0x4cda0, cls=0x164910,
> meth=0x164980) at ../../../kaffe/kaffe/kaffevm/jni.c:2295
> #4 0x5088 in main2 (env=0x4cda0, argv=0xefbfd4f4, farg=2, argc=0)
> at ../../../kaffe/kaffe/kaffe/main.c:188
> #5 0x4f26 in main (argc=2, argv=0xefbfd4f4)
> at ../../../kaffe/kaffe/kaffe/main.c:108
> (gdb) pmeth meth
> SoTimeout.main;([Ljava/lang/String;)V
> (gdb) p mtable
> $1 = {{v = {tint = 1428168, tword = 1428168, tlong = 0xefbfcd300015cac8,
> tfloat = 2.00128963e-39, tdouble = -1.9286103650785768e+230,
> taddr = 0x15cac8, tstr = 0x15cac8 " L\026"}}}
> (gdb) p (Hjava_lang_Object*)mtable.v.taddr
> $2 = (Hjava_lang_Object *) 0x15cac8
> (gdb) p *$2.dtable
> $3 = {class = 0x10a110, method = {0x1ac238}}
> (gdb) p *$3.class
> $4 = {head = {dtable = 0x114600}, centry = 0x122010, name = 0x122040,
> sourcefile = 0x122070 "8\001\021", accflags = 8352, superclass = 0x1220d0,
> constants = {size = 1188096, tags = 0x122130 "x\003\021", data = 0x1257c0},
> methods = 0x122190, nmethods = 8640, msize = 18, fields = 0x1221f0,
> bfsize = 1188384, nfields = 20544, nsfields = 18, dtable = 0x125070,
> interfaces = 0x1250a0, if2itable = 0x1250d0, itable2dtable = 0x125100,
> interface_len = 20784, total_interface_len = 18, loader = 0x125160,
> gc_layout = 0x125190, state = -64 'À', processingThread = 0x1251f0,
> finalizer = 0x125220, static_data = 0x125250}
>
> This is screwed up. mtable should be a java.lang.string.
>
> - Godmar

--
  Tim Wilkinson                         Tel:     +1 510 704 1660
  Transvirtual Technologies, Inc.,      Fax:     +1 510 704 1893
  Berkeley, CA, USA.                    Email:   tim@transvirtual.com


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:06 EDT