On Fri, Dec 17, 2010 at 3:03 AM, Ketil Malde wrote:
>
> So I still think the 80% rule is pretty good - it's simple, and
> although it isn't optimal in all cases, it's conservative in that any
> larger bound is almost certainly going to thrash.
Did you get a chance to test the 80% rule? Was I rig
On Thu, Dec 16, 2010 at 4:13 AM, Simon Marlow wrote:
>
> If your program has large memory requirements, you might also benefit from
> parallel GC in the old generation: +RTS -N2 -qg1.l
Testing shows this advice did not help in my case. The program that
implements the undecidable algorithm in my
On Fri, Dec 17, 2010 at 3:03 AM, Ketil Malde wrote:
>
> So I still think the 80% rule is pretty good - it's simple, and
> although it isn't optimal in all cases, it's conservative in that any
> larger bound is almost certainly going to thrash.
Please test the 80% rule, and report the results of y
You might like to read about free and reclaimable memory on Linux
systems. I recommend that you go
http://linuxdevcenter.com/pub/a/linux/2006/11/30/linux-out-of-memory.html
and run the C programs that are included in the article. Another good
way to learn about Linux memory is to Google with the
"John D. Ramsdell" writes:
>> In absence of any explicit limits, I think a sensible default is to set
>> maximum total memory use to something like 80%-90% of physical RAM.
> This would be a poor choice on Linux systems. As I've argued
> previously in this thread, the best choice is to limit th
On Thu, Dec 16, 2010 at 4:45 AM, Ketil Malde wrote:
>
> In absence of any explicit limits, I think a sensible default is to set
> maximum total memory use to something like 80%-90% of physical RAM.
This would be a poor choice on Linux systems. As I've argued
previously in this thread, the best c
Simon Marlow writes:
> ulimit is a good way to catch an infinite loop. But it's not a good
> way to tell GHC how much memory you want to use - if GHC knows the
> memory limit, then it can make much more intelligent decisions about
> how to manage memory.
I'm interpreting this to mean that GHC
On 16/12/2010 00:37, John D. Ramsdell wrote:
On Wed, Dec 15, 2010 at 7:59 AM, Simon Marlow wrote:
The -M flag causes the GC algorithm to switch from copying (fast but
hungry) to compaction (slow but frugal) as the limit approaches.
Ah, so that's what it's doing. My measurements say that p
On Wed, Dec 15, 2010 at 7:59 AM, Simon Marlow wrote:
>
> The -M flag causes the GC algorithm to switch from copying (fast but
> hungry) to compaction (slow but frugal) as the limit approaches.
Ah, so that's what it's doing. My measurements say that part of the
code is working well. Of course,
Hi John,
> I think the previous responder was asserting the 32M limit, not you.
I believe the previous poster suggested that you use ulimit to provide a
hard upper bound for run-time memory use. That 32M figure seemed to be made
up out of thin air just as an example to illustrate the syntax of t
On 13/12/2010 15:45, Peter Simons wrote:
Hi Mathieu,
> Why don't you use ulimit for this job?
>
> $ ulimit -m 32M; ./cpsa
yes, I was thinking the same thing. Relying exclusively on GHC's ability to
limit run-time memory consumption feels like an odd choice for this task.
It's nice that
On Tue, Dec 14, 2010 at 1:48 PM, Peter Simons wrote:
>
> I beg your pardon? I didn't say anything about "32M". I said that
> designing software to rely on a GHC-enforced memory limit as a means of
> "dealing" with infinite loops feels really not like a particularly good
> solution.
Sorry about th
Hi Peter
> I beg your pardon? I didn't say anything about "32M". I said that
> designing software to rely on a GHC-enforced memory limit as a means of
> "dealing" with infinite loops feels really not like a particularly good
> solution.
As I understand the discussion, it's not about infinite l
Hi John,
> On Mon, Dec 13, 2010 at 10:45 AM, Peter Simons wrote:
>
>> Relying exclusively on GHC's ability to limit run-time memory
>> consumption feels like an odd choice for this task. It's nice that
>> this feature exists in GHC, but it's inherently non-portable and
>> outside of the sco
On Mon, Dec 13, 2010 at 10:45 AM, Peter Simons wrote:
> Hi Mathieu,
>
> ... There really ought to be a better way to catch an infinite loop that this.
It all comes down to picking the correct memory limit. How do you
propose to do it? How did you come up with the number 32M? That
number would
On Mon, Dec 13, 2010 at 10:17 AM, Mathieu Boespflug wrote:
> Hi John,
>
> Why don't you use ulimit for this job?
By default, the GHC runtime will allocate memory beyond what it takes
for takes to cause thrashing on a Linux box. However, if you give the
GHC runtime a limit with the -M option, and
Hi Mathieu,
> Why don't you use ulimit for this job?
>
> $ ulimit -m 32M; ./cpsa
yes, I was thinking the same thing. Relying exclusively on GHC's ability to
limit run-time memory consumption feels like an odd choice for this task.
It's nice that this feature exists in GHC, but it's inherently
Hi John,
Why don't you use ulimit for this job?
$ ulimit -m 32M; ./cpsa
Regards,
Mathieu
On Fri, Dec 10, 2010 at 12:51 PM, John D. Ramsdell wrote:
> Please excuse the grammar errors in my last post. I was very tired.
> The name of the package that supplies the free function on Linux is
> pr
Please excuse the grammar errors in my last post. I was very tired.
The name of the package that supplies the free function on Linux is
procps, not procpc. It's hosted on SourceForge. To compile my
program, do the following:
$ mv memfree.txt memfree.l
$ make LDLIBS=-ll memfree
John
On Thu, De
I found out how to compute a good memory limit for the GHC runtime on
Linux systems. One opens /proc/meminfo, and sums the free memory with
the reclaimable memory. The memory allocated to file buffers and the
disk cache are reclaimable, and can be added to the memory of a
growing GHC process. On
On 09/12/2010 12:48 PM, Simon Marlow wrote:
On 08/12/2010 16:34, Andrew Coppin wrote:
It appears that with GHC 7, you can just say something like
|-with-rtsopts="-H128m -K1m"| while compiling your program, and now that
will forever be the default RTS settings for your program.
Nice! I didn't no
On 08/12/2010 16:34, Andrew Coppin wrote:
On 08/12/2010 03:29 PM, Brandon S Allbery KF8NH wrote:
Then build your CGIs restricted. Restricting the runtime by default,
*especially* when setting runtime options at compile time is so much of a
pain, is just going to cause problems. I'm already thi
On 11/29/2010 03:00 PM, John D. Ramsdell wrote:
only one other solution. Somehow the default behavior of the runtime
system must impose some reasonable limit. Here is the problem with
Shouldn't you configure your operating system to impose some reasonable
limit? That's not the job of the pr
On Wed, 8 Dec 2010, Brandon S Allbery KF8NH wrote:
> Then build your CGIs restricted. Restricting the runtime by default,
> *especially* when setting runtime options at compile time is so much of
> a pain, is just going to cause problems. I'm already thinking that I
> may have to skip ghc7.
O
On 08/12/2010 03:29 PM, Brandon S Allbery KF8NH wrote:
Then build your CGIs restricted. Restricting the runtime by default,
*especially* when setting runtime options at compile time is so much of a
pain, is just going to cause problems. I'm already thinking that I may have
to skip ghc7.
With
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/8/10 02:17 , Anders Kaseorg wrote:
> On Sat, 2010-12-04 at 13:42 -0500, Brandon S Allbery KF8NH wrote:
>> We went over this some time back; the GHC runtime is wrong here, it
>> should only disable flags when running with geteuid() == 0.
>
> No.
On Sat, 2010-12-04 at 13:42 -0500, Brandon S Allbery KF8NH wrote:
> We went over this some time back; the GHC runtime is wrong here, it
> should only disable flags when running with geteuid() == 0.
No. +RTS flags on the command line, at least, need to stay disabled in
all cases, not just setuid b
I forgot to say what performance I got out of the new version of the
compiler on my application. I turns out a standard benchmark ran ever
so slightly slower after being compiled by 7.0.1 as compared with
6.12.1. Nothing exciting to report here.
John
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/4/10 14:35 , Riad S. Wahby wrote:
> "Edward Z. Yang" wrote:
>> There are many setuid binaries to non-root users, so getuid() != geteuid()
>> would probably make more sense, though I'm not 100% it has all the correct
>> security properties.
>
>
"Edward Z. Yang" wrote:
> There are many setuid binaries to non-root users, so getuid() != geteuid()
> would probably make more sense, though I'm not 100% it has all the correct
> security properties.
Might as well throw in getegid() != getgid() for good measure.
Another issue with this: in the
Excerpts from Brandon S Allbery KF8NH's message of Sat Dec 04 13:42:48 -0500
2010:
> We went over this some time back; the GHC runtime is wrong here, it should
> only disable flags when running with geteuid() == 0. Also, the current
> mechanism for specifying runtime flags at compile time is horr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/24/10 20:59 , John D. Ramsdell wrote:
> Due to a security concern, GHC 7.0.1 disables all runtime flags unless
> a new flag is provided during linking. Since limiting memory usage is
> so important, many developers will modify their cabal files
On Tue, Nov 30, 2010 at 9:24 AM, Ryan Ingram wrote:
> On Mon, Nov 29, 2010 at 12:36 AM, Simon Peyton-Jones
> wrote:
>> Do you have an alternative to suggest? After all, the previous situation
>> wasn't good either.
>
> I suggest that we should be able to specify RTS options at
> compile/link ti
2010/11/30 Ryan Ingram
> On Mon, Nov 29, 2010 at 12:36 AM, Simon Peyton-Jones
> wrote:
> > Do you have an alternative to suggest? After all, the previous situation
> wasn't good either.
>
> I suggest that we should be able to specify RTS options at
> compile/link time, or as pragmas in the Main
Quoth Ryan Ingram ,
> I suggest that we should be able to specify RTS options at
> compile/link time, or as pragmas in the Main module.
It would be good for me in any case if I could specify the value of
an option at compile time, though I suppose you mean to specify which
options may be specifie
On Tue, Nov 30, 2010 at 9:24 AM, Ryan Ingram wrote:
>
> I suggest that we should be able to specify RTS options at
> compile/link time, or as pragmas in the Main module.
So if I wrote a really good, stable Haskell program, and made it
available in binary form, people ten years from now would not
On Mon, Nov 29, 2010 at 12:36 AM, Simon Peyton-Jones
wrote:
> Do you have an alternative to suggest? After all, the previous situation
> wasn't good either.
I suggest that we should be able to specify RTS options at
compile/link time, or as pragmas in the Main module.
-- ryan
___
On Mon, Nov 29, 2010 at 3:36 AM, Simon Peyton-Jones
wrote:
> | The irony of this situation is deep. CPSA is a program that analyzes
> | cryptographic protocols in an effort to expose security flaws. To
> | ensure that the program does not crash a user's machine, I have to use
> | a linker option
| The irony of this situation is deep. CPSA is a program that analyzes
| cryptographic protocols in an effort to expose security flaws. To
| ensure that the program does not crash a user's machine, I have to use
| a linker option that may expose the user to some security problems.
Do you have an
"Edward Z. Yang" writes:
> Arguably the correct thing to do is to use GHC's hooks for
> programatically specifying runtime options; unfortunately, because
> this has to run /before/ any Haskell code starts, it's a bit
> unwieldly
Maybe what's needed is a way to allow certain RTS options to trick
On Thu, Nov 25, 2010 at 6:07 AM, Nils Anders Danielsson
wrote:
> Is CPSA intended to be run by untrusted users (for instance with the
> setuid bit set)?
>
> http://hackage.haskell.org/trac/ghc/ticket/3910
> http://www.amateurtopologist.com/2010/04/23/security-vulnerability-in-haskell-with-cgi/
A
Hello John,
Arguably the correct thing to do is to use GHC's hooks for
programatically specifying runtime options; unfortunately, because
this has to run /before/ any Haskell code starts, it's a bit
unwieldly: essentially you'll need a C stub file that scribbles
the correct options into char *ghc_
On 2010-11-25 01:59, John D. Ramsdell wrote:
The irony of this situation is deep. CPSA is a program that analyzes
cryptographic protocols in an effort to expose security flaws. To
ensure that the program does not crash a user's machine, I have to use
a linker option that may expose the user to
A quick review of GHC 7.0.1 revealed two challenges for developers.
I downloaded the GHC 7.0.1 sources, configured for a home directory
install, and built and installed the compiler. Very close to the end,
my machine froze, perhaps due to memory exhaustion. In any event, a
reboot allowed me to c
44 matches
Mail list logo
