Serious problem with RMI on jdk15

[Nikolay Denev]

On Oct 13, 2008, at 11:47 PM, Greg Lewis wrote:

> On Mon, Oct 13, 2008 at 05:58:58PM +0300, Nikolay Denev wrote:
>> On Oct 13, 2008, at 5:47 PM, Nikolay Denev wrote:
>>> On Oct 9, 2008, at 4:35 PM, Nikolay Denev wrote:
>>>
>>>> Hi All,
>>>>
>>>> I have the following problem : when I connect to a jmxremote
>>>> enabled application with jconsole the whole VM crashes with
>>>> segmentation fault.
>>>>
>>> [...snip...]
>>>>
>>>> I'm running amd64 7.1-PRE from yesterday, and the jdk is
>>>> jdk-1.5.0.14p8_3,1
>>>>
>>>> Any help is greatly appreciated!
>>>>
>>>> Thanks,
>>>> Nikolay Denev
>>>
>>> I think I've tracked down the problem.
>>> The JVM crashes when one requests the TotalPhysicalMemory from the
>>> OperatingSystem bean.
>>> The strange thing is that Sun specifies this value as "long", but
>>> how this can work on 64bit machines with many gigabytes of memory?
>>>
>>> What BSD patchset does is read the hw.physmem sysctl, which returns
>>> unsigned long, and then cast it to jlong and probably this is where
>>> the problem is.
>>> I've tried disabling the sysctl and hardcoding the result and my JVM
>>> does not crash anymore.
>>> Jconsole still does not show anything though.... and the same test
>>> program produces info when used with the diablo-jdk15...
>>>
>>>
>>> Regards,
>>> Nikolay Denev
>>
>> As I read this now, It's not exactly correct, longs should be 4 bytes
>> on 32bit archs, and 8bytes on 64bit archs.
>> So the storage type for TotalPhysicalMemory should be ok. Maybe jlong
>> is not correctly adjusted to 8bytes on 64bit architectures?
>
> A jlong is typedef'ed as a 'long long' on both 32 and 64 bit  
> architectures.
> How much memory does the machine have and what architecture is it?
>
> -- 
> Greg Lewis                          Email   : glewis at eyesbeyond.com
> Eyes Beyond                         Web     : http:// 
> www.eyesbeyond.com
> Information Technology              FreeBSD : glewis at FreeBSD.org

Hi,

I've looked at the source and found out that myself, but it is still  
puzzling to me why it crashes...

The machine runs 7.1-PRERELASE a few days old (maybe a week) and is an  
amd64 with 2G of ram.

All my tcpdumps of the network communication between the jconsole and  
the app show that it crashes
right after the request for TotalPhysicalMemory, also I've confirmed  
this by ktracing the process, and
the thread that crashes does the sysctl() to get the hw.physmem value  
and immediately after the return from it,
  it receives a SIGSEGV.
I've instrumented the patchset and especialy this function not to do  
the sysctl() stuff but to return a hard coded value equal to the  
amount of memory on my machine without any casting to jlong and now it  
doesn't crash,
so it seems that the problem is somewhere there.

 From what I've read "long" and "long long" should be 64bit ints on  
64bit architectures, and the casting is done
only because hw.physmem sysctl is ulong?

Regards,
Nikolay Denev