Re: [rvm-research] [rvm-core] about sys.C sysMalloc warning

Hi Wang,

This is more on-topic for the researchers list, so I've redirected my 
reply there.

MMTk strongly assumes that it can have a large contiguous chunk of 
virtual memory to itself, and it can map it lazily when it needs it.
This doesn't sit well with Linux's assumptions about how applications 
want to use memory.  On Ubuntu, malloc generally allocates in low 
addresses, so by starting the heap at 0x50000000 or so, we allow malloc 
some space for itself.

Evidently malloc on SUSE isn't doing that, and I'm not sufficiently 
across suse to know why.


One possible workaround is to shift your virtual address space into a 
lower region of memory.

Edit build/targets/x86_64-linux.properties and change the value of

   target.max-mappable.address=0xb0000000

to be (say) 0x80000000.  Of course this will leave you with a very small 
usable memory, so you can increase it until you have problems.
You can also try dropping the lower-bound constants

target.bootimage.code.address=0x64000000
target.bootimage.data.address=0x60000000
target.bootimage.rmap.address=0x67000000

until you encounter problems - just make sure to keep them at the same 
offsets from each other.  I seem to recall some code that assumes that 
heap addresses are greater than 0x30000000, so that's probably the 
lowest usable offset.

You could also try running with -X:gc:eagerMmapSpaces=true, which should 
reserve MMTk's heap in advance.  I'm not sure whether this still works.

It's also worth checking whether malloc always uses the same addresses - 
if they move around from run to run, the problem may be harder to work 
around.

Let us know how you get on.

regards,
Robin

On 13/04/15 13:37, wangchenxi7 wrote:
> Hi,everyone
>
> I’m a new developer of JikesRVM. When I run the rvm ,something print on
> my screen and cause some random error.
>
>
> the warning is :
>
> malloc returned something that is in RVM address space: 0xa2f04530
>
> malloc returned something that is in RVM address space: 0xa2f04530
>
> malloc returned something that is in RVM address space: 0xa2f04530
>
> malloc returned something that is in RVM address space: 0xa2f04530
>
> malloc returned something that is in RVM address space: 0xa2f04530
>
> malloc returned something that is in RVM address space: 0xa2f04530
>
>
> and sometimes it will crash the program:
>
> JikesRVM: TROUBLE.  Got a signal (Segmentation fault; #11) from outside
> the VM's address space in thread 0xa2fffb40.
>
> JikesRVM: UNRECOVERABLE trapped signal 11 (Segmentation fault)
>
> handler stack f749be84
>
> si->si_addr   0x4
>
> cs            0x00000023
>
> ds            0x0000002b
>
> es            0x0000002b
>
> fs            0x00000000
>
> gs            0x00000063
>
> ss            0x0000002b
>
> edi           0x00000000
>
> esi -- PR/VP  0x000000a8
>
> ebp           0xa5500010
>
> esp -- SP     0x71a222d4
>
> ebx           0xf75c9ff4
>
> edx           0xa5500018
>
> ecx           0x00000000
>
> eax           0xa550003c
>
> eip           0xf749be84
>
> trapno        0x0000000e
>
> err           0x00000004
>
> eflags        0x00010207
>
> fpregs        a55042a0
>
> oldmask       0x00020000
>
> cr2           0x00000004
>
> fp0 0x00000000000000000000
>
> fp1 0x00000000000000000000
>
> fp2 0x00000000000000000000
>
> fp3 0x00000000000000000000
>
> fp4 0x00000000000000000000
>
> fp5 0x00000000000000000000
>
> fp6 0xb00012552516c1c34009
>
> fp7 0xbfc8f66208f7eb134001
>
> JikesRVM: internal error
>
> invalid native thread address (not an address a8)
>
> Aborted (core dumped)
>
>
> But,When I copy the program(see below) and the build jikesRVM-3.13 to a
> Ubuntu server，It’s all Ok.
>
>    1
>
>    2 public class accessArray {
>
>    3
>
>    4   public static void main(String[] args) {
>
>    5
>
>    6     final int size=1000000;
>
>    7
>
>    8 int a[]=new int[size];
>
>    9 int b[]=new int[size];
>
>   10 int c[]=new int[size];
>
>   11
>
>   12 int i,j,k;
>
>   13
>
>   14 for(i=0;i<size;i++){
>
>   15       a[i]=i;
>
>   16       b[i]=i+2;
>
>   17 //        System.out.println(b[i]);
>
>   18     }
>
>   19
>
>   20 for(j=0;j<size;j++)
>
>   21       c[j]=a[j]+b[j];
>
>   22
>
>   23 for(j=1;j<size;j*=10)
>
>   24       System.out.println(c[j]);
>
>   25   }
>
>   26
>
>   27 }
>
>
> My platform is
>
> LSB
> Version:core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:desktop-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch
>
> Distributor ID:SUSE LINUX
>
> Description:openSUSE 12.2 (x86_64)
>
> Release:12.2
>
> Codename:Mantis
>
>
> I can learn that this is caused by the overlap of the MMTk heap and some
> malloc thinks.But I don’t know how to correct it ?
>
>
> Anything responsed is helpful. Thank you!
>
>
>        wang
>
> China CAS.ICT
>
>
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>
>
>
> _______________________________________________
> Jikesrvm-core mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>


------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Jikesrvm-researchers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers