The following pull request was merged into master in relation to this
bug https://github.com/snapcore/snapd/pull/6706
I'm marking it as patch was released since.
** Also affects: snapd
Importance: Undecided
Status: New
** Changed in: snapd
Status: New => Fix Released
**
On Tue, Apr 09, 2019 at 07:58:20AM -, Maciej Borzecki wrote:
> Proposed tenative fix in snapd is to disable PIE builds. Relevant PR:
> https://github.com/snapcore/snapd/pull/6700
I dislike this change.
While ASLR is not particularly strong on 32 bit platforms, it is
significantly more useful
When investigating on the affected 32bit ARM system, we have observed
that Go runtime would make a request to allocate system memory for it's
arena allocator, using a size that was questionable. Even most trivial
binary would request 150MB, using mmap(.., PROT_READ|PROT_WRITE,
Proposed tenative fix in snapd is to disable PIE builds. Relevant PR:
https://github.com/snapcore/snapd/pull/6700
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1822738
Title:
memleak in 2.38+ ?
To
** Changed in: snapd (Ubuntu)
Status: Confirmed => In Progress
** Changed in: snapd (Ubuntu)
Importance: Undecided => Critical
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1822738
Title:
I've looked as some /proc/meminfo dumps I was provided with.
Dump were made at these time points:
1. after boot
2. successful core refresh from 2.38 to 2.37.4
3. successful core refresh from 2.37.4 to 2.38
4. failed refresh of other snap, failed when mounting the snap with: fork/exec
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: snapd (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1822738
Title:
What architecture are they seeing the OOMs on?
Have they enabled swap?
What's the output of `free`?
taw
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1822738
Title:
memleak in 2.38+ ?
To manage
you probably want 2.38 and not current master because master now puts
things in timings as well
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1822738
Title:
memleak in 2.38+ ?
To manage
Repeated the same with 2.37:
$ ps -C snapd -ocmd,rsz,vsz,pid
CMD RSZVSZ PID
/usr/lib/snapd/snapd17940 2630004 31818
After 23 loops, RSS was 20532. After pruning, took 20 iterations to
start growing again.
Feels like we should hook up proper tracing
The binaries themselves are quite large. Using current master
(a057a16c6), and go 1.11.5, snapd is ~20MB, snap is ~15MB in size. I
think it's fair to assume that whenever snapd or snap runs, most of it
ends up in the memory. So calling 'snap refresh' would take up (worst
case) 35MB to start with.
Another idea if we suspect go1.10 changes, is to try repeated refreshes
with forced prune in between
with snapd compiled with 1.6 , 1.10 and 1.12 perhapse ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The other option is to try the same with a recompiled snapd from 2.37
(if the issue is in our own code)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1822738
Title:
memleak in 2.38+ ?
To manage
This is a good idea from John:
http://paste.ubuntu.com/p/yZkPWJ3FmH/
might also be 0,0,1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1822738
Title:
memleak in 2.38+ ?
To manage notifications
** Description changed:
We might have a memleak in snapd 2.38+ on install - this could be
related to the move from go-1.6 to go-1.10. This was reported by a
customer. The data points we have so far:
- happens on refresh for the customer
- on systems with low amounts of memory (256M)
We need to factor that we keep changes around until pruning, not saying
there's no leak but that we need to take that into account when
searching for it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
16 matches
Mail list logo
