18 / 19
Jun 2017

Hi!

Hoes does online judge measure memory usage? I know CPU time can be measured on Linux with getrusage(2) or wait3(2), but these syscalls don't give me too much information about used memory. smile
I found that memory usage for a running process is written in /proc//status, but after the process terminates, i.e. becomes zombie, this is useless.

Thanks. smile

I played a little with GNU accounting tools and encountered a few problems. blush

    * I ran a simple Hello World program and sa reported that it used ~300k of memory. After I compiled the program with the -static flag it used ~100k. Looks too much to me. smile
    * I have to run the program at least twice so it's actually accounted (otherwise it's listed in "**other")
    * sa outputs the CPU time average memory usage. How to calculate the total average memory usage? Multiply it with the CPU time in milliseconds?
How are those problem dealt with at SPOJ?

Thanks in advance. wink

Well.. it's the C library; if you want to save some memory, write in asm or at least don't use glibc stuck_out_tongue
As you noticed, shared libraries are also counted, as well as the binary itself. In spoj, a C program which does nothing is reported to consume quite a lot of memory (glibc), while fpc programs don't (dyniamic linking doesn't work (?)).

Um.. I don't know what you mean.. AFAIK every process is guaranteed to be logged after it finishes (and its parent wait()s for it). And I don't know what "**other" is, maybe I haven't looked into "sa" enough.. I use "dump-acct" myself and in spoj we process pacct files on our own.

In spoj, we just output the average memory usage of the first process. If you want to measure maximum memory usage, polling /proc is the only thing I can think of.
I think average isn't that bad; and processes are guaranteed not to exceed fixed memory limit set by RLIMITs.

I've just sent a simple solution to the problem TEST and it used 1484k of memory. smile Are those actually kilobytes? dump-acct reports that it used 1320 on my computer, and sa reports 330k?!? What does 1320 actually represent? confused

I've taken a look at dump-acct, it's what I needed, though I still don't know what each field of it's output represents (no manpage for dump-acct). frowning

This average usage... Is it the number of (kilo)bytes of memory process allocated during some time, or is it the memory process accessed. For example, what happens with this measurement if a program has a big global array, i.e. doesn't use malloc and company?

As of RLIMITs, when RLIMIT_AS is exceeded, program receives SIGSEGV. How do you differentiate that program has exceeded the memory limit or it just access illegal part of memory (the unallocated part, for example). I'm a bit confused here. confused

Another thing. smile In chroot jail (in which programs are being run) do you have all the libraries and interpreters (for dynammicaly linked programs and the ones that use interpreters)? In this case, couldn't any program just do unlink(2) and mess everything up?! Do you copy input files to this jail or just use a FIFO or some similar trick. smile

Thanks for the answers. wink

All dynamic libraries it's linked with, program's code itself and all data and stack memory it allocates, AFAIK.
They are kilobytes, glibc is quite heavy. But then again, it's sure to be cached in RAM.

Well, if your distribution doesn't come with it, google for it..
Fields are: command, user time, system time, effective time, uid, gid, memory, io, time.

It's allocated memory, not accessed. I don't know how to measure accessed memory.

We don't stuck_out_tongue Right now, it's "RE (other)" in spoj.
We might start to detect it sometime, but I personally don't like to mess with ptrace() and we would detach after loading libraries and allocating memory anyway.

I don't get your point, on my systems, chroot() doesn't give any additional privileges and unlink()ing is at least as hard without proper privileges as without it.
And yes, we have separate chroot or two (chroots for compilers) for all languages.
Input and output files are passed though pipes.

Well, doesn't this affect RLIMIT_AS too? Or you increase the mem limit a megabyte more for glibc? smile

Well, maybe you could use the measured memory usage. If it's greater than the limit, then it's memory limit exceeded, otherwise it's just SIGSEGV. stuck_out_tongue I just don't know if that would work, because it's just an average memory usage.

Nevermind, my mistake. smile I forgot that you can drop the (root) privileges after you enter the chroot jail with setuid(2). blush

