It only works on non-ARM because they use getcontext() by default. If
picking the setjmp/longjmp mechanism, x86 has the same behaviour as
descibed in comment 10. glibc performs the same sanity check in longjmp
for all archs.
I have mailed the upstream author a week ago pointing him to this
bugrepo
Jani, thanks for the explanation; I wonder why this works on non-ARM
arches though.
Should we open a bug upstream so that pth disabled FORTIFY_SOURCE on ARM
if it's in the default compiler options?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
I overlooked there was a gpg related bug here. Anyway gpg-agent works
with the latest pth now - the abort was due to FORTIFY_SOURCE enabled
extra checks in every longjmp call.
There is no bug in glibc/eglibc , but pth relies on some tricks which
are not guaranteed to work and indeed they fail star
I thought there was a runtime issue as well (not just make test)?! (The
original bug mentions some abort when using gnupg.)
I understand that when getcontext() is missing, pth defaults to another
pth backend which either is broken in pth itself or exposes a bug in
eglibc; I'd like to make sure th
@Loïc these are not really issues with longjmp itself, pth relies on a behavior
which was changed in glibc 2.11
the failing test case is the one in pth (make test)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad
Do we have a bug and/or a test case to track the setjmp() issues (which
apparently aren't ARM specific)?
I filed bug #696794 to track the lack of getcontext() on ARM in eglibc,
with a task to revert these pth changes once eglibc provides
getcontext().
--
You received this bug notification becaus
This bug was fixed in the package pth - 2.0.7-16ubuntu2
---
pth (2.0.7-16ubuntu2) natty; urgency=low
* debian/rules: disable FORTIFY_SOURCE for armel build, as it breaks
the sigjmp/longjmp mechanism used on ARM for user space threading.
(Closes LP: #599862)
-- Jani Monoses
It happens on ARM only because it does not have the getcontext() API so
a different implementation is used for user context switching.
On non-ARM one can select the setjmp based implementation (all 3 args must be
given or it will be a mix of setjmp/ucontext and it won't build) by via
configure
e
** Changed in: pth (Ubuntu)
Assignee: (unassigned) => Linaro Foundations (linaro-foundations)
** Changed in: pth (Ubuntu)
Importance: Undecided => High
** Changed in: pth (Ubuntu)
Status: New => Triaged
--
pth_init() aborts on armel with "longjmp causes uninitialized stack frame"
This patch demonstrates a possible workaround, which enables the pth
tests to pass.
This match modifies a generated file: it should be applied after running
configure.
The stack pointer is hacked immediately before calling the longjmp
family of functions, so that the sanity-check in the longjmp
i
Looks like there's a check for longjmp decreasing the sp, which was
merged from eglibc upstream revision 2.11~20100104.
see http://bazaar.launchpad.net/%7Eubuntu-
branches/ubuntu/maverick/eglibc/maverick/annotate/head%3A/ports/sysdeps/unix/sysv/linux/arm/longjmp_chk.S
--
pth_init() aborts on
Looks like the failure might be restricted to armel because of the
unavailability of the ucontext API:
checking for ucontext.h... yes
checking for makecontext... no
checking for swapcontext... no
checking for getcontext... no
checking for setcontext... no
checking for usable SVR4/SUSv2 makecontext
OK, the source of scariness seems to be in pth_mctx.c which does some
evil-looking things in order to implement userspace threading.
In order to switch threads with an accompanying switch of stack,
setjmp() is called from inside a signal handler which has an alternate
signal stack set up. [1]
egl
** Patch added: "debugging patch to demonstrate the above"
https://bugs.launchpad.net/ubuntu/+source/pth/+bug/599862/+attachment/1520809/+files/pth_debug.diff
--
pth_init() aborts on armel with "longjmp causes uninitialized stack frame"
https://bugs.launchpad.net/bugs/599862
You received thi
Narrowed this down a bit further... the error appears to happen in the
call to pth_spawn() at pth_lib.c:pth_init():95.
Building with the attached diff demonstrates this:
=== TESTING GLOBAL LIBRARY API ===
Fetching library version
version = 0x200207
=== TESTING BASIC OPERATION ===
Initializing
15 matches
Mail list logo
