From owner-freebsd-current Tue Feb 22 1: 0:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from knight.cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 5FF8D37B663; Tue, 22 Feb 2000 01:00:09 -0800 (PST) (envelope-from cracauer@knight.cons.org) Received: (from cracauer@localhost) by knight.cons.org (8.9.3/8.9.3) id KAA13794; Tue, 22 Feb 2000 10:00:07 +0100 (CET) Date: Tue, 22 Feb 2000 10:00:06 +0100 From: Martin Cracauer 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 #include 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: {} (void *) 0x8049638 = 671997369 10 fprintf(stderr, "Address of tzname: %p\n", tzname); 1: {} (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 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