Of course it does! Memory limits never had been "strict" in spoj: RLIMIS_AS is set to 256MB (enough to keep JVM happy), 64MB of physical RAM is guaranteed for the program itself and that's it.
It might seem desperate, but I can't think of a "problem" where a set memory limit would really be necessary.
Such problem would have to be limited to few languages (C/C++/Pascal?), programs would have to be linked statically and even then, compiler's optimizer could break a program which seems to use little memory enough.
Note that online judges which compile statically and have ~3 languages to choose from don't have such problems :>

Memory usage of those SIGSEGVs isn't greater than the limit - it's really low instead. IMO, ptrace() would be more trustworty than comparing that value to observed memory consumption of SIGSEGVed program for a specific language.
With ptrace(), it would be enough to check what execve() returns.

My mistake. I haven't noticed that you don't set memory limits at all. smile Usually IOI-type programming contests limit memory too (both stack and heap).

I don't understand this. How could execve's return value help you determine if the program allocated more memory than allowed or it just accessed an illegal segment? confused

strace-ing execve() of a program which allocates more memory at the very start (from ELF headers, not in the code) gives:
execve("./a", ["./a"], [/* 23 vars */]) = -1 ENOMEM (Cannot allocate memory)
+++ killed by SIGKILL +++

That's the only time where allocating memory results is SIGSEGV, e.g. malloc-ing simply fails when reaching the limit. And it's nothing wrong to allocate as much memory as you can this way (large malloc, halve the amount you want if it fails etc).

Nice... I didn't know that. smile

Damn, why didn't I thought of that. wink

7 years later

We are left with using operating system specific APIs to determine memory usage. This is however, an advantage. We will be able to determine the complete overhead of an application, including memory not allocated through the C library. For example, when the process loads a shared library, the linker will use the mmap() system call directly. Similarly, the thread stacks in the pthread implementation will be directly mapped rather than malloced.

2 years later

Tak to ju偶 jest, z przechodzeniem, 偶e potem robi膮 si臋 z tego problemy po przej艣ciach.
Podstawowy problem polega tu na tym, 偶e powinien przebiega膰, a nie przechodzi膰. Jak dalej b臋dzie si臋 tak guzdra艂, to dla niepodstawowych b臋dzie du偶o za wolny, tak przynajmniej czuj臋 i mog臋 si臋 domy艣li膰 i wyobra藕i膰.

Jak Ci mog臋 jeszcze pom贸c?

Ewentualnie, jak Ty by艣 troch臋 m贸g艂 pom贸c, tym co Ci chcieliby ewentualnie pom贸c, w ten spos贸b, 偶eby艣 pom贸g艂 im, aby mogli lepiej zrozumie膰 jak Ci pom贸c, 偶eby艣 m贸g艂 lepiej pom贸c tym, kt贸rzy zechc膮 Ci pom贸c... chyba si臋 zap臋tli艂em w rekurencj臋.

Jak to zrobi膰? Gdzie艣 tam na forum le偶y taki jaki艣 poradnik.

Ok. rozumiem. Z tym, 偶e chwilowo nie chodzi mi o to aby ten program przebiega艂 przez testy tylko 偶eby je zrobi艂. Nie wyrzuca mi, 偶e przekroczy艂em limit czasu tylko, 偶e jest b艂臋dna odpowied藕. Tak po za tym w limicie czasu na razie si臋 mie艣ci, ma jeszcze zapas sekundy.

Chodzi mi o to, 偶e nie mog臋 znale藕膰 testu dla kt贸rego pojawia si臋 b艂臋dna odpowied藕. Kod jest napisany chyba do艣膰 przejrzy艣cie.

Z tego co widzia艂em na forum, wszyscy wrzucaj膮 tak kody, do tego kod chyba nie jest za d艂ugi.

Zadanie zaakceptowane, co prawda na razie dosy膰 s艂ab膮 metodyk膮 (cho膰 i tak skr贸cone o te warunki) ale zaraz sobie przerobi臋 偶eby dzia艂a艂o rekurencyjnie. Dzi臋ki wielkie za sugestie, w tym r贸wnie偶 to, 偶e funkcja pot臋gi jest zb臋dna oraz za te nie dotycz膮ce zadania. Na pewno to usprawni moj膮 komunikacje na forum.

2 years later
3 years later

Yes, links are broken. Could you restore that information please?