Guile 2.0 eating memory on ARM

Guile 2.0 eating memory on ARM

[Neil Jerram]

Hi there...

I think I've successfully cross-compiled Guile (stable-2.0, e309f3bf9e)
for my Freerunner phone.  However, when I run it, it just keeps
allocating memory until the OOM killer kills it:

root@om-gta02 ~ # guile -c 3
Killed
root@om-gta02 ~ # guile
Killed

and if I strace it, the log ends with lots of repetitions of:

brk(0x590f000)                          = 0x510f000                             
mmap2(0x40fd2000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE, 5, 0) = 0x40fd2000  
mmap2(0x40fe2000, 8388608, PROT_READ|PROT_WRITE, MAP_PRIVATE, 5, 0) = -1 ENOMEM 

I don't have any more detailed investigation or solutions yet.  But in
case anyone else is in a similar area - let's compare notes.

Also a couple of notes to connect back with previous threads about
cross-compiling:

- I have some more patches to allow the running of guile and guile-tools
  during the build.  I'll post those probably tomorrow, and also compare
  them with Jan's series.

- Following the discussion about a cross version of `guile-tools
  compile', I realized that the Freerunner ARM platform is
  little-endian, and hence the .go files should be identical to those
  for x86.  Therefore, although I was going to look at adding a target
  type in the way that Ludo and Andy agreed, I don't actually need to do
  that yet.

  (Is that right?  In any case, it definitely isn't relevant to the
  memory eating problem, because the strace shows that guile hasn't yet
  tried to open any .scm or .go files.)

Regards,
    Neil

Re: Guile 2.0 eating memory on ARM

[nalaginrut]

> Hi there...
> 
> I think I've successfully cross-compiled Guile (stable-2.0, e309f3bf9e)
> for my Freerunner phone.  However, when I run it, it just keeps
> allocating memory until the OOM killer kills it:
> 
> root@om-gta02 ~ # guile -c 3
> Killed
> root@om-gta02 ~ # guile
> Killed
> 
> and if I strace it, the log ends with lots of repetitions of:
> 
> brk(0x590f000)                          = 0x510f000                             
> mmap2(0x40fd2000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE, 5, 0) = 0x40fd2000  
> mmap2(0x40fe2000, 8388608, PROT_READ|PROT_WRITE, MAP_PRIVATE, 5, 0) = -1 ENOMEM 
> 
> I don't have any more detailed investigation or solutions yet.  But in
> case anyone else is in a similar area - let's compare notes.
> 
> Also a couple of notes to connect back with previous threads about
> cross-compiling:
> 
> - I have some more patches to allow the running of guile and guile-tools
>   during the build.  I'll post those probably tomorrow, and also compare
>   them with Jan's series.
> 
> - Following the discussion about a cross version of `guile-tools
>   compile', I realized that the Freerunner ARM platform is
>   little-endian, and hence the .go files should be identical to those
>   for x86.  Therefore, although I was going to look at adding a target
>   type in the way that Ludo and Andy agreed, I don't actually need to do
>   that yet.
> 
>   (Is that right?  In any case, it definitely isn't relevant to the
>   memory eating problem, because the strace shows that guile hasn't yet
>   tried to open any .scm or .go files.)
> 
> Regards,
>     Neil
> 

I think guile on embedded device would be interesting since it has VM
now.  What kernel version your freerunner running?

-- 
GNU Powered it
GPL Protected it
GOD Blessed it

HFG - NalaGinrut

--hacker key--
v4sw7CUSMhw6ln6pr8OSFck4ma9u8MLSOFw3WDXGm7g/l8Li6e7t4TNGSb8AGORTDLMen6g6RASZOGCHPa28s1MIr4p-x hackerkey.com
---end key---

Re: Guile 2.0 eating memory on ARM

[Neil Jerram]

nalaginrut <nalaginrut@gmail.com> writes:

> I think guile on embedded device would be interesting since it has VM
> now.

Also since it has the FFI - which means being able to access lots of
libraries, without needing to prepare and cross-compile glue code.

>  What kernel version your freerunner running?

2.6.34

Regards,
      Neil

Re: Guile 2.0 eating memory on ARM

[Ludovic Courtès]

Hello Neil,

Neil Jerram <neil@ossau.uklinux.net> writes:

> I think I've successfully cross-compiled Guile (stable-2.0, e309f3bf9e)
> for my Freerunner phone.  However, when I run it, it just keeps
> allocating memory until the OOM killer kills it:

How much RAM does it have?  What is Guile doing when it gets killed?  Is
it running a program or just trying to get to the REPL?

