Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1111097 > unrolled thread

Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)

Started byPeter Blackman <peter@pblackman.plus.com>
First post2022-07-27 13:30 +0200
Last post2022-07-28 17:30 +0200
Articles 17 — 3 participants

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Peter Blackman <peter@pblackman.plus.com> - 2022-07-27 13:30 +0200
    Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Samuel Thibault <sthibault@debian.org> - 2022-07-27 14:00 +0200
      Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Peter B <peter@pblackman.plus.com> - 2022-07-27 19:20 +0200
        Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Peter B <peter@pblackman.plus.com> - 2022-07-27 19:50 +0200
        Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Samuel Thibault <sthibault@debian.org> - 2022-07-27 23:40 +0200
          Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Samuel Thibault <sthibault@debian.org> - 2022-07-28 01:10 +0200
            Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Peter B <peter@pblackman.plus.com> - 2022-07-28 17:10 +0200
              Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Samuel Thibault <sthibault@debian.org> - 2022-07-28 17:10 +0200
                Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Peter B <peter@pblackman.plus.com> - 2022-07-28 17:30 +0200
                  Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Samuel Thibault <sthibault@debian.org> - 2022-07-28 18:00 +0200
                    Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Peter B <peter@pblackman.plus.com> - 2022-07-28 19:10 +0200
                      Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Peter B <peter@pblackman.plus.com> - 2022-07-28 19:30 +0200
                        Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Samuel Thibault <sthibault@debian.org> - 2022-07-28 19:40 +0200
                      Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Samuel Thibault <sthibault@debian.org> - 2022-07-28 20:30 +0200
                        Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Peter B <peter@pblackman.plus.com> - 2022-07-28 21:20 +0200
                          Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Samuel Thibault <sthibault@debian.org> - 2022-07-28 22:10 +0200
    Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail) Samuel Thibault <sthibault@debian.org> - 2022-07-28 17:30 +0200

#1111097 — Bug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)

FromPeter Blackman <peter@pblackman.plus.com>
Date2022-07-27 13:30 +0200
SubjectBug#1016106: duma: FTBFS on hurd-i386 (builds OK, but most self tests fail)
Message-ID<ENNoJ-ea5O-5@gated-at.bofh.it>
Package: duma
Tags: hurd, ftbfs, confirmed, help
Usertags: debian-hurd@lists.debian.org
X-Debbugs-Cc: debian-hurd@lists.debian.org


duma compiles & links on Hurd, but self tests fail.
https://buildd.debian.org/status/package.php?p=duma


Testing via KVM, shows that all tests except for thread-test,
fail with output 'Killed'.

Back trace on dumatest shows an endless loop. Repeats every ten steps.


=====================================================

Starting program: /home/demo/duma-2.5.21/dumatest

Thread 4 received signal ?, Unknown signal.
0x010b9415 in ?? () from /lib/i386-gnu/libc.so.0.3
#0  0x010b9415 in ?? () from /lib/i386-gnu/libc.so.0.3
#1  0x010b812a in dcgettext () from /lib/i386-gnu/libc.so.0.3
#2  0x010b7452 in __assert_fail () from /lib/i386-gnu/libc.so.0.3
#3  0x010452cf in pthread_self () from /lib/i386-gnu/libpthread.so.0.3
#4  0x08036095 in lock () at sem_inc.c:135
#5  0x080361d6 in DUMA_get_sem () at sem_inc.c:230
#6  0x080345a1 in _duma_allocate (alignment=1, userSize=100, protectBelow=0,
     fillByte=255, protectAllocList=1, allocator=EFA_MALLOC, #49 0x01103ce5 in ?? () from /lib/i386-gnu/libc.so.0.3
#7  0x080353b6 in _duma_malloc (size=100,
     filename=0x8037060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
     lineno=0) at duma.c:1970
#8  0x08035c8b in malloc (size=100) at duma.c:2424
#9  0x01103ce5 in ?? () from /lib/i386-gnu/libc.so.0.3
#10 0x010e06a7 in asprintf () from /lib/i386-gnu/libc.so.0.3
#11 0x010b736a in ?? () from /lib/i386-gnu/libc.so.0.3
#12 0x010b7469 in __assert_fail () from /lib/i386-gnu/libc.so.0.3
#13 0x010452cf in pthread_self () from /lib/i386-gnu/libpthread.so.0.3
#14 0x08036095 in lock () at sem_inc.c:135
#15 0x080361d6 in DUMA_get_sem () at sem_inc.c:230
#16 0x080345a1 in _duma_allocate (alignment=1, userSize=100, protectBelow=0,
     fillByte=255, protectAllocList=1, allocator=EFA_MALLOC,
     fail=DUMA_FAIL_ENV,
     filename=0x8037060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
     lineno=0) at duma.c:1386
#17 0x080353b6 in _duma_malloc (size=100,
     filename=0x8037060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
     lineno=0) at duma.c:1970
