subject:"Re\: \[Factor\-talk\] Out Of Memory"

Re: [Factor-talk] Out Of Memory

2016-11-24 Thread Jon Harper

That's because you are running a 32 bit factor. Try allocating many arrays,
at some point your OS should return an error to factor at
https://github.com/factor/factor/blob/master/vm/os-windows.cpp#L97

Also what you are seeing is expected, the array size is limited to
most-positive-fixnum/2, which is not a problem on 64bits (2^58-1 ~ 10^17 )
but is kind of limiting on 32 bits (2^26-1 = 67 million ~= 10^8). There was
discussions about this but I can't find it anymore...

Jon

On Thu, Nov 24, 2016 at 4:45 PM, Alexander Ilin  wrote:

> Hello!
>
> Unfortunately, I can't reproduce this in Win8.1 GUI listener:
>
> IN: scratchpad 50 2^ 0 
> Cannot convert to fixnum: 1125899906842624
>
> IN: scratchpad 25 2^ 0 
> (success)
>
> IN: scratchpad 26 2^ 0 
> Invalid array size: 67108864
> Maximum: 67108863
> 24.11.2016, 17:06, "Jon Harper" :
>
> Hi,
> more precisely, the process is aborted (uses the vm 'fatal_error()'
> function):
>
> $ ./factor -run=listener
> Factor 0.98 x86.64 (1781, heads/master-d4528c36da, Tue Aug 16 17:00:11
> 2016)
> [Clang (GCC 4.2.1 Compatible Ubuntu Clang 3.4 (tags/RELEASE_34/final))] on
> linux
> IN: scratchpad 50 2^ 0 
> fatal_error: Out of memory in mmap: 0x2018a82000
> [ ... ]
> Aborted (core dumped)
>
>
>
> Jon
>
> On Thu, Nov 24, 2016 at 4:15 AM, Björn Lindqvist 
> wrote:
>
> Hi,
>
> It shouldn't crash exactly, but it does terminate the process with an
> "Out of memory" error.
>
> 2016-11-23 20:43 GMT+01:00 Alexander Ilin :
> > Hello!
> >
> >   What happens if Factor is out of memory?
> >   Does it throw an exception and aborts the current operation? Or does
> it simply crash the instance?
> >   For me it simply crashes, which is not very nice.
>
>
> ---=---
> Александр
>
>
> 
> --
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Out Of Memory

2016-11-24 Thread Alexander Ilin

Hello! Unfortunately, I can't reproduce this in Win8.1 GUI listener: IN: scratchpad 50 2^ 0 Cannot convert to fixnum: 1125899906842624 IN: scratchpad 25 2^ 0 (success) IN: scratchpad 26 2^ 0 Invalid array size: 67108864Maximum: 6710886324.11.2016, 17:06, "Jon Harper" :Hi,more precisely, the process is aborted (uses the vm 'fatal_error()' function):$ ./factor -run=listenerFactor 0.98 x86.64 (1781, heads/master-d4528c36da, Tue Aug 16 17:00:11 2016)[Clang (GCC 4.2.1 Compatible Ubuntu Clang 3.4 (tags/RELEASE_34/final))] on linuxIN: scratchpad 50 2^ 0 fatal_error: Out of memory in mmap: 0x2018a82000[ ... ]Aborted (core dumped)  Jon On Thu, Nov 24, 2016 at 4:15 AM, Björn Lindqvist  wrote:Hi,It shouldn't crash exactly, but it does terminate the process with an"Out of memory" error.2016-11-23 20:43 GMT+01:00 Alexander Ilin :> Hello!>>   What happens if Factor is out of memory?>   Does it throw an exception and aborts the current operation? Or does it simply crash the instance?>   For me it simply crashes, which is not very nice. ---=---Александр --
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Out Of Memory

2016-11-24 Thread Jon Harper

Hi,
more precisely, the process is aborted (uses the vm 'fatal_error()'
function):

$ ./factor -run=listener
Factor 0.98 x86.64 (1781, heads/master-d4528c36da, Tue Aug 16 17:00:11 2016)
[Clang (GCC 4.2.1 Compatible Ubuntu Clang 3.4 (tags/RELEASE_34/final))] on
linux
IN: scratchpad 50 2^ 0 
fatal_error: Out of memory in mmap: 0x2018a82000
[ ... ]
Aborted (core dumped)



Jon

On Thu, Nov 24, 2016 at 4:15 AM, Björn Lindqvist  wrote:

> Hi,
>
> It shouldn't crash exactly, but it does terminate the process with an
> "Out of memory" error.
>
> 2016-11-23 20:43 GMT+01:00 Alexander Ilin :
> > Hello!
> >
> >   What happens if Factor is out of memory?
> >   Does it throw an exception and aborts the current operation? Or does
> it simply crash the instance?
> >   For me it simply crashes, which is not very nice.
> >
> > ---=---
> >  Александр
> >
> > 
> --
> > ___
> > Factor-talk mailing list
> > Factor-talk@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
>
> --
> mvh/best regards Björn Lindqvist
>
> 
> --
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Out Of Memory

2016-11-23 Thread Björn Lindqvist

Hi,

It shouldn't crash exactly, but it does terminate the process with an
"Out of memory" error.

2016-11-23 20:43 GMT+01:00 Alexander Ilin :
> Hello!
>
>   What happens if Factor is out of memory?
>   Does it throw an exception and aborts the current operation? Or does it 
> simply crash the instance?
>   For me it simply crashes, which is not very nice.
>
> ---=---
>  Александр
>
> --
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk



-- 
mvh/best regards Björn Lindqvist

--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Out of memory error

2012-09-12 Thread John Benediktsson

I can confirm that it speeds up some benchmarks!

But also that it has math.simd failures:

https://github.com/slavapestov/factor/issues/671

How should we go about debugging this for merging?

Btw, awesome work!


