Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Feb 2000 10:00:06 +0100
From:      Martin Cracauer <cracauer@cons.org>
To:        jdp@freebsd.org
Cc:        jkh@freebsd.org, current@freebsd.org, dillon@apollo.backplane.com
Subject:   extern variables in shared libraries broken (ld.so or mmap bug)
Message-ID:  <20000222100006.A13742@cons.org>

next in thread | raw e-mail | index | archive | help
I am trying to hunt the strptime(..., "%+", ...) bug down. It looks
like a showstopper dynamic linker bug in 4.0 now. I suspect that
extern variables located in shared variables are broken, either by a
ld.so or a mmap bug.

In a dynamically linked program, it looks like the address of the
symbol "extern char *tzname[];" changes at runtime. You can write to
it as much as you like, but if you read it, the address points to the
void and the program dumps core. gdb displays very odd stuff, probably
reflecting a change in the underlying memory mapping.

When you link the program statically, it runs fine.

Try this program:

#include <stdio.h>
#include <time.h>

int
main(void)
{
  fprintf(stderr, "Address of tzname: %p\n", tzname);

  tzname[0] = "ERA";
  fprintf(stderr, "Address of tzname: %p\n", tzname);
  tzname[1] = "ERA";
  fprintf(stderr, "Address of tzname: %p\n", tzname);

  tzset();

  fprintf(stderr, "Address of tzname: %p\n", tzname);

  fprintf(stderr, "Values: '%s', '%s'\n", tzname[0], tzname[1]);

  return 0;
}

Run it in gdb, using this .gdbinit:

file test2
b main
r
display tzname
n
n

Breakpoint 1, 0x80484ab in main () at test2.c:7
7         fprintf(stderr, "Address of tzname: %p\n", tzname);
Address of tzname: 0x8049638
9         tzname[0] = "ERA";
1: {<data variable, no debug info>} (void *) 0x8049638 = 671997369
10        fprintf(stderr, "Address of tzname: %p\n", tzname);
1: {<data variable, no debug info>} (void *) 0x8049638 = 134514018


Now, look at the addresses printed by gdb: The hex addresses are the
same, but the decimal ones are not.

Also, the type of variable tzname is defined in scope, gdb should be
able to gather it.

Further down, when accessing tzname[0] or tzname[1] for reading, the
program dumps core, both when running in gdb and running standalone.

As I said, everything works fine when linking statically. In
3.4-stable, all is well for static and dynamic linking.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/
  Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000222100006.A13742>