#18 0x08035c8b in malloc (size=100) at duma.c:2424
#19 0x01103ce5 in ?? () from /lib/i386-gnu/libc.so.0.3
#20 0x010e06a7 in asprintf () from /lib/i386-gnu/libc.so.0.3
#21 0x010b736a in ?? () from /lib/i386-gnu/libc.so.0.3
#22 0x010b7469 in __assert_fail () from /lib/i386-gnu/libc.so.0.3
#23 0x010452cf in pthread_self () from /lib/i386-gnu/libpthread.so.0.3
#24 0x08036095 in lock () at sem_inc.c:135
#25 0x080361d6 in DUMA_get_sem () at sem_inc.c:230
#26 0x080345a1 in _duma_allocate (alignment=1, userSize=100, protectBelow=0,
     fillByte=255, protectAllocList=1, allocator=EFA_MALLOC,
     fail=DUMA_FAIL_ENV,
     filename=0x8037060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
     lineno=0) at duma.c:1386
#27 0x080353b6 in _duma_malloc (size=100,
     filename=0x8037060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
     lineno=0) at duma.c:1970
#28 0x08035c8b in malloc (size=100) at duma.c:2424
#29 0x01103ce5 in ?? () from /lib/i386-gnu/libc.so.0.3
#30 0x010e06a7 in asprintf () from /lib/i386-gnu/libc.so.0.3
#31 0x010b736a in ?? () from /lib/i386-gnu/libc.so.0.3
#32 0x010b7469 in __assert_fail () from /lib/i386-gnu/libc.so.0.3
#33 0x010452cf in pthread_self () from /lib/i386-gnu/libpthread.so.0.3
#34 0x08036095 in lock () at sem_inc.c:135
#35 0x080361d6 in DUMA_get_sem () at sem_inc.c:230
#36 0x080345a1 in _duma_allocate (alignment=1, userSize=100, protectBelow=0,
     fillByte=255, protectAllocList=1, allocator=EFA_MALLOC,
     fail=DUMA_FAIL_ENV,
     filename=0x8037060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
     lineno=0) at duma.c:1386
#37 0x080353b6 in _duma_malloc (size=100,
     filename=0x8037060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
     lineno=0) at duma.c:1970
#38 0x08035c8b in malloc (size=100) at duma.c:2424
#39 0x01103ce5 in ?? () from /lib/i386-gnu/libc.so.0.3
#40 0x010e06a7 in asprintf () from /lib/i386-gnu/libc.so.0.3
#41 0x010b736a in ?? () from /lib/i386-gnu/libc.so.0.3
#42 0x010b7469 in __assert_fail () from /lib/i386-gnu/libc.so.0.3
#43 0x010452cf in pthread_self () from /lib/i386-gnu/libpthread.so.0.3
#44 0x08036095 in lock () at sem_inc.c:135
#45 0x080361d6 in DUMA_get_sem () at sem_inc.c:230
#46 0x080345a1 in _duma_allocate (alignment=1, userSize=100, protectBelow=0,
     fillByte=255, protectAllocList=1, allocator=EFA_MALLOC,
     fail=DUMA_FAIL_ENV,
     filename=0x8037060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
     lineno=0) at duma.c:1386
#47 0x080353b6 in _duma_malloc (size=100,
     filename=0x8037060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
     lineno=0) at duma.c:1970
#48 0x08035c8b in malloc (size=100) at duma.c:2424

===========================================================


I'm curious about the step   pthread_self ()  -->  __assert_fail ()

The man page for pthread_self (Linux)
https://man7.org/linux/man-pages/man3/pthread_self.3.html

states that the function always succeeds. Unlikely if it throws an assert.


Also raised upstream
https://github.com/johnsonjh/duma/issues/172

but the question really is.

Is this a bug in Hurd, or something that can be fixed in duma?


Regards,
Peter B

[toc] | [next] | [standalone]

#1111100

FromSamuel Thibault <sthibault@debian.org>
Date2022-07-27 14:00 +0200
Message-ID<ENNRL-eafJ-3@gated-at.bofh.it>
In reply to#1111097
Hello,

Peter Blackman, le mer. 27 juil. 2022 12:22:17 +0100, a ecrit:
> Back trace on dumatest shows an endless loop. Repeats every ten steps.

Could you manage to get the top of the stack?

> #35 0x080361d6 in DUMA_get_sem () at sem_inc.c:230
> #36 0x080345a1 in _duma_allocate (alignment=1, userSize=100, protectBelow=0,
>     fillByte=255, protectAllocList=1, allocator=EFA_MALLOC,
>     fail=DUMA_FAIL_ENV,
>     filename=0x8037060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
>     lineno=0) at duma.c:1386
> #37 0x080353b6 in _duma_malloc (size=100,
>     filename=0x8037060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
>     lineno=0) at duma.c:1970
> #38 0x08035c8b in malloc (size=100) at duma.c:2424
> #39 0x01103ce5 in ?? () from /lib/i386-gnu/libc.so.0.3
> #40 0x010e06a7 in asprintf () from /lib/i386-gnu/libc.so.0.3
> #41 0x010b736a in ?? () from /lib/i386-gnu/libc.so.0.3
> #42 0x010b7469 in __assert_fail () from /lib/i386-gnu/libc.so.0.3
> #43 0x010452cf in pthread_self () from /lib/i386-gnu/libpthread.so.0.3
> #44 0x08036095 in lock () at sem_inc.c:135
> #45 0x080361d6 in DUMA_get_sem () at sem_inc.c:230
> #46 0x080345a1 in _duma_allocate (alignment=1, userSize=100, protectBelow=0,
>     fillByte=255, protectAllocList=1, allocator=EFA_MALLOC,
>     fail=DUMA_FAIL_ENV,
>     filename=0x8037060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
>     lineno=0) at duma.c:1386
> #47 0x080353b6 in _duma_malloc (size=100,
>     filename=0x8037060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
>     lineno=0) at duma.c:1970
> #48 0x08035c8b in malloc (size=100) at duma.c:2424

