[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Problem with monotone 0.29

From: Detlef Vollmann
Subject: Re: [Monotone-devel] Problem with monotone 0.29
Date: Mon, 28 Aug 2006 05:39:01 +0200

Nathaniel Smith wrote:
> On Sat, Aug 26, 2006 at 11:42:12PM +0200, Detlef Vollmann wrote:
> > So it's no problem to build a static binary with glibc 2.3 and
> > run it on a system that uses 2.2 (which is what I do).
> No, really, this is wrong.  For instance, Ulrich Drepper (glibc head
> honcho) says:
>    all kinds of features in the libc (locale (through iconv), NSS,
>    IDN, ...) require dynamic linking to load the appropriate external
>    code. We have very limited support for doing this in statically
>    linked code.  But it requires that the dynamically loaded modules
>    available at runtime must come from the same glibc version as the
>    code linked into the application.
>      --
This is only true if some parts of the library used by monotone
use dynamic linking.
(And I don't agree with the general statement of that page:
there are lot's of systems around where dynamic linking is not
available, and they work fine anyway.  But that's offtopic here.

> We certainly use locale and iconv, and network operations need NSS
> (though I don't know why 'checkout' would).  If you're in the C
> locale, I don't know why it would need to dynamically load any
> libraries, either, but then, glibc does move in mysterious ways.  So
> I'd still worry about this as a possible factor... or maybe it's not
> relevant at all.
I'll do a check (with strace) if any SO is dlopened.

> ...very strange.  Either gdb is screwing up, or there is some sort of
> stack corruption going on here... unfortunately the former is more
> likely.  (But what's up with every number on the stack being 140706656
> (= 0x8630360)?  In the later backtraces, even the stack_end argument
> to __libc_start_main is printed with this value.)  In any case, it
> doesn't make the problem obvious, at least to me :-(.
I definitely can't comment to this.

> Does the memory usage of the process grow as it runs?
If so, then very slowly.  I'll check again.

> Another thought, that I should have thought of before... if you run
> mtn with --debug, does it stop printing things when it freezes?  If
> so, what is the last thing it prints?  If not, then what does it print
> while "frozen"?
It's actually not so easy to reproduce the problem now (it simply
works).  But I'll try again on Wednesday (I'll be out-of-office
Monday and Tuesday).


Detlef Vollmann   vollmann engineering gmbh
Linux and C++ for Embedded Systems
Linux for PXA270 Colibri module:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]