storeio crashes with gunzip/bunzip2 classes

[Ludovic Courtès]

Hi,

On my machine (installation comes from the H4 CDs), doing the following makes
storeio crash:

  $ settrans -ca t /hurd/storeio -T gunzip file.gz
  $ cat t

The following happens:

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x000074ac in _dl_lookup_symbol () from /lib/ld.so
(gdb) bt
#0  0x000074ac in _dl_lookup_symbol () from /lib/ld.so
#1  0x011e5998 in _dl_sym () from /lib/libc.so.0.3
#2  0x01228f09 in dlclose () from /lib/libdl.so.2
#3  0x0000b02d in _dl_catch_error () from /lib/ld.so
#4  0x012291d0 in dlerror () from /lib/libdl.so.2
#5  0x01228f43 in dlsym () from /lib/libdl.so.2
#6  0x0104d2a6 in store_find_class () from /lib/libstore.so.0.2
#7  0x0104d3c7 in store_typed_open () from /lib/libstore.so.0.2
#8  0x0105039d in store_gunzip_open () from /lib/libstore.so.0.2
#9  0x0104c12b in store_parsed_name () from /lib/libstore.so.0.2
#10 0x0104c325 in store_parsed_open () from /lib/libstore.so.0.2
#11 0x08049df3 in dev_open (dev=0x125fe80) at dev.c:153
#12 0x0804b0b6 in check_open_hook (trivfs_control=0x804dae0, user=0x804dca0,
    flags=1) at storeio.c:228
#13 0x01031946 in trivfs_S_fsys_getroot () from /lib/libtrivfs.so.0.2
#14 0x01031c5d in trivfs_S_fsys_syncfs () from /lib/libtrivfs.so.0.2
#15 0x01032675 in trivfs_fsys_server () from /lib/libtrivfs.so.0.2
#16 0x0102ec88 in trivfs_demuxer () from /lib/libtrivfs.so.0.2
#17 0x01091fd7 in ports_manage_port_operations_one_thread ()
   from /lib/libports.so.0.2
#18 0x010bf090 in mach_msg_server_timeout () from /lib/libc.so.0.3
#19 0x01091d74 in ports_manage_port_operations_one_thread ()
   from /lib/libports.so.0.2
#20 0x010920e8 in ports_manage_port_operations_multithread ()
   from /lib/libports.so.0.2
#21 0x0804af06 in main (argc=4, argv=0x125ff98) at storeio.c:148
#22 0x010e2db6 in __libc_start_main () from /lib/libc.so.0.3

The same thing happens with the bunzip2 store class.
I'm wondering if this is a problem everyone has or if this is something messed
up on my machine.

Thanks,
Ludovic.