So the loop is because the assertion failure uses printf, which uses an
allocation, which triggers the assertion again etc.

> I'm curious about the step   pthread_self ()  -->  __assert_fail ()
> 
> The man page for pthread_self (Linux)
> https://man7.org/linux/man-pages/man3/pthread_self.3.html
> 
> states that the function always succeeds. Unlikely if it throws an assert.

Yes, that's why it's an assert and not an error: something very wrong is
happening.

Do you have the libc0.3-dbg package installed? That'd help to know
exactly why assertion fails.

> Also raised upstream
> https://github.com/johnsonjh/duma/issues/172
> 
> but the question really is.
> 
> Is this a bug in Hurd, or something that can be fixed in duma?

Most probably what happens (the top of the stack would tell) is that
pthread_self is called very early, before libpthread is initialized, and
it's assert (__pthread_threads); which fails because of that.

Samuel

[toc] | [prev] | [next] | [standalone]

#1111131

FromPeter B <peter@pblackman.plus.com>
Date2022-07-27 19:20 +0200
Message-ID<ENSRr-edoh-7@gated-at.bofh.it>
In reply to#1111100
Hi Samuel,

Thanks for the suggestions. I've installed libc0.3-dbg, and also ended up with a much smaller backtrace.

Regarding
     "/../sysdeps/mach/hurd/htl/pt-mutex-lock.c: No such file or directory/"
Does this suggest a missing dependency?


Complete backtrace for a failing test.


Starting program: /home/demo/duma-2.5.21/dumatest

Thread 4 received signal ?, Unknown signal.
0x0104d996 in __pthread_mutex_lock (mtxp=0x8) at ../sysdeps/mach/hurd/htl/pt-mutex-lock.c:30
30    ../sysdeps/mach/hurd/htl/pt-mutex-lock.c: No such file or directory.
#0  0x0104d996 in __pthread_mutex_lock (mtxp=0x8)
     at ../sysdeps/mach/hurd/htl/pt-mutex-lock.c:30
#1  0x01052af4 in __pthread_enable_asynccancel () at cancellation.c:28
#2  0x01198991 in __GI___libc_write (fd=2, buf=0x1038a2c, nbytes=235)
     at ../sysdeps/mach/hurd/write.c:25
#3  0x0803d7ee in DUMA_Print (
     pattern=0x803df60 <version> "DUMA, built 11/05/21 20:00:00 (static library)\nCopyright (C) 2006 Michael Eddington 
<meddington@gmail.com>\nCopyright (C) 2002-2009 Hayati Ayguen <h_ayguen@web.de>, Procitec GmbH\nCopyright (C) 
1987-199"...) at print.c:331
#4  0x0803ae72 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>)
     at duma.c:905
#5  0x0803aec9 in duma_init () at duma.c:943
#6  0x0803b2a2 in _duma_init () at duma.c:1138
#7  0x0803c436 in _duma_free (baseAdr=0x0,
     filename=0x803e060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
     lineno=0) at duma.c:2003
#8  0x0803ccdd in free (address=0x0) at duma.c:2436
#9  0x010bf07b in __dcigettext (
     domainname=0x1267ac0 <_libc_intl_domainname> "libc",
     msgid1=<optimized out>, msgid2=<optimized out>, plural=<optimized out>,
     n=0, category=<optimized out>) at dcigettext.c:833
#10 0x010bdc9a in __GI___dcgettext (
     domainname=0x1267ac0 <_libc_intl_domainname> "libc",
     msgid=0x1267ae0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", category=5) at dcgettext.c:47
#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



Cheers,
Peter B

[toc] | [prev] | [next] | [standalone]

#1111132

FromPeter B <peter@pblackman.plus.com>
Date2022-07-27 19:50 +0200
Message-ID<ENTkt-edy4-1@gated-at.bofh.it>
In reply to#1111131

[Multipart message — attachments visible in raw view] — view raw

Attaching back trace log

[toc] | [prev] | [next] | [standalone]

#1111158

FromSamuel Thibault <sthibault@debian.org>
Date2022-07-27 23:40 +0200
Message-ID<ENWV3-efHs-29@gated-at.bofh.it>
In reply to#1111131
Hello,

