On Wed, Jul 3, 2019 at 8:34 AM Mark Wielaard wrote:
> Great. Thanks for testing on a real world binary.
> There aren't actually that many out there this big!
> Please do let me know if you still see issues (or discover others).
You are welcome. Thank you for fixing this issue in elfutils.
We wil
On Wed, 2019-07-03 at 08:23 -0700, Lei Zhang wrote:
> On Wed, Jul 3, 2019 at 7:53 AM Mark Wielaard wrote:
> > Thanks for the file, it is indeed pretty big :)
> > But I am not able to replicate the issue with elfutils from git
> > trunk.
> > commit 31c8b3f098b0654db8f573b2a15d5b6d07d4d3b0
> >
> >
On Wed, Jul 3, 2019 at 7:53 AM Mark Wielaard wrote:
> Thanks for the file, it is indeed pretty big :)
> But I am not able to replicate the issue with elfutils from git trunk.
> commit 31c8b3f098b0654db8f573b2a15d5b6d07d4d3b0
>
> And both the produced chrome_elfutil_test.stripped and
> chrome_elfut
Hi,
On Tue, 2019-07-02 at 16:21 -0700, Lei Zhang wrote:
> On Tue, Jul 2, 2019 at 4:15 PM Mark Wielaard wrote:
> > I'll try to create a testcase to replicate the issue to see if I can
> > debug where the offset value gets truncated.
>
> Sounds good to me.
>
> > Or do you happen to have the 5.4 G
On Tue, Jul 2, 2019 at 4:15 PM Mark Wielaard wrote:
> I'll try to create a testcase to replicate the issue to see if I can
> debug where the offset value gets truncated.
Sounds good to me.
> Or do you happen to have the 5.4 GB binary named "chrome" create before
> splitting still around somewher
Hi,
On Tue, 2019-07-02 at 11:40 -0700, Lei Zhang wrote:
> I tested and found some problems. My test procedure is to:
> - Build elfutils at commit 31c8b3f098b0654db8f573b2a15d5b6d07d4d3b0
> - Replace Chromium's buildtools/third_party/eu-strip/bin/eu-strip with
> the newly built strip binary.
> - Do
On Tue, Jun 18, 2019 at 5:04 PM Mark Wielaard wrote:
> My apologies if you tried to upstream this and I missed it. But I think
> the patch below is a more complete fix. If you could test it in your
> setup that would be great.
Hi Mark,
I'm not sure if we tried to upstream the patch. So no worrie
Hi,
I pushed this to master with the changes suggested by Dmitry.
Thanks,
Mark
On Thu, 2019-06-20 at 04:54 +0300, Dmitry V. Levin wrote:
> On Thu, Jun 20, 2019 at 01:10:53AM +0200, Mark Wielaard wrote:
> > +# Make sure the disk is reasonably fast, should be able to write
> > 100MB/s
> > +fast_disk=1
> > +timeout -s9 10s dd conv=fsync if=/dev/urandom of=tempfile bs=1M
> > coun
On Thu, Jun 20, 2019 at 01:10:53AM +0200, Mark Wielaard wrote:
> On Wed, 2019-06-19 at 02:04 +0200, Mark Wielaard wrote:
> > The patch also contains a testcase. But since it is necessary to create
> > and process a 4GB+ file it is guarded by some checks to make sure the
> > machine has enough disk
On Wed, 2019-06-19 at 02:04 +0200, Mark Wielaard wrote:
> The patch also contains a testcase. But since it is necessary to create
> and process a 4GB+ file it is guarded by some checks to make sure the
> machine has enough disk and memory. Do these checks look reasonable?
> They probably prevent (m
Hi,
I saw some curious crashes and broken ELF files in the Fedora builder
for really big packages (e.g. Qt5). It turned out that when libelf tries
to update or write out a 4GB+ files it used some 32bit offsets/types
where it should have been using 64bit offsets/types.
While searching for the bad
12 matches
Mail list logo
