All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: Frank de Lange <frank@unternet.org>, linux-kernel@vger.kernel.org
Cc: reiser@namesys.com
Subject: Re: reiserfs on 2.4.1,2.4.2-pre (with null bytes patch) breaks mozilla compile
Date: Sat, 17 Feb 2001 19:16:59 -0500	[thread overview]
Message-ID: <1217040000.982455419@tiny> (raw)
In-Reply-To: <20010217172118.A5737@unternet.org>



On Saturday, February 17, 2001 05:21:18 PM +0100 Frank de Lange
<frank@unternet.org> wrote:

> Hi'all,
> 
> Well, subject says it all... When I try to compile mozilla (CVS version)
> with the '--enable-elf-dynstr-gc' option, the compile fails with a
> segfault:
> 
> ../../dist/bin/elf-dynstr-gc ../../dist/lib/components/libsample.so
> make[2]: *** [install] Segmentation fault (core dumped)
> 

That's not good.  Which compiler did you use to compile the kernel?  This
sounds lame, but reiserfs exercises the cpu/mem more than ext2, so we hit
bad ram more often.  If we run out of other things to try, please run a
memory tester.

> compiling the same codebase on an ext2 filesystem does not produce this
> segfault. When I compare the produced library (libsample.so), there is a
> consistent difference between the one compile on the reiserfs and the ext2
> filesystem. Running objdump on the reiserfs-compiled library also produces
> errors (some assertion failures, a lot of 'invalid string offset' errors,
> and finally a 'Memory exhausted' error), while objdump happily
> disassebles the ext-produced binary.
> 

Where in the libsample.so file are the differences (what byte offset?).
Are they restricted to a given range, or do they vary randomly?

> These problems occur on:
> 
>  2.4.1
>  2.4.2-pre4
>  2.4.2-pre4 with Chris Mason's 'reiserfs fix for null bytes in small
>  files'
> 
At least the patch didn't make it worse.  Would anyone care to comment on
how the elf-dynstr-gc option changes the file access patterns for the
compile?

thanks,
Chris

  reply	other threads:[~2001-02-18  0:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-17 16:21 reiserfs on 2.4.1,2.4.2-pre (with null bytes patch) breaks mozilla compile Frank de Lange
2001-02-18  0:16 ` Chris Mason [this message]
2001-02-18  1:47   ` David
2001-02-18  2:07     ` Frank de Lange
2001-02-18  2:18       ` David
2001-02-19 17:40         ` Frank de Lange
2001-02-18 17:10       ` Chris Mason
  -- strict thread matches above, loose matches on Subject: below --
2001-02-18  0:57 Frank de Lange
2001-02-18  1:10 ` Frank de Lange
2001-02-18 16:42   ` Chris Mason
2001-02-18  1:15 ` Frank de Lange
2001-02-18 17:47 Frank de Lange

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1217040000.982455419@tiny \
    --to=mason@suse.com \
    --cc=frank@unternet.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiser@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.