Peter B, le mer. 27 juil. 2022 18:02:53 +0100, a ecrit:
> Regarding
>     "/../sysdeps/mach/hurd/htl/pt-mutex-lock.c: No such file or directory/"
> Does this suggest a missing dependency?

No it's just that you don't have the glibc source code in your current
directory :)

> #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.

(this is probably working on Linux only by luck)

Samuel

[toc] | [prev] | [next] | [standalone]

#1111165

FromSamuel Thibault <sthibault@debian.org>
Date2022-07-28 01:10 +0200
Message-ID<ENYka-egFc-3@gated-at.bofh.it>
In reply to#1111158
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

[toc] | [prev] | [next] | [standalone]

#1111232

FromPeter B <peter@pblackman.plus.com>
Date2022-07-28 17:10 +0200
Message-ID<EOdjb-epFF-3@gated-at.bofh.it>
In reply to#1111165
On 28/07/2022 00:02, Samuel Thibault wrote:
> Could you try with the libc from
> https://people.debian.org/~sthibault/tmp/hurd-i386/
>
> Samuel

Hi Samuel,

Having some issues with file corruption in my VM, so not sure the results are consistent.

I tried Jeffrey's suggestions of DUMA_DISABLE_BANNER and DUMA_OUTPUT_FILE
and it made no difference.
Tried your libc and also no difference.

Reinstalled duma after hosing its folder somehow, GNUmakefile was overwritten with binary junk.

Tests now pass if DUMA_DISABLE_BANNER is defined.

I don't know how to downgrade libc to confirm whether DUMA_DISABLE_BANNER is sufficient,
or whether the libc upgrade is also needed. On its own, it (libc) does not seem to fix the problem.


Cheers,
Peter

[toc] | [prev] | [next] | [standalone]

#1111234

FromSamuel Thibault <sthibault@debian.org>
Date2022-07-28 17:10 +0200
Message-ID<EOdjc-epFF-9@gated-at.bofh.it>
In reply to#1111232
Peter B, le jeu. 28 juil. 2022 15:56:27 +0100, a ecrit:
> Tried your libc and also no difference.

The backtrace is exactly the same? I don't see how that can be, since my
patch makes __pthread_self return immediately when ___pthread_self is
NULL, and at

#21 0x0105146b in _init_routine (stack=<optimized out>) at ../sysdeps/mach/hurd/htl/pt-sysdep.c:66

has not yet be set to non-NULL.

Samuel

[toc] | [prev] | [next] | [standalone]

#1111237

FromPeter B <peter@pblackman.plus.com>
Date2022-07-28 17:30 +0200
Message-ID<EOdCx-epM1-5@gated-at.bofh.it>
In reply to#1111234

[Multipart message — attachments visible in raw view] — view raw

On 28/07/2022 16:00, Samuel Thibault wrote:
> Peter B, le jeu. 28 juil. 2022 15:56:27 +0100, a ecrit:
>> Tried your libc and also no difference.
> The backtrace is exactly the same? I don't see how that can be, since my
> patch makes __pthread_self return immediately when ___pthread_self is
> NULL, and at
>
> #21 0x0105146b in _init_routine (stack=<optimized out>) at ../sysdeps/mach/hurd/htl/pt-sysdep.c:66
>
> has not yet be set to non-NULL.
>
> Samuel

Hi Samuel,

Sorry, I just meant that the test program still fails. Here is the new (different) backtrace.


Starting program: /home/demo/duma-2.5.21/dumatest

Thread 4 received signal ?, Unknown signal.
0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3
#0  0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3
#1  0x01052ae4 in __pthread_enable_asynccancel ()
    from /lib/i386-gnu/libpthread.so.0.3
#2  0x01198991 in write () from /lib/i386-gnu/libc.so.0.3
#3  0x0803d802 in DUMA_Print (
     pattern=0x803df60 <version> "DUMA, built 11/05/21 20:00:00 (static library)\nCopyright (C) 2006 Michael Eddington 
<meddington@gmail.com>\nCopyright (C) 2002-2009 Hayati Ayguen <h_ayguen@web.de>, Procitec GmbH\nCopyright (C) 
1987-199"...) at print.c:331
#4  0x0803ae86 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>)
     at duma.c:905
#5  0x0803aedd in duma_init () at duma.c:943
#6  0x0803b2b6 in _duma_init () at duma.c:1138
#7  0x0803c39a in _duma_malloc (size=716,
     filename=0x803e060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
     lineno=0) at duma.c:1966
#8  0x0803cc9f in malloc (size=716) at duma.c:2424
#9  0x0104c33d in __pthread_alloc () from /lib/i386-gnu/libpthread.so.0.3
#10 0x0104c773 in __pthread_create_internal ()
    from /lib/i386-gnu/libpthread.so.0.3
#11 0x0105145b in _init_routine.part.0 () from /lib/i386-gnu/libpthread.so.0.3
#12 0x0001164b in ?? () from /lib/ld.so
#13 0x000117f5 in ?? () from /lib/ld.so
#14 0x00002052 in ?? () from /lib/ld.so
#0  0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3
#1  0x01052ae4 in __pthread_enable_asynccancel ()
    from /lib/i386-gnu/libpthread.so.0.3
