Hello Michal.
I believe it's a serious problem, as an unprivileged user-space
application can basically render the system completely unusable, so
that it must be hard-rebooted.
I'll try to answer your points below...
On mar, 2016-01-05 at 16:54 +0100, Michal Hocko wrote:
> On Tue 29-12-15 18:03:02, Guido Trentalancia wrote:
> > Hello.
> >
> > I am getting an unrecoverable Out Of Memory error on kernel 4.3.1,
> > while compiling Firefox 43.0.3. The system becomes unresponsive,
> > the
> > hard-disk is continuously busy and a hard-reboot must be forced.
> >
> > Here is the report from the kernel:
> [...]
> > Dec 29 12:28:25 vortex kernel: Mem-Info:
> > Dec 29 12:28:25 vortex kernel: active_anon:716916
> > inactive_anon:199483 isolated_anon:0
> > Dec 29 12:28:25 vortex kernel: active_file:3108 inactive_file:3160
> > isolated_file:32
> > Dec 29 12:28:25 vortex kernel: unevictable:4316 dirty:3173
> > writeback:55 unstable:0
> > Dec 29 12:28:25 vortex kernel: slab_reclaimable:16548
> > slab_unreclaimable:9058
> > Dec 29 12:28:25 vortex kernel: mapped:4037 shmem:13351
> > pagetables:6846 bounce:0
> > Dec 29 12:28:25 vortex kernel: free:7058 free_pcp:295 free_cma:0
> [...]
> > Dec 29 12:28:25 vortex kernel: Free swap = 0kB
> > Dec 29 12:28:25 vortex kernel: Total swap = 16380kB
>
> Your swap space is full and basically all the memory is eaten by the
> anonymous memory which cannot be reclaimed.
> [...]
> > Dec 29 12:28:25 vortex kernel: Killed process 10197 (cc1plus)
> > total-vm:969632kB, anon-rss:809184kB, file-rss:9308kB
>
> This task is consuming a lot of memory so killing it should help to
> release the memory pressure. It would be interesting to see whether
> the
> task has died or not.
I am not able to login into any console and therefore I cannot check
whether the gcc task died or not.
> Are there any follow up messages in the log?
The first message have been posted entirely. Such message is then
repeated several times (for the "cc1plus" task and once for the "as"
assembler). The other messages are similar and therefore have not been
posted...
It only appears to happen with parallel builds ("make -j4") and not
with normal builds ("make" or "make -j1"), but that's another issue, I
mean a user-space application should not be able to render the system
unusable by sucking all of its memory...
Is the hard-disk working continuosly because the kernel is trying to
swap endlessly and cannot reclaim back memory ?!?
> Maybe the target task is stuck behind some lock which is blocked
> because
> of a memory allocation. We have seen deadlocks like that in the past.
> The current linux-next has some measures to reduce the probability of
> such a deadlock so you might give it a try. Especially if this is
> reproducible.
It's probably possible to reproduce it on my system by launching a
parallel build "make -j4" of the firefox 43.0.3.
Gcc is version 5.3.0, glibc is version 2.22. If the same versions of
gcc, glibc and firefox are installed on another system, it might or
might not be possible to reproduce it, I have not checked...
Guido
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>