Inexplicable Parameter-Passing Phenomena w/MinGW GCJ

Wed Sep 10 14:51:00 GMT 2003

Mohan Embar writes:
 > Hi Andrew,
 > 
 > > > When the above skt.getTimeout() call (which happens AFTER the
 > > > skt.setSoTimeout() call and should therefore have no effect on it)
 > > > is commented out, no message boxes appear.
 > > > 
 > > > I know I need to troubleshoot this and document this much further, but what
 > > > I'm looking for is any sort of "aha" here. Keep in mind that this is a
 > > > statically linked libgcj.
 > >
 > >Well, I can't believe that the right method is being called. You must
 > >have a version mismatch between .class and .java and .o. What makes
 > >you thisnk skt.getTimeout() really is called?
 > 
 > Good gravy. You're right. The call in impl.setOption() in DatagramSocket:
 > 
 > ---------------------------------------8<----------------------------------
 > public synchronized void setSoTimeout(int timeout) throws SocketException
 > {
 > if (timeout < 0)
 > throw new IllegalArgumentException("Invalid timeout: " + timeout);
 > 
 > impl.setOption(SocketOptions.SO_TIMEOUT, new Integer(timeout));
 > }
 > ---------------------------------------8<----------------------------------
 > 
 > ...ends up calling getOption() in natPlainDatagramSocketImplWin32.cc:
 > and impl.getOption() ends up calling setOption with a totally bogus
 > second parameter.
Right, so the method table offset is wrong.
 > I'm pretty sure that everything is in sync. I even did a clean get and build
 > of everything from CVS last night. Do you have any advice as to how
 > the wrong CNI-native method could get invoked? Or any tips at all?
<Deep Thought mode> All right, ... You're really not going to like it.
I would look at some assembly code. For whatever reason, the caller
and the called have different opinions about the method table offset
of setSoTimeout().
I still wonder if the compiler might be looking at different versions
of DatagramSocket.
Andrew.