#2  0x01198991 in write () from /lib/i386-gnu/libc.so.0.3
#3  0x0803d802 in DUMA_Print (
     pattern=0x803df60 <version> "DUMA, built 11/05/21 20:00:00 (static library)\nCopyright (C) 2006 Michael Eddington 
<meddington@gmail.com>\nCopyright (C) 2002-2009 Hayati Ayguen <h_ayguen@web.de>, Procitec GmbH\nCopyright (C) 
1987-199"...) at print.c:331
#4  0x0803ae86 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>)
     at duma.c:905
#5  0x0803aedd in duma_init () at duma.c:943
#6  0x0803b2b6 in _duma_init () at duma.c:1138
#7  0x0803c39a in _duma_malloc (size=716,
     filename=0x803e060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
     lineno=0) at duma.c:1966
#8  0x0803cc9f in malloc (size=716) at duma.c:2424
#9  0x0104c33d in __pthread_alloc () from /lib/i386-gnu/libpthread.so.0.3
#10 0x0104c773 in __pthread_create_internal ()
    from /lib/i386-gnu/libpthread.so.0.3
#11 0x0105145b in _init_routine.part.0 () from /lib/i386-gnu/libpthread.so.0.3
#12 0x0001164b in ?? () from /lib/ld.so
#13 0x000117f5 in ?? () from /lib/ld.so
#14 0x00002052 in ?? () from /lib/ld.so


Cheers,
Peter

[toc] | [prev] | [next] | [standalone]

#1111239

FromSamuel Thibault <sthibault@debian.org>
Date2022-07-28 18:00 +0200
Message-ID<EOe5z-epVl-9@gated-at.bofh.it>
In reply to#1111237
Peter B, le jeu. 28 juil. 2022 16:22:23 +0100, a ecrit:
> #0  0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3
> #1  0x01052ae4 in __pthread_enable_asynccancel ()
>    from /lib/i386-gnu/libpthread.so.0.3

Possibly it could be just that, could you try with the updated packages
from 

https://people.debian.org/~sthibault/tmp/hurd-i386/

?

Samuel

[toc] | [prev] | [next] | [standalone]

#1111244

FromPeter B <peter@pblackman.plus.com>
Date2022-07-28 19:10 +0200
Message-ID<EOfbj-eqMK-1@gated-at.bofh.it>
In reply to#1111239

[Multipart message — attachments visible in raw view] — view raw

On 28/07/2022 16:53, Samuel Thibault wrote:
> Peter B, le jeu. 28 juil. 2022 16:22:23 +0100, a ecrit:
>> #0  0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3
>> #1  0x01052ae4 in __pthread_enable_asynccancel ()
>>     from /lib/i386-gnu/libpthread.so.0.3
> Possibly it could be just that, could you try with the updated packages
> from
>
> https://people.debian.org/~sthibault/tmp/hurd-i386/
>
> ?
>
> Samuel

Sure ....

This is what I got while our messages crossed

Starting program: /home/demo/duma-2.5.21/dumatest

Thread 4 received signal ?, Unknown signal.
0x0104d986 in __pthread_mutex_lock (mtxp=0x8) at ../sysdeps/mach/hurd/htl/pt-mutex-lock.c:30
30    ../sysdeps/mach/hurd/htl/pt-mutex-lock.c: No such file or directory.
#0  0x0104d986 in __pthread_mutex_lock (mtxp=0x8)
     at ../sysdeps/mach/hurd/htl/pt-mutex-lock.c:30
#1  0x01052ae4 in __pthread_enable_asynccancel () at cancellation.c:28
#2  0x01198991 in __GI___libc_write (fd=2, buf=0x1038bec, nbytes=235)
     at ../sysdeps/mach/hurd/write.c:25
#3  0x0803d7ee in DUMA_Print (
     pattern=0x803df60 <version> "DUMA, built 11/05/21 20:00:00 (static library)\nCopyright (C) 2006 Michael Eddington 
<meddington@gmail.com>\nCopyright (C) 2002-2009 Hayati Ayguen <h_ayguen@web.de>, Procitec GmbH\nCopyright (C) 
1987-199"...) at print.c:331
#4  0x0803ae72 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>)
     at duma.c:905
#5  0x0803aec9 in duma_init () at duma.c:943
#6  0x0803b2a2 in _duma_init () at duma.c:1138
#7  0x0803c386 in _duma_malloc (size=716,
     filename=0x803e060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
     lineno=0) at duma.c:1966
#8  0x0803cc8b in malloc (size=716) at duma.c:2424
#9  0x0104c33d in __pthread_alloc (pthread=0x1039d30) at pt-alloc.c:124
#10 0x0104c773 in __pthread_create_internal (thread=0x1039d78, attr=0x1039d7c,
     start_routine=0x0, arg=0x0) at pt-create.c:120