> Also a couple of notes to connect back with previous threads about
> cross-compiling:
>
> - I have some more patches to allow the running of guile and guile-tools
>   during the build.  I'll post those probably tomorrow, and also compare
>   them with Jan's series.

Great!

> - Following the discussion about a cross version of `guile-tools
>   compile', I realized that the Freerunner ARM platform is
>   little-endian, and hence the .go files should be identical to those
>   for x86.  Therefore, although I was going to look at adding a target
>   type in the way that Ludo and Andy agreed, I don't actually need to do
>   that yet.
>
>   (Is that right?

I think so.

>   In any case, it definitely isn't relevant to the memory eating
>   problem, because the strace shows that guile hasn't yet tried to
>   open any .scm or .go files.)

Woow, really?  Then can you start it directly under gdb and interrupt it
quickly after to see what’s going on?

FWIW it runs on my GuruPlug, an ARM device, but that one has 512 MiB of RAM.

Thanks,
Ludo’.

Re: Guile 2.0 eating memory on ARM

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hello Neil,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> I think I've successfully cross-compiled Guile (stable-2.0, e309f3bf9e)
>> for my Freerunner phone.  However, when I run it, it just keeps
>> allocating memory until the OOM killer kills it:
>
> How much RAM does it have?

About 126Mb NAND, optionally plus 512Mb more SD card swap.  But I think
the behaviour was the same with and without the swap; with the swap it
just took longer before the OOM killer killed it.

>  What is Guile doing when it gets killed?  Is
> it running a program or just trying to get to the REPL?

Well, I tried once with `guile -c 3', i.e. just trying to evaluate `3',
and once with `guile', i.e. getting to the REPL.  I don't think it got
as far as where those two possibilities fork.

>> - Following the discussion about a cross version of `guile-tools
>>   compile', I realized that the Freerunner ARM platform is
>>   little-endian, and hence the .go files should be identical to those
>>   for x86.  Therefore, although I was going to look at adding a target
>>   type in the way that Ludo and Andy agreed, I don't actually need to do
>>   that yet.
>>
>>   (Is that right?
>
> I think so.

Thanks.

>>   In any case, it definitely isn't relevant to the memory eating
>>   problem, because the strace shows that guile hasn't yet tried to
>>   open any .scm or .go files.)
>
> Woow, really?  Then can you start it directly under gdb and interrupt it
> quickly after to see what’s going on?

Yes, I'll do that.  I also should try with libgc CVS, instead of my
current 7.2alpha4.

> FWIW it runs on my GuruPlug, an ARM device, but that one has 512 MiB of RAM.

If it's easy for you to find out, (i) what version of libgc are you
using there, and (ii) how much memory does Guile use to execute `guile
-c 3' or `guile'?

Another possibility is that the problem is ARM version-dependent.  Mine
is armv4t, which I understand is now a bit old.

Thanks for your input!

     Neil

Re: Guile 2.0 eating memory on ARM

[Ludovic Courtès]

Hi Neil,

Sorry for the late reply.

Neil Jerram <neil@ossau.uklinux.net> writes:

>> Neil Jerram <neil@ossau.uklinux.net> writes:
>>
>>> I think I've successfully cross-compiled Guile (stable-2.0, e309f3bf9e)
>>> for my Freerunner phone.  However, when I run it, it just keeps
>>> allocating memory until the OOM killer kills it:
>>
>> How much RAM does it have?
>
> About 126Mb NAND, optionally plus 512Mb more SD card swap.  But I think
> the behaviour was the same with and without the swap; with the swap it
> just took longer before the OOM killer killed it.

[...]

> Well, I tried once with `guile -c 3', i.e. just trying to evaluate `3',
> and once with `guile', i.e. getting to the REPL.  I don't think it got
> as far as where those two possibilities fork.

OK.

[...]

>> FWIW it runs on my GuruPlug, an ARM device, but that one has 512 MiB of RAM.
>
> If it's easy for you to find out, (i) what version of libgc are you
> using there, and (ii) how much memory does Guile use to execute `guile
> -c 3' or `guile'?

Guile at the REPL uses 12 MiB of RSS, and 27 MiB of virtual memory.

It’s actually Guile 1.9.15.67-dc20f and libgc 7.1, but I’ll try with
something more cutting edge.

> Another possibility is that the problem is ARM version-dependent.  Mine
> is armv4t, which I understand is now a bit old.

The GuruPlug is armv5tel.

--8<---------------cut here---------------start------------->8---
$ cat /proc/cpuinfo 
Processor       : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS        : 1192.75
Features        : swp half thumb fastmult edsp 
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1

Hardware        : Marvell GuruPlug Reference Board
Revision        : 0000
Serial          : 0000000000000000
--8<---------------cut here---------------end--------------->8---

Thanks,
Ludo’.