bug-hurd
[Top][All Lists]
Advanced

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

Re: roland_libstore_modules_branch


From: Marcus Brinkmann
Subject: Re: roland_libstore_modules_branch
Date: Tue, 12 Mar 2002 00:54:36 +0100
User-agent: Mutt/1.3.27i

On Mon, Mar 11, 2002 at 04:37:27AM -0500, Roland McGrath wrote:
> > I did only the above tests, not a full install and boot, which one should
> > probably do next.  But it already looks very promising, fine work!
> 
> But it doesn't sound like you tested any of the dynamic loading
> functionality at all.

Indeed!  module.c isn't even part of the compiled source in your branch.

I added module.c to the sources, and module to the store-types, although the
latter doesn't seem to be necessary.  I removed gunzip.c from the sources,
and some of the GZIP objects, except util.o, which is also needed by bunzip2
(so I guess the current rule to build bunzip2 module is broken).  I changed

libstore.so-LDLIBS += -ldl

to

libstore.so-LDFLAGS += -ldl

as the former is not recognized by our Makeconf.  That made it build
correctly.  I then made a libstore_gunzip.so.0.2.  I changed

#define STORE_SONAME_SUFFIX ".so.1"

to

#define STORE_SONAME_SUFFIX ".so.0.2"

because otherwise it would look for the wrong file.  From the command line,
it seems to recognize the gunzip store now, both with -T module gunzip:file.gz
and with -T gunzip file.gz.  As a storeio translator, it starts up and dies:

#0  0x00007e04 in _dl_lookup_symbol () from /lib/ld.so
#1  0x011e08f3 in _dl_sym (handle=0x102b530, name=0x105cdaf 
"__start_store_std_classes", who=0x0)
    at dl-sym.c:62
#2  0x0121b108 in dlsym_doit (a=0x124b9fc) at dlsym.c:39
#3  0x0000bf92 in _dl_catch_error () from /lib/ld.so
#4  0x0121b426 in _dlerror_run (operate=0x121b0e4 <dlsym_doit>, args=0x124b9fc) 
at dlerror.c:130
#5  0x0121b143 in dlsym (handle=0x102b530, name=0x105cdaf 
"__start_store_std_classes")
    at dlsym.c:51
#6  0x010515e3 in store_find_class (name=0x804e1f0 "r.gz", clname_end=0x804e1f4 
"", classes=0x0)
    at ../../libstore/typed.c:75
#7  0x010516e0 in store_typed_open (name=0x804e1f0 "r.gz", flags=4096, 
classes=0x0,
    store=0x124bac8) at ../../libstore/typed.c:121
#8  0x0002ac07 in store_gunzip_open (name=0x804e1f0 "r.gz", flags=0, 
classes=0x0, store=0x124fe8c)
    at ../../libstore/gunzip.c:261
#9  0x010503ce in open (name=0x804e1f0 "r.gz", store=0x124fe8c) at 
../../libstore/argp.c:188
#10 0x0105044c in store_parsed_open (parsed=0x804e1c8, flags=0, store=0x124fe8c)
    at ../../libstore/argp.c:195
#11 0x08049f8e in dev_open (dev=0x124fe88) at ../../storeio/dev.c:153
#12 0x0804b64c in check_open_hook (trivfs_control=0x804e0f8, user=0x804e690, 
flags=1)
    at ../../storeio/storeio.c:228
#13 0x0103487f in trivfs_S_fsys_getroot () from /lib/libtrivfs.so.0.2
#14 0x01034cbb in trivfs_S_fsys_syncfs () from /lib/libtrivfs.so.0.2
#15 0x010354cd in trivfs_fsys_server () from /lib/libtrivfs.so.0.2
#16 0x01031d5f in trivfs_demuxer () from /lib/libtrivfs.so.0.2
#17 0x01095fd3 in ports_manage_port_operations_one_thread () from 
/lib/libports.so.0.2
#18 0x010c30eb in __mach_msg_server_timeout (demux=0x124fdfc, max_size=8192, 
rcv_name=31,
    option=2048, timeout=0) at msgserver.c:127
#19 0x010960b6 in ports_manage_port_operations_one_thread () from 
/lib/libports.so.0.2
#20 0x010961a6 in ports_manage_port_operations_multithread () from 
/lib/libports.so.0.2
#21 0x0804b592 in main (argc=4, argv=0x124ff88) at ../../storeio/storeio.c:148
#22 0x010e4e2b in __libc_start_main (main=0x804b498 <main>, argc=4, 
ubp_av=0x124ff88,
    init=0x804984c <_init>, fini=0x804c3e0 <_fini>, rtld_fini=0xc370 <_dl_fini>,
    stack_end=0x124ff7c) at ../sysdeps/generic/libc-start.c:129

It turns out that in store_parsed_open, the gunzip store class is in parsed,
plus the name "r.gz".  So NUM is 1, and it calls open as shown above.  It
should fail to find a module and try to open it as a file instead, but
rather than doing that it crashes.  It first finds the normal std classes,
and then at the second dlsym it dies.  From an earlier debugging session:

75                start = dlsym (map, "__start_store_std_classes");
(gdb) print map
$1 = (struct link_map *) 0x102b000
(gdb) print *map
$2 = {l_addr = 0, l_name = 0x15aeb "", l_ld = 0x804da84, l_next = 0x102b500, 
l_prev = 0x0}
(gdb) n
76                if (start == 0)
(gdb) n
81                if (start == __start_store_std_classes)
(gdb) print start
$3 = (struct store_class **) 0x105fac0
(gdb) n
93              }
(gdb) n
75                start = dlsym (map, "__start_store_std_classes");
(gdb) n

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x00007e04 in _dl_lookup_symbol () from /lib/ld.so

Note that -T gunzip file:r.gz works fine!

> But before those tests, if a full boot and tests on the system using the
> new libstore all work, then I will merge the branch into the mainline.

I did not do that yet.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de



reply via email to

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