#11 0x0105145b in _init_routine (stack=<optimized out>)
     at ../sysdeps/mach/hurd/htl/pt-sysdep.c:66
#12 0x0001164b in call_init (l=<optimized out>, argc=argc@entry=1,
     argv=argv@entry=0x1039e54, env=0x1039e5c) at dl-init.c:74
#13 0x000117f5 in call_init (env=0x1039e5c, argv=0x1039e54, argc=1, l=<optimized out>) at dl-init.c:37
#14 _dl_init (main_map=0x389d0, argc=1, argv=0x1039e54, env=0x1039e5c) at dl-init.c:88
#15 0x00002052 in _dl_start_user () from /lib/ld.so


This is with the latest libc

Starting program: /home/demo/duma-2.5.21/dumatest

Thread 4 received signal ?, Unknown signal.
__pthread_enable_asynccancel () at cancellation.c:30
30    cancellation.c: No such file or directory.
#0  __pthread_enable_asynccancel () at cancellation.c:30
#1  0x01198991 in __GI___libc_write (fd=2, buf=0x1038bec, nbytes=235)
     at ../sysdeps/mach/hurd/write.c:25
#2  0x0803d7ee in DUMA_Print (
     pattern=0x803df60 <version> "DUMA, built 11/05/21 20:00:00 (static library)\nCopyright (C) 2006 Michael Eddington 
<meddington@gmail.com>\nCopyright (C) 2002-2009 Hayati Ayguen <h_ayguen@web.de>, Procitec GmbH\nCopyright (C) 
1987-199"...) at print.c:331
#3  0x0803ae72 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>)
     at duma.c:905
#4  0x0803aec9 in duma_init () at duma.c:943
#5  0x0803b2a2 in _duma_init () at duma.c:1138
#6  0x0803c386 in _duma_malloc (size=716,
     filename=0x803e060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
     lineno=0) at duma.c:1966
#7  0x0803cc8b in malloc (size=716) at duma.c:2424
#8  0x0104c33d in __pthread_alloc (pthread=0x1039d30) at pt-alloc.c:124
#9  0x0104c773 in __pthread_create_internal (thread=0x1039d78, attr=0x1039d7c,
     start_routine=0x0, arg=0x0) at pt-create.c:120
#10 0x0105145b in _init_routine (stack=<optimized out>)
     at ../sysdeps/mach/hurd/htl/pt-sysdep.c:66
#11 0x0001164b in call_init (l=<optimized out>, argc=argc@entry=1,
     argv=argv@entry=0x1039e54, env=0x1039e5c) at dl-init.c:74
#12 0x000117f5 in call_init (env=0x1039e5c, argv=0x1039e54, argc=1,
     l=<optimized out>) at dl-init.c:37
#13 _dl_init (main_map=0x389d0, argc=1, argv=0x1039e54, env=0x1039e5c) at dl-init.c:88
#14 0x00002052 in _dl_start_user () from /lib/ld.so

[toc] | [prev] | [next] | [standalone]

#1111245

FromPeter B <peter@pblackman.plus.com>
Date2022-07-28 19:30 +0200
Message-ID<EOfuF-eqT5-3@gated-at.bofh.it>
In reply to#1111244
@ Samuel,


We have a solution with libc 2.33-9 and DUMA_DISABLE_BANNER
if hurd users can live without the banner.

I'm happy to do more tests, but probably have to wait till next week now.

Cheers,
Peter

[toc] | [prev] | [next] | [standalone]

#1111246

FromSamuel Thibault <sthibault@debian.org>
Date2022-07-28 19:40 +0200
Message-ID<EOfEl-eqW5-5@gated-at.bofh.it>
In reply to#1111245
Peter B, le jeu. 28 juil. 2022 18:24:40 +0100, a ecrit:
> We have a solution with libc 2.33-9 and DUMA_DISABLE_BANNER

Yes, but better have a more complete solution, so that other libraries
like duma can work too.

Samuel

[toc] | [prev] | [next] | [standalone]

#1111256

FromSamuel Thibault <sthibault@debian.org>
Date2022-07-28 20:30 +0200
Message-ID<EOgqJ-ersr-1@gated-at.bofh.it>
In reply to#1111244
Peter B, le jeu. 28 juil. 2022 18:01:42 +0100, a ecrit:
> Thread 4 received signal ?, Unknown signal.
> __pthread_enable_asynccancel () at cancellation.c:30
> 30	cancellation.c: No such file or directory.
> #0  __pthread_enable_asynccancel () at cancellation.c:30

Oh, right, of course. Could you try the updated package from 
https://people.debian.org/~sthibault/tmp/hurd-i386/
?

Samuel

[toc] | [prev] | [next] | [standalone]

#1111262

