Please take into account that upstream is completely against applying
that patch:
https://github.com/plougher/squashfs-tools/issues/60
Hi Chris,
On Thu, Apr 4, 2019 at 1:04 PM Chris Lamb wrote:
> > We believe that the bug you reported is fixed in the latest version of
> > squashfs-tools, which is due to be installed in the Debian FTP archive.
> […]
> > squashfs-tools (1:4.3-12) unstable; urgency=medium
> > .
> > [ Alexander Co
Hi all,
> We believe that the bug you reported is fixed in the latest version of
> squashfs-tools, which is due to be installed in the Debian FTP archive.
[…]
> squashfs-tools (1:4.3-12) unstable; urgency=medium
> .
> [ Alexander Couzens ]
> * Fix compressor initialization in frag_deflator()
Hi lynxis,
On Mon, Mar 25, 2019 at 11:04 PM Alexander Couzens wrote:
> > I'm playing with the different patched versions for hours now.
> > Indeed, it seems with your latest patch the memory leak is bearable.
>
> Nice to hear. I compressed a 8GB tree of toolchains and rootfs with
> valgrind (too
Hi Laszlo,
> I'm playing with the different patched versions for hours now.
> Indeed, it seems with your latest patch the memory leak is bearable.
Nice to hear. I compressed a 8GB tree of toolchains and rootfs with
valgrind (took > 10h ;) without any noticable leaks.
> I've never tested CPU usa
On Mon, Mar 25, 2019 at 3:50 PM Alexander Couzens wrote:
> Here is an updated patch to match debian's state of squashfs-tools.
I'm playing with the different patched versions for hours now.
Indeed, it seems with your latest patch the memory leak is bearable.
I've never tested CPU usage before. I'
Dear lynxis,
> original, my patch had the problem, that it use the
> same stream (compressor context) as the main thread. This seems to be
> ok, as long the compression is not lzo (I tested with lzma).
>
> After your patch to fix lzo, the compressor will be initialized with a
> new context on ev
Hi László,
> Am I right that this isn't going to be fixed soon? I will remove this
> patch on Monday in the afternoon as the release of Buster is getting
> close.
Alas, I don't think I will be able to get to writing a patch/fix today
as I don't fully understand the leak (or, actually, the origi
> Laszlo, would you like any assistance with a debdiff or is lynxis'
> patch sufficient asis? You will have to patch the existing patch, if
> you see what I mean...
Here is an updated patch to match debian's state of squashfs-tools.
Best,
lynxis
Index: squashfs-tools-4.3/squashfs-tools/mksquashfs
mpressor_init's will leak, but since they are
only called once, it's not a big problem to leak some kbs.
I attached a patch to fix this to the bug #923711
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923711
It would be nice if you can test it.
Best,
lynxis
PS: If you like to write a
Can you please test the attached patch if it fixes the memory leakage?
> This is also the case why not all CPU cores are used during the run
> of mksquashfs.
This is a known bug/feature, as it removes one thread.
mksquashfs only scales the frad_thrd, deflator & removed frag_deflator
thread by th
Hi all,
On Mon, Mar 18, 2019 at 7:33 PM Chris Lamb wrote:
> Looks like a few other folks have hit this issue:
> https://redmine.tails.boum.org/code/issues/16457
>
This is also the case why not all CPU cores are used during the run of
mksquashfs.
Am I right that this isn't going to be fixed s
Control: severity -1 grave
Rationale: Also breaks building relatively small images on machines with
few real memory. Caused major trouble when upgrading a set of LTSP
machines that were running entirely smoothly before.
signature.asc
Description: PGP signature
The real culprit is only 0016-remove-frag_deflator_thread.patch
Dropping 0016-remove-frag_deflator_thread.patch and
0017-add-zstd-support.patch stops the memory leak
15 matches
Mail list logo
