Re: [Monotone-devel] Problem with monotone 0.29

[Nathaniel Smith]

On Sat, Aug 26, 2006 at 11:42:12PM +0200, Detlef Vollmann wrote:
> Nathaniel Smith wrote:
> > Right... it isn't possible to create real static binaries with glibc
> > :-(.
> Actually, that is not really a problem.  You can build static
> binaries, and I do it for my server.
> That is, they do not need any dynamic libraries for running.
> But it is true that they need some infrastructure from glibc:
> config files for name resolution, timezone, locales, and I think
> there are more.
> But this infrastructure is pretty stable: AFAIK there wasn't
> any change for this in the glibc-2 line.
> 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.
     -- http://people.redhat.com/drepper/no_static_linking.html

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.

> > (You might also try
> >   http://venge.net/monotone/downloads/mtn-0.29-linux-x86.bz2
> > anyway... I'm not sure the binary currently there _is_ compiled with
> > glibc 2.3, that might be a lie as well :-).  It definitely is
> > statically linked to libstdc++, though, so that shouldn't be an
> > issue.)
> But it's not a static binary and requires /lib/libc-2.3.so,
> which doesn't exist on my server.

The ldd output for me just says
        linux-gate.so.1 =>  (0xffffe000)
        libm.so.6 => /lib/tls/libm.so.6 (0xb7fa2000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7e6a000)
        /lib/ld-linux.so.2 (0x80000000)
It might still require 2.3, though; it was just a thought :-).

> > Uh... yeah.  A non-stripped build would be helpful; I'm not sure how
> > else we're going to figure out what's going on here :-).
> Ok, I built a non-stripped binary again and tried it again.
> It was actually harder to reproduce the error with the non-stripped
> binary than with the stripped binary...
> 
> When it ran off (on the fourth try), I attached gdb, printed
> the stack, continued, interrupted, printed stack again, twice.
> Here is the output:
> =========================================================================
> Attaching to program: /usr/local/bin/mtn, process 13565
> [New Thread 16384 (LWP 13565)]
> [Switching to Thread 16384 (LWP 13565)]
> 0x08468605 in _int_malloc (av=0x8630360, bytes=150847728) at malloc.c:3849
> 3849    malloc.c: No such file or directory.
>         in malloc.c
> (gdb) bt
> #0  0x08468605 in _int_malloc (av=0x8630360, bytes=150847728) at malloc.c:3849
> #1  0x08467889 in __libc_malloc (bytes=112) at malloc.c:3292
> #2  0x0830d9a8 in sqlite3MallocRaw (n=140706656, doMemManage=1)
>     at sqlite/util.c:590
> #3  0x0830da7e in sqlite3Malloc (n=140706656, doMemManage=150847728)
>     at sqlite/util.c:658
> #4  0x08383fb3 in allocateCursor (p=0x8630360, iCur=112, iDb=150847728)
>     at sqlite/vdbe.c:191
> #5  0x08384cfc in sqlite3VdbeExec (p=0x8cca780) at sqlite/vdbe.c:2587
> #6  0x0830f02f in sqlite3_step (pStmt=0x8630360) at sqlite/vdbeapi.c:231
> #7  0x0814402b in database::fetch(std::vector<std::vector<std::string, 
> std::allocator<std::string> >, std::allocator<std::vector<std::string, 
> std::allocator<std::string> > > >&, int, int, query const&) ()
> #8  0x08145870 in database::delta_exists(hexenc<id> const&, std::string 
> const&)
>     ()
> #9  0x0814a7e2 in database::file_version_exists(file<hexenc<id> > const&) ()
> #10 0x080f3387 in commands::cmd_checkout::exec(app_state&, std::vector<utf8, 
> std::allocator<utf8> > const&) ()
> #11 0x080a612e in commands::process(app_state&, std::string const&, 
> std::vector<utf8, std::allocator<utf8> > const&) ()
> #12 0x0829f6af in cpp_main(int, char**) ()
> #13 0x082a3b7c in main ()
> #14 0x0843fbc9 in __libc_start_main (main=0x82a39f6 <main>, argc=5,
>     ubp_av=0xbffffbb4, init=0x843fce0 <__libc_csu_init>,
>     fini=0x843fd40 <__libc_csu_fini>, rtld_fini=0, stack_end=0x8fdc0f0)
>     at ../sysdeps/generic/libc-start.c:152
> (gdb) cont

...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 :-(.

Does the memory usage of the process grow as it runs?

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"?

-- Nathaniel

-- 
"But suppose I am not willing to claim that.  For in fact pianos
are heavy, and very few persons can carry a piano all by themselves."