FromPeter B <peter@pblackman.plus.com>
Date2022-07-28 21:20 +0200
Message-ID<EOhd7-erYN-1@gated-at.bofh.it>
In reply to#1111256
On 28/07/2022 19:19, Samuel Thibault wrote:
> Peter B, le jeu. 28 juil. 2022 18:01:42 +0100, a ecrit:
>> Thread 4 received signal ?, Unknown signal.
>> __pthread_enable_asynccancel () at cancellation.c:30
>> 30	cancellation.c: No such file or directory.
>> #0  __pthread_enable_asynccancel () at cancellation.c:30
> Oh, right, of course. Could you try the updated package from
> https://people.debian.org/~sthibault/tmp/hurd-i386/
> ?
>
> Samuel

All working fine now!  What happens next?

I will ask for duma to be rebuilt when the libc fix reaches sid.



Many thanks,
Peter

[toc] | [prev] | [next] | [standalone]

#1111266

FromSamuel Thibault <sthibault@debian.org>
Date2022-07-28 22:10 +0200
Message-ID<EOhZv-esuh-1@gated-at.bofh.it>
In reply to#1111262
Peter B, le jeu. 28 juil. 2022 20:11:58 +0100, a ecrit:
> On 28/07/2022 19:19, Samuel Thibault wrote:
> > Peter B, le jeu. 28 juil. 2022 18:01:42 +0100, a ecrit:
> > > Thread 4 received signal ?, Unknown signal.
> > > __pthread_enable_asynccancel () at cancellation.c:30
> > > 30	cancellation.c: No such file or directory.
> > > #0  __pthread_enable_asynccancel () at cancellation.c:30
> > Oh, right, of course. Could you try the updated package from
> > https://people.debian.org/~sthibault/tmp/hurd-i386/
> > ?
> 
> All working fine now!  What happens next?

Great :D

I'll commit it upstream and set a dep-wait in buildd for duma to be
retried with the newer glibc.

Samuel

[toc] | [prev] | [next] | [standalone]

#1111236

FromSamuel Thibault <sthibault@debian.org>
Date2022-07-28 17:30 +0200
Message-ID<EOdCx-epM1-3@gated-at.bofh.it>
In reply to#1111097
Peter B, le jeu. 28 juil. 2022 16:22:23 +0100, a ecrit:
> On 28/07/2022 16:00, Samuel Thibault wrote:
> > Peter B, le jeu. 28 juil. 2022 15:56:27 +0100, a ecrit:
> > > Tried your libc and also no difference.
> > The backtrace is exactly the same? I don't see how that can be, since my
> > patch makes __pthread_self return immediately when ___pthread_self is
> > NULL, and at
> > 
> > #21 0x0105146b in _init_routine (stack=<optimized out>) at ../sysdeps/mach/hurd/htl/pt-sysdep.c:66
> > 
> > has not yet be set to non-NULL.
> > 
> > Samuel
> 
> Hi Samuel,
> 
> Sorry, I just meant that the test program still fails.

That doesn't mean we didn't make progress. When several bugs have the
same end-user symptom, having just one kind of symptom doesn't mean
there is just one bug to fix, and getting the symptom doesn't mean one
hasn't progressed in fixing them.

> Here is the new (different) backtrace.

Could you install libc0.3-dbg as well so we get more details?

> Starting program: /home/demo/duma-2.5.21/dumatest
> 
> Thread 4 received signal ?, Unknown signal.
> 0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3
> #0  0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3
> #1  0x01052ae4 in __pthread_enable_asynccancel ()
>    from /lib/i386-gnu/libpthread.so.0.3
> #2  0x01198991 in write () from /lib/i386-gnu/libc.so.0.3
> #3  0x0803d802 in DUMA_Print (
>     pattern=0x803df60 <version> "DUMA, built 11/05/21 20:00:00 (static
> library)\nCopyright (C) 2006 Michael Eddington
> <meddington@gmail.com>\nCopyright (C) 2002-2009 Hayati Ayguen
> <h_ayguen@web.de>, Procitec GmbH\nCopyright (C) 1987-199"...) at print.c:331
> #4  0x0803ae86 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>)
>     at duma.c:905
> #5  0x0803aedd in duma_init () at duma.c:943
> #6  0x0803b2b6 in _duma_init () at duma.c:1138
> #7  0x0803c39a in _duma_malloc (size=716,
>     filename=0x803e060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
>     lineno=0) at duma.c:1966
> #8  0x0803cc9f in malloc (size=716) at duma.c:2424
> #9  0x0104c33d in __pthread_alloc () from /lib/i386-gnu/libpthread.so.0.3
> #10 0x0104c773 in __pthread_create_internal ()
>    from /lib/i386-gnu/libpthread.so.0.3
> #11 0x0105145b in _init_routine.part.0 () from /lib/i386-gnu/libpthread.so.0.3
> #12 0x0001164b in ?? () from /lib/ld.so
> #13 0x000117f5 in ?? () from /lib/ld.so
> #14 0x00002052 in ?? () from /lib/ld.so
> #0  0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3
> #1  0x01052ae4 in __pthread_enable_asynccancel ()
>    from /lib/i386-gnu/libpthread.so.0.3
> #2  0x01198991 in write () from /lib/i386-gnu/libc.so.0.3
> #3  0x0803d802 in DUMA_Print (
>     pattern=0x803df60 <version> "DUMA, built 11/05/21 20:00:00 (static
> library)\nCopyright (C) 2006 Michael Eddington
> <meddington@gmail.com>\nCopyright (C) 2002-2009 Hayati Ayguen
> <h_ayguen@web.de>, Procitec GmbH\nCopyright (C) 1987-199"...) at print.c:331
> #4  0x0803ae86 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>)
>     at duma.c:905
> #5  0x0803aedd in duma_init () at duma.c:943
> #6  0x0803b2b6 in _duma_init () at duma.c:1138
> #7  0x0803c39a in _duma_malloc (size=716,
>     filename=0x803e060 <unknown_file> "UNKNOWN (use #include \"duma.h\")",
>     lineno=0) at duma.c:1966
> #8  0x0803cc9f in malloc (size=716) at duma.c:2424
> #9  0x0104c33d in __pthread_alloc () from /lib/i386-gnu/libpthread.so.0.3
> #10 0x0104c773 in __pthread_create_internal ()
>    from /lib/i386-gnu/libpthread.so.0.3
> #11 0x0105145b in _init_routine.part.0 () from /lib/i386-gnu/libpthread.so.0.3
> #12 0x0001164b in ?? () from /lib/ld.so
> #13 0x000117f5 in ?? () from /lib/ld.so
> #14 0x00002052 in ?? () from /lib/ld.so
> 
> 
> Cheers,
> Peter
> 

