Re, Samuel Thibault, le mer. 27 juil. 2022 23:35:46 +0200, a ecrit: > Peter B, le mer. 27 juil. 2022 18:02:53 +0100, a ecrit: > > #11 0x010bcff2 in __GI___assert_fail (assertion=0x10538b5 "self != NULL", > > file=0x10538ab "pt-self.c", line=28, function=0x10538c4 > > <__PRETTY_FUNCTION__.1> "__pthread_self") at assert.c:101 > > #12 0x0104d33f in __pthread_self () at pt-self.c:28 > > #13 __pthread_self () at pt-self.c:25 > > #14 0x0803d0c7 in lock () at sem_inc.c:145 > > #15 0x0803d1d6 in DUMA_get_sem () at sem_inc.c:230 > > #16 0x0803afcc in _duma_init () at duma.c:1034 > > #17 0x0803c386 in _duma_malloc (size=716, filename=0x803e060 <unknown_file> > > "UNKNOWN (use #include \"duma.h\")", lineno=0) at duma.c:1966 > > #18 0x0803cc8b in malloc (size=716) at duma.c:2424 > > #19 0x0104c33d in __pthread_alloc (pthread=0x1039d30) at pt-alloc.c:124 > > #20 0x0104c773 in __pthread_create_internal (thread=0x1039d78, > > attr=0x1039d7c, start_routine=0x0, arg=0x0) at pt-create.c:120 > > #21 0x0105146b in _init_routine (stack=<optimized out>) at > > ../sysdeps/mach/hurd/htl/pt-sysdep.c:66 > > #22 0x0001164b in call_init (l=<optimized out>, argc=argc@entry=1, > > argv=argv@entry=0x1039e54, env=0x1039e5c) at dl-init.c:74 > > #23 0x000117f5 in call_init (env=0x1039e5c, argv=0x1039e54, argc=1, > > l=<optimized out>) at dl-init.c:37 > > #24 _dl_init (main_map=0x389d0, argc=1, argv=0x1039e54, env=0x1039e5c) at > > dl-init.c:88 > > #25 0x00002052 in _dl_start_user () from /lib/ld.so > > Ok, that confirms what I was guessing: libpthread is initializing > itself, and for that uses a dynamic allocation, during which duma calls > pthread_self, which cannot work yet. > > Ideally libpthread would not need to allocate anything for its > initialization, but that's really tricky. Possibly we can trick > pthread_self into being callable very early.
Could you try with the libc from https://people.debian.org/~sthibault/tmp/hurd-i386/ Samuel
