Your message dated Mon, 25 Mar 2024 18:31:02 +0000
with message-id <e1rop66-00ebia...@fasolo.debian.org>
and subject line Bug#1066993: Removed package(s) from unstable
has caused the Debian Bug report #370060,
regarding Segmentation fault if linked with the pthread library
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
370060: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370060
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libpcl1
Version: 1.6-1

I have a situation on the ARM platform where if I compile an executable to use
both libpcl and libpthread, then even if I'm not actually using threads,
trying to do anything to a coroutine causes an immediate segmentation fault.

To replicate:

$ gcc /usr/share/doc/libpc1-dev/examples/cobench.c -lpcl
--> produces working executable.
$ ldd ./a.out
        libpcl.so.1 => /usr/lib/libpcl.so.1 (0x4001e000)
        libc.so.6 => /lib/libc.so.6 (0x40029000)
        /lib/ld-linux.so.2 (0x40000000)

gcc /usr/share/doc/libpc1-dev/examples/cobench.c -lpcl -lpthread
--> produces failing executable.
$ ldd ./a.out
        libpcl.so.1 => /usr/lib/libpcl.so.1 (0x4001e000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x40029000)
        libc.so.6 => /lib/libc.so.6 (0x40083000)
        /lib/ld-linux.so.2 (0x40000000)

The reason why this is an issue is that I have an application which uses
coroutines, but not pthreads, which wants to link to the sqlite library. When
sqlite was built, it was done so with its threading support enabled; which
means that it tries to call mutex primitives in the pthreads library. This
means that linking an application against libsqlite will implicitly pull in
libpthread, which then causes it to fail.

This actually sounds suspiciously similar to a problem I previously
encountered on the i386, Debian bug 339827. To summarise: on i386 when running
a sufficiently old kernel that does not have thread-local storage, the
threading library figures out which thread is running by the location of the
stack pointer. If the application has allocated a user stack, it fails to cope
and crashes. This means that calling any thread-safe function which needs to
know what the calling thread is will fail when it is called from any user stack.

The only workaround I've got for this is to recompile sqlite without threading
support, which is painful.

Architecture:
Linux pyanfar 2.6.15-1-nslu2 #2 Tue Mar 7 17:36:32 UTC 2006 armv5tel GNU/Linux

Debian version:
Etch (current)


Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---
--- Begin Message ---
Version: 1.12-2+rm

Dear submitter,

as the package libpcl1 has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1066993

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmas...@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)

--- End Message ---

Reply via email to