On Mon, Sep 10, 2012 at 9:35 AM, Alexander J. Vondrak 
ajvond...@csupomona.edu wrote:

 Latest working* code was at https://github.com/ajvondrak/factor/tree/gvn

 *I haven't pushed any of the stuff I was experimenting on when I started
 having
 problems with `load-all test-all`.  But before those issues, I gave up on
 figuring out why math.vectors.simd tests (specifically around the
 check-vector-ops tests) were causing memory protection faults with GVN
 enabled
 (they don't with it disabled), hoping that getting gvn-tests.factor up to
 date
 would resolve issues.  But, I got gvn-tests.factor working without needing
 any
 changes to the GVN pass itself, so I reckon the math.vectors.simd tests
 will
 still fail.  Hopefully one of you knows more about how to go around
 debugging
 those tests than I do?  (If you can reproduce, anyway.)

 As for the code itself, I started by copying over
 basis/compiler/cfg/value-numbering/ to extra/compiler/cfg/gvn/ and
 changing it
 there.  It was easier during development to not touch an existing compiler
 pass, lest the whole listener break.

 The diff between the gvn  value-numbering stuff is actually pretty small.
  But
 since they're different files, it might be a bit of a pain to figure some
 stuff
 out (to make sure you like it or whatever).  I've found myself doing a lot
 of
 `git diff --no-index` and `git merge-file basis/stuff /dev/null/
 extra/stuff`
 to resolve discrepancies.  Pretty sure I took care of the few changes made
 to
 the value-numbering vocab while I was working on gvn:

 https://github.com/ajvondrak/factor/commit/beff2088132d992c983ddebe5860183f01bc8b5e

 Otherwise, it should be a drop-in replacement of value-numbering: just
 change
 references to compiler.cfg.value-numbering into compiler.cfg.gvn in
 math.simd.vectors.intrinsics and compiler.cfg.optimizer.

 Extra things I can think of:
   - I needed to make a minor change to compiler.cfg.copy-prop due to the
 GVN
 changes, so that'll be in there.
   - The reason I wrote the graphviz vocab was to facilitate the fun stuff
 in

 https://github.com/ajvondrak/factor/blob/gvn/extra/compiler/cfg/graphviz
 and

 https://github.com/ajvondrak/factor/tree/gvn/extra/compiler/cfg/gvn/testing
 so I could include CFG diagrams in my thesis.
   - Just last night, I tried out a fresh 0.95 download's `load-all
 test-all`
 (in ./factor -run=listener) on my x86_64, up-to-date Arch install (same
 hardware as before).  Still crashed, but instead of getting out of
 memory
 I got a memory protection fault from the gc.  I hope to be improving
 the
 GVN pass some once I can get these errors figured out.  :-/  I notice
 there's been an issue opened about load-all test-all running out of
 memory
 (https://github.com/slavapestov/factor/issues/633); don't know if
 that's in
 response to what I brought up or not.

 So, I guess I kind of just went text dump mode there, but let me know if
 you
 have any questions or if there's anything I can do to help.

 Regards,
 --Alex Vondrak

 
 From: John Benediktsson [mrj...@gmail.com]
 Sent: Sunday, September 09, 2012 6:58 PM
 To: factor-talk@lists.sourceforge.net
 Subject: Re: [Factor-talk] Out of memory error

 I'd love to help you work on merging your GVN patches, where did we leave
 it?

 Best,
 John.

 On Sat, Aug 25, 2012 at 7:05 PM, Alexander J. Vondrak 
 ajvond...@csupomona.edumailto:ajvond...@csupomona.edu wrote:
 Good idea, but still no dice.

 --Alex Vondrak
 
 From: Doug Coleman [doug.cole...@gmail.commailto:doug.cole...@gmail.com]
 Sent: Saturday, August 25, 2012 4:28 PM
 To: factor-talk@lists.sourceforge.netmailto:
 factor-talk@lists.sourceforge.net
 Subject: Re: [Factor-talk] Out of memory error

 Are you running it in the shell listener? It might save memory.

 ./factor -run=listener

 load-all test-all

 Doug

 On Sat, Aug 25, 2012 at 1:36 PM, Alexander J. Vondrak
 ajvond...@csupomona.edumailto:ajvond...@csupomona.edu wrote:
  Just did a load-all test-all with 0.94, and that crashes, too.  I know
 that
  I've run those tests before without running out of memory, so I suspect
 it's
  either an OS update issue (who knows?) or how my setup is interacting
 with my
  new hardware (inherited some 64-bit hardware, still using my old 32-bit
 Debian
  install because I've been lazy about ditching
 it/upgrading/what-have-you).
  Don't know if that would make sense, per se, but hell, it's not the first
  problem I've had with my current OS setup.  If no one can reproduce, it's
  probably some combination of things on my end...
 
  I'll be trying the unit tests out again once I get Arch configured on
 another
  hard drive on this machine.
 
  Thanks

Re: [Factor-talk] Out of memory error

2012-09-10 Thread Alexander J. Vondrak

Latest working* code was at https://github.com/ajvondrak/factor/tree/gvn

*I haven't pushed any of the stuff I was experimenting on when I started having
problems with `load-all test-all`.  But before those issues, I gave up on
figuring out why math.vectors.simd tests (specifically around the
check-vector-ops tests) were causing memory protection faults with GVN enabled
(they don't with it disabled), hoping that getting gvn-tests.factor up to date
would resolve issues.  But, I got gvn-tests.factor working without needing any
changes to the GVN pass itself, so I reckon the math.vectors.simd tests will
still fail.  Hopefully one of you knows more about how to go around debugging
those tests than I do?  (If you can reproduce, anyway.)

As for the code itself, I started by copying over
basis/compiler/cfg/value-numbering/ to extra/compiler/cfg/gvn/ and changing it
there.  It was easier during development to not touch an existing compiler
pass, lest the whole listener break.

The diff between the gvn  value-numbering stuff is actually pretty small.  But
since they're different files, it might be a bit of a pain to figure some stuff
out (to make sure you like it or whatever).  I've found myself doing a lot of
`git diff --no-index` and `git merge-file basis/stuff /dev/null/ extra/stuff`
to resolve discrepancies.  Pretty sure I took care of the few changes made to
the value-numbering vocab while I was working on gvn:
https://github.com/ajvondrak/factor/commit/beff2088132d992c983ddebe5860183f01bc8b5e

Otherwise, it should be a drop-in replacement of value-numbering: just change
references to compiler.cfg.value-numbering into compiler.cfg.gvn in
math.simd.vectors.intrinsics and compiler.cfg.optimizer.

Extra things I can think of:
  - I needed to make a minor change to compiler.cfg.copy-prop due to the GVN
changes, so that'll be in there.
  - The reason I wrote the graphviz vocab was to facilitate the fun stuff in
https://github.com/ajvondrak/factor/blob/gvn/extra/compiler/cfg/graphviz
and 
https://github.com/ajvondrak/factor/tree/gvn/extra/compiler/cfg/gvn/testing
so I could include CFG diagrams in my thesis.
  - Just last night, I tried out a fresh 0.95 download's `load-all test-all`
(in ./factor -run=listener) on my x86_64, up-to-date Arch install (same
hardware as before).  Still crashed, but instead of getting out of memory
I got a memory protection fault from the gc.  I hope to be improving the
GVN pass some once I can get these errors figured out.  :-/  I notice
there's been an issue opened about load-all test-all running out of memory
(https://github.com/slavapestov/factor/issues/633); don't know if that's in
response to what I brought up or not.

So, I guess I kind of just went text dump mode there, but let me know if you
have any questions or if there's anything I can do to help.

Regards,
--Alex Vondrak


From: John Benediktsson [mrj...@gmail.com]
Sent: Sunday, September 09, 2012 6:58 PM
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Out of memory error

I'd love to help you work on merging your GVN patches, where did we leave it?

Best,
John.

On Sat, Aug 25, 2012 at 7:05 PM, Alexander J. Vondrak 
ajvond...@csupomona.edumailto:ajvond...@csupomona.edu wrote:
Good idea, but still no dice.

--Alex Vondrak

From: Doug Coleman [doug.cole...@gmail.commailto:doug.cole...@gmail.com]
Sent: Saturday, August 25, 2012 4:28 PM
To: factor-talk@lists.sourceforge.netmailto:factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Out of memory error

Are you running it in the shell listener? It might save memory.

./factor -run=listener

load-all test-all

Doug

On Sat, Aug 25, 2012 at 1:36 PM, Alexander J. Vondrak
ajvond...@csupomona.edumailto:ajvond...@csupomona.edu wrote:
 Just did a load-all test-all with 0.94, and that crashes, too.  I know that
 I've run those tests before without running out of memory, so I suspect it's
 either an OS update issue (who knows?) or how my setup is interacting with my
 new hardware (inherited some 64-bit hardware, still using my old 32-bit Debian
 install because I've been lazy about ditching it/upgrading/what-have-you).
 Don't know if that would make sense, per se, but hell, it's not the first
 problem I've had with my current OS setup.  If no one can reproduce, it's
 probably some combination of things on my end...

 I'll be trying the unit tests out again once I get Arch configured on another
 hard drive on this machine.

 Thanks for the feedback everyone,
 --Alex Vondrak

 
 From: John Benediktsson [mrj...@gmail.commailto:mrj...@gmail.com]
 Sent: Saturday, August 25, 2012 11:11 AM
 To: 
 factor-talk@lists.sourceforge.netmailto:factor-talk@lists.sourceforge.net
 Cc: 
 factor-talk@lists.sourceforge.netmailto:factor-talk@lists.sourceforge.net
 Subject: Re: [Factor-talk] Out of memory error

Re: [Factor-talk] Out of memory error

2012-09-09 Thread John Benediktsson

I'd love to help you work on merging your GVN patches, where did we leave
it?

Best,
John.

On Sat, Aug 25, 2012 at 7:05 PM, Alexander J. Vondrak 
ajvond...@csupomona.edu wrote:

 Good idea, but still no dice.

 --Alex Vondrak
 
 From: Doug Coleman [doug.cole...@gmail.com]
 Sent: Saturday, August 25, 2012 4:28 PM
 To: factor-talk@lists.sourceforge.net
 Subject: Re: [Factor-talk] Out of memory error

 Are you running it in the shell listener? It might save memory.

 ./factor -run=listener

 load-all test-all

 Doug

 On Sat, Aug 25, 2012 at 1:36 PM, Alexander J. Vondrak
 ajvond...@csupomona.edu wrote:
  Just did a load-all test-all with 0.94, and that crashes, too.  I know
 that
  I've run those tests before without running out of memory, so I suspect
 it's
  either an OS update issue (who knows?) or how my setup is interacting
 with my
  new hardware (inherited some 64-bit hardware, still using my old 32-bit
 Debian
  install because I've been lazy about ditching
 it/upgrading/what-have-you).
  Don't know if that would make sense, per se, but hell, it's not the first
  problem I've had with my current OS setup.  If no one can reproduce, it's
  probably some combination of things on my end...
 
  I'll be trying the unit tests out again once I get Arch configured on
 another
  hard drive on this machine.
 
  Thanks for the feedback everyone,
  --Alex Vondrak
 
  
  From: John Benediktsson [mrj...@gmail.com]
  Sent: Saturday, August 25, 2012 11:11 AM
  To: factor-talk@lists.sourceforge.net
  Cc: factor-talk@lists.sourceforge.net
  Subject: Re: [Factor-talk] Out of memory error
 
  If this is happening of 0.95 release than I wonder if we have a slow
 leak rather than corruption - all of our builders produce consistent clean
 builds (load-all test-all) and have for awhile.
 
  Perhaps we don't notice due to 16+ GB of RAM...?
 
 
  On Aug 25, 2012, at 11:06 AM, Joe Groff arc...@gmail.com wrote:
 
  On Sat, Aug 25, 2012 at 1:36 PM, Jim Mack j...@less2do.com wrote:
  In a way, too many possible culprits mask each other.
 
  I remember a problem like this that I solved by reducing the amount of
  memory so the problem would show quickly, then testing small things in
  isolation and volume.  Pick a subset of tests and run them multiple
 times at
  low memory until it fails or becomes clear it won't.   Rinse and
 repeat.
 
  An out of memory error could also be caused by things other than a
  lack of memory. If the heap is getting corrupted or there is a
  compiler bug, the system could end up passing a garbage size to malloc
  or mmap that is too big to be fulfilled.
 
  -Joe
 
 
 --
  Live Security Virtual Conference
  Exclusive live event will cover all the ways today's security and
  threat landscape has changed and how IT managers can respond.
 Discussions
  will include endpoint security, mobile security and the latest in
 malware
  threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
  ___
  Factor-talk mailing list
  Factor-talk@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/factor-talk
 
 
 --
  Live Security Virtual Conference
  Exclusive live event will cover all the ways today's security and
  threat landscape has changed and how IT managers can respond. Discussions
  will include endpoint security, mobile security and the latest in malware
  threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
  ___
  Factor-talk mailing list
  Factor-talk@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/factor-talk
 
 
 --
  Live Security Virtual Conference
  Exclusive live event will cover all the ways today's security and
  threat landscape has changed and how IT managers can respond. Discussions
  will include endpoint security, mobile security and the latest in malware
  threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
  ___
  Factor-talk mailing list
  Factor-talk@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/factor-talk


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Factor-talk mailing list
 Factor-talk@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/factor

Re: [Factor-talk] Out of memory error

2012-08-25 Thread Alexander J. Vondrak

Okay, so still no luck:

  - Tried skipping tools.deploy tests (just yanked deploy-tests.factor out of
the 0.95 source tree before `load-all test-all`), still crashed.

  - Tried skipping extra/ with `resouce:core load-root resource:basis
load-root test-all`, still crashed.

  - Tried doubling the sizes of the GC generations (./factor -young=2 -aging=4
-tenured=1600) to no avail.

  - No particular vocabulary seems to be tripping it off, as verified by doing
the above with 
```
\ run-test-file [
  [ dup ~/Desktop/tests utf8 [ print ] with-file-appender ] prepend
] annotate
```
and having them crash at different vocabs.  The few times I managed to
catch a glimpse of the factor process running in top, the memory usage just
seemed to creep up to its ceiling as more and more tests were run until it
finally aborted.

It didn't use to do this (even very recently), which is what made me think it
was something to do with my machine just being b0rked.  I've had weird bugs
crop up from time to time using Debian, so it's not unprecedented.  I've been
procrastinating setting up an Arch install on this machine, so maybe this is as
good a reason as any to get around to that...

Any other experiments I should try?

Thanks for the help,
--Alex Vondrak


From: John Benediktsson [mrj...@gmail.com]
Sent: Friday, August 24, 2012 6:54 PM
To: factor-talk@lists.sourceforge.net
Cc: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Out of memory error

It might be worth only loading and testing vocabularies in core and basis, to 
see if GVN works?

On Aug 24, 2012, at 6:50 PM, Alexander J. Vondrak ajvond...@csupomona.edu 
wrote:

 It seems to fail soon after the tools.deploy tests.  I tried at one point 
 disabling those, but I think it still crashed.  I should check again...

 
 From: Doug Coleman [doug.cole...@gmail.com]
 Sent: Friday, August 24, 2012 6:44 PM
 To: factor-talk@lists.sourceforge.net
 Subject: Re: [Factor-talk] Out of memory error

 8gb outta be enough for anybody. But It's not, I guess. Try with more RAM or 
 patch the part that grows to only grow to as much as you have.

 Maybe something is using way too much

 On Aug 24, 2012 6:01 PM, Alexander J. Vondrak 
 ajvond...@csupomona.edumailto:ajvond...@csupomona.edu wrote:
 Hey all,

 Mini-update: got the unit tests for the global value numbering pass more
 up-to-snuff awhile ago (it's like test-driven development in reverse!).  Still
 seems like I should be doing more to test the new capabilities, but I'm not
 sure if I could do much more than what's there.

 My efforts as of late have been focused on some GVN improvements.  But for the
 past way-too-long, I thought I had broken something catastrophic because
 `load-all test-all` would invariably crash the listener with an out of 
 memory
 error:

  Out of memory

  Nursery: Start=831c, size=10, end=832c
  Aging: Start=82fc, size=20, end=831c
  Tenured: Start=50c8, size=3214, end=82dc
  Cards:base=b44d0008, size=326800
  Aborted

 After a lot of very slow debugging (them's the breaks when running all the 
 unit
 tests, I guess) that was ultimately fruitless, I finally tried out Factor 0.95
 straight from the build farm---none of my changes, no .git, just a clean
 download of the linux-x86-32 tarchive.  And, what do you know, `load-all
 test-all` still crashes with the same error.

 It hadn't done that before, so I think the issue may be an intervening OS
 update I did.  I'm running a fully up-to-date Debian testing, kernel
 3.2.0-3-686-pae.

 1) Can anyone reproduce this error?  Or is my machine just that jacked up?  
 I'd
 be happy to provide other diagnostic info, if it'd help.

 2) Any coping mechanisms?  I considered just throwing a bunch of memory at it
 with command line switches (-young=, -aging=, -tenured=, etc.), but wasn't
 really sure how much would do the trick, since it just started crashing like
 this out of the blue anyway.

 Thanks,
 --Alex Vondrak
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Factor-talk mailing list
 Factor-talk@lists.sourceforge.netmailto:Factor-talk@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/factor-talk

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include

Re: [Factor-talk] Out of memory error

2012-08-25 Thread Jim Mack

In a way, too many possible culprits mask each other.

I remember a problem like this that I solved by reducing the amount of
memory so the problem would show quickly, then testing small things in
isolation and volume.  Pick a subset of tests and run them multiple times
at low memory until it fails or becomes clear it won't.   Rinse and repeat.



On Sat, Aug 25, 2012 at 10:19 AM, Alexander J. Vondrak 
ajvond...@csupomona.edu wrote:

 Okay, so still no luck:

   - Tried skipping tools.deploy tests (just yanked deploy-tests.factor out
 of
 the 0.95 source tree before `load-all test-all`), still crashed.

   - Tried skipping extra/ with `resouce:core load-root resource:basis
 load-root test-all`, still crashed.

   - Tried doubling the sizes of the GC generations (./factor -young=2
 -aging=4
 -tenured=1600) to no avail.

   - No particular vocabulary seems to be tripping it off, as verified by
 doing
 the above with
 ```
 \ run-test-file [
   [ dup ~/Desktop/tests utf8 [ print ] with-file-appender ] prepend
 ] annotate
 ```
 and having them crash at different vocabs.  The few times I managed to
 catch a glimpse of the factor process running in top, the memory usage
 just
 seemed to creep up to its ceiling as more and more tests were run
 until it
 finally aborted.

 It didn't use to do this (even very recently), which is what made me think
 it
 was something to do with my machine just being b0rked.  I've had weird bugs
 crop up from time to time using Debian, so it's not unprecedented.  I've
 been
 procrastinating setting up an Arch install on this machine, so maybe this
 is as
 good a reason as any to get around to that...

 Any other experiments I should try?

 Thanks for the help,
 --Alex Vondrak

 
 From: John Benediktsson [mrj...@gmail.com]
 Sent: Friday, August 24, 2012 6:54 PM
 To: factor-talk@lists.sourceforge.net
 Cc: factor-talk@lists.sourceforge.net
 Subject: Re: [Factor-talk] Out of memory error

 It might be worth only loading and testing vocabularies in core and basis,
 to see if GVN works?

 On Aug 24, 2012, at 6:50 PM, Alexander J. Vondrak 
 ajvond...@csupomona.edu wrote:

  It seems to fail soon after the tools.deploy tests.  I tried at one
 point disabling those, but I think it still crashed.  I should check
 again...
 
  
  From: Doug Coleman [doug.cole...@gmail.com]
  Sent: Friday, August 24, 2012 6:44 PM
  To: factor-talk@lists.sourceforge.net
  Subject: Re: [Factor-talk] Out of memory error
 
  8gb outta be enough for anybody. But It's not, I guess. Try with more
 RAM or patch the part that grows to only grow to as much as you have.
 
  Maybe something is using way too much
 
  On Aug 24, 2012 6:01 PM, Alexander J. Vondrak ajvond...@csupomona.edu
 mailto:ajvond...@csupomona.edu wrote:
  Hey all,
 
  Mini-update: got the unit tests for the global value numbering pass more
  up-to-snuff awhile ago (it's like test-driven development in reverse!).
  Still
  seems like I should be doing more to test the new capabilities, but I'm
 not
  sure if I could do much more than what's there.
 
  My efforts as of late have been focused on some GVN improvements.  But
 for the
  past way-too-long, I thought I had broken something catastrophic because
  `load-all test-all` would invariably crash the listener with an out of
 memory
  error:
 
   Out of memory
 
   Nursery: Start=831c, size=10, end=832c
   Aging: Start=82fc, size=20, end=831c
   Tenured: Start=50c8, size=3214, end=82dc
   Cards:base=b44d0008, size=326800
   Aborted
 
  After a lot of very slow debugging (them's the breaks when running all
 the unit
  tests, I guess) that was ultimately fruitless, I finally tried out
 Factor 0.95
  straight from the build farm---none of my changes, no .git, just a clean
  download of the linux-x86-32 tarchive.  And, what do you know, `load-all
  test-all` still crashes with the same error.
 
  It hadn't done that before, so I think the issue may be an intervening OS
  update I did.  I'm running a fully up-to-date Debian testing, kernel
  3.2.0-3-686-pae.
 
  1) Can anyone reproduce this error?  Or is my machine just that jacked
 up?  I'd
  be happy to provide other diagnostic info, if it'd help.
 
  2) Any coping mechanisms?  I considered just throwing a bunch of memory
 at it
  with command line switches (-young=, -aging=, -tenured=, etc.), but
 wasn't
  really sure how much would do the trick, since it just started crashing
 like
  this out of the blue anyway.
 
  Thanks,
  --Alex Vondrak
 
 --
  Live Security Virtual Conference
  Exclusive live event will cover all the ways today's security and
  threat landscape has changed and how IT managers can respond. Discussions
  will include endpoint security, mobile security and the latest in malware
  threats

Re: [Factor-talk] Out of memory error

2012-08-25 Thread Joe Groff

On Sat, Aug 25, 2012 at 1:36 PM, Jim Mack j...@less2do.com wrote:
 In a way, too many possible culprits mask each other.

 I remember a problem like this that I solved by reducing the amount of
 memory so the problem would show quickly, then testing small things in
 isolation and volume.  Pick a subset of tests and run them multiple times at
 low memory until it fails or becomes clear it won't.   Rinse and repeat.

An out of memory error could also be caused by things other than a
lack of memory. If the heap is getting corrupted or there is a
compiler bug, the system could end up passing a garbage size to malloc
or mmap that is too big to be fulfilled.

-Joe

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Out of memory error

2012-08-25 Thread John Benediktsson

If this is happening of 0.95 release than I wonder if we have a slow leak 
rather than corruption - all of our builders produce consistent clean builds 
(load-all test-all) and have for awhile.

Perhaps we don't notice due to 16+ GB of RAM...?


On Aug 25, 2012, at 11:06 AM, Joe Groff arc...@gmail.com wrote:

 On Sat, Aug 25, 2012 at 1:36 PM, Jim Mack j...@less2do.com wrote:
 In a way, too many possible culprits mask each other.
 
 I remember a problem like this that I solved by reducing the amount of
 memory so the problem would show quickly, then testing small things in
 isolation and volume.  Pick a subset of tests and run them multiple times at
 low memory until it fails or becomes clear it won't.   Rinse and repeat.
 
 An out of memory error could also be caused by things other than a
 lack of memory. If the heap is getting corrupted or there is a
 compiler bug, the system could end up passing a garbage size to malloc
 or mmap that is too big to be fulfilled.
 
 -Joe
 
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and 
 threat landscape has changed and how IT managers can respond. Discussions 
 will include endpoint security, mobile security and the latest in malware 
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Factor-talk mailing list
 Factor-talk@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/factor-talk

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Out of memory error

2012-08-25 Thread Alexander J. Vondrak

Just did a load-all test-all with 0.94, and that crashes, too.  I know that
I've run those tests before without running out of memory, so I suspect it's
either an OS update issue (who knows?) or how my setup is interacting with my
new hardware (inherited some 64-bit hardware, still using my old 32-bit Debian
install because I've been lazy about ditching it/upgrading/what-have-you).
Don't know if that would make sense, per se, but hell, it's not the first
problem I've had with my current OS setup.  If no one can reproduce, it's
probably some combination of things on my end...

I'll be trying the unit tests out again once I get Arch configured on another
hard drive on this machine.

Thanks for the feedback everyone,
--Alex Vondrak


From: John Benediktsson [mrj...@gmail.com]
Sent: Saturday, August 25, 2012 11:11 AM
To: factor-talk@lists.sourceforge.net
Cc: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Out of memory error

If this is happening of 0.95 release than I wonder if we have a slow leak 
rather than corruption - all of our builders produce consistent clean builds 
(load-all test-all) and have for awhile.

Perhaps we don't notice due to 16+ GB of RAM...?


On Aug 25, 2012, at 11:06 AM, Joe Groff arc...@gmail.com wrote:

 On Sat, Aug 25, 2012 at 1:36 PM, Jim Mack j...@less2do.com wrote:
 In a way, too many possible culprits mask each other.

 I remember a problem like this that I solved by reducing the amount of
 memory so the problem would show quickly, then testing small things in
 isolation and volume.  Pick a subset of tests and run them multiple times at
 low memory until it fails or becomes clear it won't.   Rinse and repeat.

 An out of memory error could also be caused by things other than a
 lack of memory. If the heap is getting corrupted or there is a
 compiler bug, the system could end up passing a garbage size to malloc
 or mmap that is too big to be fulfilled.

 -Joe

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Factor-talk mailing list
 Factor-talk@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/factor-talk

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Out of memory error

2012-08-25 Thread Doug Coleman

Are you running it in the shell listener? It might save memory.

./factor -run=listener

load-all test-all

Doug

On Sat, Aug 25, 2012 at 1:36 PM, Alexander J. Vondrak
ajvond...@csupomona.edu wrote:
 Just did a load-all test-all with 0.94, and that crashes, too.  I know that
 I've run those tests before without running out of memory, so I suspect it's
 either an OS update issue (who knows?) or how my setup is interacting with my
 new hardware (inherited some 64-bit hardware, still using my old 32-bit Debian
 install because I've been lazy about ditching it/upgrading/what-have-you).
 Don't know if that would make sense, per se, but hell, it's not the first
 problem I've had with my current OS setup.  If no one can reproduce, it's
 probably some combination of things on my end...

 I'll be trying the unit tests out again once I get Arch configured on another
 hard drive on this machine.

 Thanks for the feedback everyone,
 --Alex Vondrak

 
 From: John Benediktsson [mrj...@gmail.com]
 Sent: Saturday, August 25, 2012 11:11 AM
 To: factor-talk@lists.sourceforge.net
 Cc: factor-talk@lists.sourceforge.net
 Subject: Re: [Factor-talk] Out of memory error

 If this is happening of 0.95 release than I wonder if we have a slow leak 
 rather than corruption - all of our builders produce consistent clean builds 
 (load-all test-all) and have for awhile.

 Perhaps we don't notice due to 16+ GB of RAM...?


 On Aug 25, 2012, at 11:06 AM, Joe Groff arc...@gmail.com wrote:

 On Sat, Aug 25, 2012 at 1:36 PM, Jim Mack j...@less2do.com wrote:
 In a way, too many possible culprits mask each other.

 I remember a problem like this that I solved by reducing the amount of
 memory so the problem would show quickly, then testing small things in
 isolation and volume.  Pick a subset of tests and run them multiple times at
 low memory until it fails or becomes clear it won't.   Rinse and repeat.

 An out of memory error could also be caused by things other than a
 lack of memory. If the heap is getting corrupted or there is a
 compiler bug, the system could end up passing a garbage size to malloc
 or mmap that is too big to be fulfilled.

 -Joe

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Factor-talk mailing list
 Factor-talk@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/factor-talk

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Factor-talk mailing list
 Factor-talk@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/factor-talk

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Factor-talk mailing list
 Factor-talk@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/factor-talk

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Out of memory error

2012-08-24 Thread Doug Coleman

How much ram?
On Aug 24, 2012 6:01 PM, Alexander J. Vondrak ajvond...@csupomona.edu
wrote:

 Hey all,

 Mini-update: got the unit tests for the global value numbering pass more
 up-to-snuff awhile ago (it's like test-driven development in reverse!).
  Still
 seems like I should be doing more to test the new capabilities, but I'm not
 sure if I could do much more than what's there.

 My efforts as of late have been focused on some GVN improvements.  But for
 the
 past way-too-long, I thought I had broken something catastrophic because
 `load-all test-all` would invariably crash the listener with an out of
 memory
 error:

   Out of memory

   Nursery: Start=831c, size=10, end=832c
   Aging: Start=82fc, size=20, end=831c
   Tenured: Start=50c8, size=3214, end=82dc
   Cards:base=b44d0008, size=326800
   Aborted

 After a lot of very slow debugging (them's the breaks when running all the
 unit
 tests, I guess) that was ultimately fruitless, I finally tried out Factor
 0.95
 straight from the build farm---none of my changes, no .git, just a clean
 download of the linux-x86-32 tarchive.  And, what do you know, `load-all
 test-all` still crashes with the same error.

 It hadn't done that before, so I think the issue may be an intervening OS
 update I did.  I'm running a fully up-to-date Debian testing, kernel
 3.2.0-3-686-pae.

 1) Can anyone reproduce this error?  Or is my machine just that jacked up?
  I'd
 be happy to provide other diagnostic info, if it'd help.

 2) Any coping mechanisms?  I considered just throwing a bunch of memory at
 it
 with command line switches (-young=, -aging=, -tenured=, etc.), but wasn't
 really sure how much would do the trick, since it just started crashing
 like
 this out of the blue anyway.

 Thanks,
 --Alex Vondrak

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Factor-talk mailing list
 Factor-talk@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/factor-talk

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Out of memory error

2012-08-24 Thread Alexander J. Vondrak

8 GB.

From: Doug Coleman [doug.cole...@gmail.com]
Sent: Friday, August 24, 2012 6:06 PM
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Out of memory error

How much ram?

On Aug 24, 2012 6:01 PM, Alexander J. Vondrak 
ajvond...@csupomona.edumailto:ajvond...@csupomona.edu wrote:
Hey all,

Mini-update: got the unit tests for the global value numbering pass more
up-to-snuff awhile ago (it's like test-driven development in reverse!).  Still
seems like I should be doing more to test the new capabilities, but I'm not
sure if I could do much more than what's there.

My efforts as of late have been focused on some GVN improvements.  But for the
past way-too-long, I thought I had broken something catastrophic because
`load-all test-all` would invariably crash the listener with an out of memory
error:

  Out of memory

  Nursery: Start=831c, size=10, end=832c
  Aging: Start=82fc, size=20, end=831c
  Tenured: Start=50c8, size=3214, end=82dc
  Cards:base=b44d0008, size=326800
  Aborted

After a lot of very slow debugging (them's the breaks when running all the unit
tests, I guess) that was ultimately fruitless, I finally tried out Factor 0.95
straight from the build farm---none of my changes, no .git, just a clean
download of the linux-x86-32 tarchive.  And, what do you know, `load-all
test-all` still crashes with the same error.

It hadn't done that before, so I think the issue may be an intervening OS
update I did.  I'm running a fully up-to-date Debian testing, kernel
3.2.0-3-686-pae.

1) Can anyone reproduce this error?  Or is my machine just that jacked up?  I'd
be happy to provide other diagnostic info, if it'd help.

2) Any coping mechanisms?  I considered just throwing a bunch of memory at it
with command line switches (-young=, -aging=, -tenured=, etc.), but wasn't
really sure how much would do the trick, since it just started crashing like
this out of the blue anyway.

Thanks,
--Alex Vondrak
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.netmailto:Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Out of memory error

2012-08-24 Thread Doug Coleman

8gb outta be enough for anybody. But It's not, I guess. Try with more RAM
or patch the part that grows to only grow to as much as you have.

Maybe something is using way too much
On Aug 24, 2012 6:01 PM, Alexander J. Vondrak ajvond...@csupomona.edu
wrote:

 Hey all,

 Mini-update: got the unit tests for the global value numbering pass more
 up-to-snuff awhile ago (it's like test-driven development in reverse!).
  Still
 seems like I should be doing more to test the new capabilities, but I'm not
 sure if I could do much more than what's there.

 My efforts as of late have been focused on some GVN improvements.  But for
 the
 past way-too-long, I thought I had broken something catastrophic because
 `load-all test-all` would invariably crash the listener with an out of
 memory
 error:

   Out of memory

   Nursery: Start=831c, size=10, end=832c
   Aging: Start=82fc, size=20, end=831c
   Tenured: Start=50c8, size=3214, end=82dc
   Cards:base=b44d0008, size=326800
   Aborted

 After a lot of very slow debugging (them's the breaks when running all the
 unit
 tests, I guess) that was ultimately fruitless, I finally tried out Factor
 0.95
 straight from the build farm---none of my changes, no .git, just a clean
 download of the linux-x86-32 tarchive.  And, what do you know, `load-all
 test-all` still crashes with the same error.

 It hadn't done that before, so I think the issue may be an intervening OS
 update I did.  I'm running a fully up-to-date Debian testing, kernel
 3.2.0-3-686-pae.

 1) Can anyone reproduce this error?  Or is my machine just that jacked up?
  I'd
 be happy to provide other diagnostic info, if it'd help.

 2) Any coping mechanisms?  I considered just throwing a bunch of memory at
 it
 with command line switches (-young=, -aging=, -tenured=, etc.), but wasn't
 really sure how much would do the trick, since it just started crashing
 like
 this out of the blue anyway.

 Thanks,
 --Alex Vondrak

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Factor-talk mailing list
 Factor-talk@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/factor-talk

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Out of memory error

2012-08-24 Thread Alexander J. Vondrak

It seems to fail soon after the tools.deploy tests.  I tried at one point 
disabling those, but I think it still crashed.  I should check again...

From: Doug Coleman [doug.cole...@gmail.com]
Sent: Friday, August 24, 2012 6:44 PM
To: factor-talk@lists.sourceforge.net
Subject: Re: [Factor-talk] Out of memory error

8gb outta be enough for anybody. But It's not, I guess. Try with more RAM or 
patch the part that grows to only grow to as much as you have.

Maybe something is using way too much

On Aug 24, 2012 6:01 PM, Alexander J. Vondrak 
ajvond...@csupomona.edumailto:ajvond...@csupomona.edu wrote:
Hey all,

Mini-update: got the unit tests for the global value numbering pass more
up-to-snuff awhile ago (it's like test-driven development in reverse!).  Still
seems like I should be doing more to test the new capabilities, but I'm not
sure if I could do much more than what's there.

My efforts as of late have been focused on some GVN improvements.  But for the
past way-too-long, I thought I had broken something catastrophic because
`load-all test-all` would invariably crash the listener with an out of memory
error:

  Out of memory

  Nursery: Start=831c, size=10, end=832c
  Aging: Start=82fc, size=20, end=831c
  Tenured: Start=50c8, size=3214, end=82dc
  Cards:base=b44d0008, size=326800
  Aborted

After a lot of very slow debugging (them's the breaks when running all the unit
tests, I guess) that was ultimately fruitless, I finally tried out Factor 0.95
straight from the build farm---none of my changes, no .git, just a clean
download of the linux-x86-32 tarchive.  And, what do you know, `load-all
test-all` still crashes with the same error.

It hadn't done that before, so I think the issue may be an intervening OS
update I did.  I'm running a fully up-to-date Debian testing, kernel
3.2.0-3-686-pae.

1) Can anyone reproduce this error?  Or is my machine just that jacked up?  I'd
be happy to provide other diagnostic info, if it'd help.

2) Any coping mechanisms?  I considered just throwing a bunch of memory at it
with command line switches (-young=, -aging=, -tenured=, etc.), but wasn't
really sure how much would do the trick, since it just started crashing like
this out of the blue anyway.

Thanks,
--Alex Vondrak
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.netmailto:Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Out of memory error

2012-08-24 Thread John Benediktsson

It might be worth only loading and testing vocabularies in core and basis, to 
see if GVN works?

On Aug 24, 2012, at 6:50 PM, Alexander J. Vondrak ajvond...@csupomona.edu 
wrote:

 It seems to fail soon after the tools.deploy tests.  I tried at one point 
 disabling those, but I think it still crashed.  I should check again...
 
 
 From: Doug Coleman [doug.cole...@gmail.com]
 Sent: Friday, August 24, 2012 6:44 PM
 To: factor-talk@lists.sourceforge.net
 Subject: Re: [Factor-talk] Out of memory error
 
 8gb outta be enough for anybody. But It's not, I guess. Try with more RAM or 
 patch the part that grows to only grow to as much as you have.
 
 Maybe something is using way too much
 
 On Aug 24, 2012 6:01 PM, Alexander J. Vondrak 
 ajvond...@csupomona.edumailto:ajvond...@csupomona.edu wrote:
 Hey all,
 
 Mini-update: got the unit tests for the global value numbering pass more
 up-to-snuff awhile ago (it's like test-driven development in reverse!).  Still
 seems like I should be doing more to test the new capabilities, but I'm not
 sure if I could do much more than what's there.
 
 My efforts as of late have been focused on some GVN improvements.  But for the
 past way-too-long, I thought I had broken something catastrophic because
 `load-all test-all` would invariably crash the listener with an out of 
 memory
 error:
 
  Out of memory
 
  Nursery: Start=831c, size=10, end=832c
  Aging: Start=82fc, size=20, end=831c
  Tenured: Start=50c8, size=3214, end=82dc
  Cards:base=b44d0008, size=326800
  Aborted
 
 After a lot of very slow debugging (them's the breaks when running all the 
 unit
 tests, I guess) that was ultimately fruitless, I finally tried out Factor 0.95
 straight from the build farm---none of my changes, no .git, just a clean
 download of the linux-x86-32 tarchive.  And, what do you know, `load-all
 test-all` still crashes with the same error.
 
 It hadn't done that before, so I think the issue may be an intervening OS
 update I did.  I'm running a fully up-to-date Debian testing, kernel
 3.2.0-3-686-pae.
 
 1) Can anyone reproduce this error?  Or is my machine just that jacked up?  
 I'd
 be happy to provide other diagnostic info, if it'd help.
 
 2) Any coping mechanisms?  I considered just throwing a bunch of memory at it
 with command line switches (-young=, -aging=, -tenured=, etc.), but wasn't
 really sure how much would do the trick, since it just started crashing like
 this out of the blue anyway.
 
 Thanks,
 --Alex Vondrak
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Factor-talk mailing list
 Factor-talk@lists.sourceforge.netmailto:Factor-talk@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/factor-talk
 
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and 
 threat landscape has changed and how IT managers can respond. Discussions 
 will include endpoint security, mobile security and the latest in malware 
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Factor-talk mailing list
 Factor-talk@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/factor-talk

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Out Of Memory

Re: [Factor-talk] Out Of Memory

Re: [Factor-talk] Out Of Memory

Re: [Factor-talk] Out Of Memory

Re: [Factor-talk] Out of memory error

Re: [Factor-talk] Out of memory error

Re: [Factor-talk] Out of memory error

Re: [Factor-talk] Out of memory error

Re: [Factor-talk] Out of memory error

Re: [Factor-talk] Out of memory error

Re: [Factor-talk] Out of memory error

Re: [Factor-talk] Out of memory error

Re: [Factor-talk] Out of memory error

Re: [Factor-talk] Out of memory error

Re: [Factor-talk] Out of memory error

Re: [Factor-talk] Out of memory error

Re: [Factor-talk] Out of memory error

Re: [Factor-talk] Out of memory error

18 matches

Site Navigation

Mail list logo

Footer information