On 6/8/2016 12:04 AM, Douglas R. Reno wrote:
On 6/7/2016 11:49 PM, Douglas R. Reno wrote:
On 6/7/2016 11:03 PM, Douglas R. Reno wrote:
Hello,

Can someone try running the gdk-pixbuf-2.34.0 test suite with all of the
dependencies (including optional) installed and report back here please?
I just ran it, and am afraid to continue using the system I ran it on.

I found that "CVE-2015-4491 1 /pixbuf/cve-2015-4491/original" caused a
memory leak, with 100% of my 4G of memory and 100% of my 8G swap taken
up by the process it spawned. I let it continue and it finished after
hanging the system for approximately 5 minutes and 15 seconds. Most of
the other tests ran slowly or hung afterwards as well, making the time
it took to run the tests somewhere in the neighborhood of 5 SBUs on this
system. The timer had stopped counting when cve-2015-4491/original had
run, so my system currently thinks it only took 876.9 seconds (3 SBUs),
but I know (based on a stopwatch) that it took nearly 45 minutes to
build. After the tests were finished running and the package was
installed, I have been unable to use any of my shells since.

Example:

"renodr [/sources ]$ echo '20160607 gdk-pixbuf-2.34.0' >>
/usr/src/package.lst"

bash: $'\302\211echo': command not foundpixbuf-2.34.0' >>
/usr/src/package.lst

Can someone run it and tell me if its just an issue with my system, or
if it is leaking/causing issues for everyone else? I'd like to know to
file a report upstream if needed.

On another system, 20160419-systemd, on an i5-2400 3.2GHz Quad-Core with
4G of DDR3 memory, it hits 58% memory during that round of tests and
breezes through it in seconds. What am I doing wrong? It doesn't have
any of these issues on the other system.

Still hangs over there... The process it spawns that takes up all the
memory is:

lt-cve-2015-4491

Can't get GDB to do anything when it has no memory to launch into. It
took nearly 3 minutes to open another XTerm. I had top open in another
window, however. I am still leaning towards this being an issue... the
other system, with 20160419-systemd, is extremely old. Lots of things
have changed since then.

As a follow-up, I have acquired a newer AMD system. I will try this out and see if I can reproduce it. I would like to know if it was just transient, or if I have a hardware problem on that system (either one is possible).

--
Douglas R. Reno
--LFS/BLFS systemd maintainer
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to