> Starting program: /home/demo/duma-2.5.21/dumatest 
> 
> Thread 4 received signal ?, Unknown signal.
> 0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3
> #0  0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3
> #1  0x01052ae4 in __pthread_enable_asynccancel ()
>    from /lib/i386-gnu/libpthread.so.0.3
> #2  0x01198991 in write () from /lib/i386-gnu/libc.so.0.3
> #3  0x0803d802 in DUMA_Print (
>     pattern=0x803df60 <version> "DUMA, built 11/05/21 20:00:00 (static library)\nCopyright (C) 2006 Michael Eddington <meddington@gmail.com>\nCopyright (C) 2002-2009 Hayati Ayguen <h_ayguen@web.de>, Procitec GmbH\nCopyright (C) 1987-199"...) at print.c:331
> #4  0x0803ae86 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>)
>     at duma.c:905
> #5  0x0803aedd in duma_init () at duma.c:943
> #6  0x0803b2b6 in _duma_init () at duma.c:1138
> #7  0x0803c39a in _duma_malloc (size=716, 
>     filename=0x803e060 <unknown_file> "UNKNOWN (use #include \"duma.h\")", 
>     lineno=0) at duma.c:1966
> #8  0x0803cc9f in malloc (size=716) at duma.c:2424
> #9  0x0104c33d in __pthread_alloc () from /lib/i386-gnu/libpthread.so.0.3
> #10 0x0104c773 in __pthread_create_internal ()
>    from /lib/i386-gnu/libpthread.so.0.3
> #11 0x0105145b in _init_routine.part.0 () from /lib/i386-gnu/libpthread.so.0.3
> #12 0x0001164b in ?? () from /lib/ld.so
> #13 0x000117f5 in ?? () from /lib/ld.so
> #14 0x00002052 in ?? () from /lib/ld.so
> #0  0x0104d986 in pthread_mutex_lock () from /lib/i386-gnu/libpthread.so.0.3
> #1  0x01052ae4 in __pthread_enable_asynccancel ()
>    from /lib/i386-gnu/libpthread.so.0.3
> #2  0x01198991 in write () from /lib/i386-gnu/libc.so.0.3
> #3  0x0803d802 in DUMA_Print (
>     pattern=0x803df60 <version> "DUMA, built 11/05/21 20:00:00 (static library)\nCopyright (C) 2006 Michael Eddington <meddington@gmail.com>\nCopyright (C) 2002-2009 Hayati Ayguen <h_ayguen@web.de>, Procitec GmbH\nCopyright (C) 1987-199"...) at print.c:331
> #4  0x0803ae86 in duma_getenvvars (duma_tls=0x8047168 <_duma_g+8200>)
>     at duma.c:905
> #5  0x0803aedd in duma_init () at duma.c:943
> #6  0x0803b2b6 in _duma_init () at duma.c:1138
> #7  0x0803c39a in _duma_malloc (size=716, 
>     filename=0x803e060 <unknown_file> "UNKNOWN (use #include \"duma.h\")", 
>     lineno=0) at duma.c:1966
> #8  0x0803cc9f in malloc (size=716) at duma.c:2424
> #9  0x0104c33d in __pthread_alloc () from /lib/i386-gnu/libpthread.so.0.3
> #10 0x0104c773 in __pthread_create_internal ()
>    from /lib/i386-gnu/libpthread.so.0.3
> #11 0x0105145b in _init_routine.part.0 () from /lib/i386-gnu/libpthread.so.0.3
> #12 0x0001164b in ?? () from /lib/ld.so
> #13 0x000117f5 in ?? () from /lib/ld.so
> #14 0x00002052 in ?? () from /lib/ld.so


-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web