[Qemu-devel] [Bug 1068900] [NEW] Thread cancellation broken in app-level emulation

[Qemu-devel] [Bug 1068900] [NEW] Thread cancellation broken in app-level emulation

[Bugdal]

Public bug reported:

Thread cancellation (and certain other implementation-internal things
such as set*id() and timers) are implemented in userspace on Linux by
stealing a couple of the realtime signals for internal use by the
implementation, leaving them unavailable to applications. Unfortunately,
this bites qemu application-level emulation when the application being
run uses thread cancellation or other features that need such signals.
The signal handler is unable to be set (because sigaction on the host
rejects the signal numbers) and attempts to send the signals result in
it being received not by the emulated application code, but by the
libc/libpthread code on which qemu is running; this in turn seems to
cause qemu to crash.

The best solution I can think of is for qemu to steal one of the
realtime signals for its own use, and multiplex signal numbers outside
the range SIGRTMIN..SIGRTMAX, as well as the stolen signal itself, on
top of this stolen signal. This would both allow cancellation to work,
and would allow applications the full range of realtime signals when the
guest has more signals than the host (e.g. MIPS running on x86 host).

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1068900

Title:
  Thread cancellation broken in app-level emulation

Status in QEMU:
  New

Bug description:
  Thread cancellation (and certain other implementation-internal things
  such as set*id() and timers) are implemented in userspace on Linux by
  stealing a couple of the realtime signals for internal use by the
  implementation, leaving them unavailable to applications.
  Unfortunately, this bites qemu application-level emulation when the
  application being run uses thread cancellation or other features that
  need such signals. The signal handler is unable to be set (because
  sigaction on the host rejects the signal numbers) and attempts to send
  the signals result in it being received not by the emulated
  application code, but by the libc/libpthread code on which qemu is
  running; this in turn seems to cause qemu to crash.

  The best solution I can think of is for qemu to steal one of the
  realtime signals for its own use, and multiplex signal numbers outside
  the range SIGRTMIN..SIGRTMAX, as well as the stolen signal itself, on
  top of this stolen signal. This would both allow cancellation to work,
  and would allow applications the full range of realtime signals when
  the guest has more signals than the host (e.g. MIPS running on x86
  host).

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1068900/+subscriptions

[Qemu-devel] [Bug 1068900] Re: Thread cancellation broken in app-level emulation

[Bugdal]

Patch for the issue is available here:

https://lists.eait.uq.edu.au/pipermail/microblaze-
linux/2012-October/005760.html

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1068900

Title:
  Thread cancellation broken in app-level emulation

Status in QEMU:
  New

Bug description:
  Thread cancellation (and certain other implementation-internal things
  such as set*id() and timers) are implemented in userspace on Linux by
  stealing a couple of the realtime signals for internal use by the
  implementation, leaving them unavailable to applications.
  Unfortunately, this bites qemu application-level emulation when the
  application being run uses thread cancellation or other features that
  need such signals. The signal handler is unable to be set (because
  sigaction on the host rejects the signal numbers) and attempts to send
  the signals result in it being received not by the emulated
  application code, but by the libc/libpthread code on which qemu is
  running; this in turn seems to cause qemu to crash.

  The best solution I can think of is for qemu to steal one of the
  realtime signals for its own use, and multiplex signal numbers outside
  the range SIGRTMIN..SIGRTMAX, as well as the stolen signal itself, on
  top of this stolen signal. This would both allow cancellation to work,
  and would allow applications the full range of realtime signals when
  the guest has more signals than the host (e.g. MIPS running on x86
  host).

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1068900/+subscriptions

[Qemu-devel] [Bug 1068900] Re: Thread cancellation broken in app-level emulation

[Aurelien Jarno]

** Changed in: qemu
       Status: New => Fix Committed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1068900

Title:
  Thread cancellation broken in app-level emulation

Status in QEMU:
  Fix Committed

Bug description:
  Thread cancellation (and certain other implementation-internal things
  such as set*id() and timers) are implemented in userspace on Linux by
  stealing a couple of the realtime signals for internal use by the
  implementation, leaving them unavailable to applications.
  Unfortunately, this bites qemu application-level emulation when the
  application being run uses thread cancellation or other features that
  need such signals. The signal handler is unable to be set (because
  sigaction on the host rejects the signal numbers) and attempts to send
  the signals result in it being received not by the emulated
  application code, but by the libc/libpthread code on which qemu is
  running; this in turn seems to cause qemu to crash.

  The best solution I can think of is for qemu to steal one of the
  realtime signals for its own use, and multiplex signal numbers outside
  the range SIGRTMIN..SIGRTMAX, as well as the stolen signal itself, on
  top of this stolen signal. This would both allow cancellation to work,
  and would allow applications the full range of realtime signals when
  the guest has more signals than the host (e.g. MIPS running on x86
  host).

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1068900/+subscriptions

[Qemu-devel] [Bug 1068900] Re: Thread cancellation broken in app-level emulation

[Bugdal]

Arg, somehow I added the above comment on the wrong bug. Thus bug is not
fixed. The other bug report I recently filed was fixed.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1068900

Title:
  Thread cancellation broken in app-level emulation

Status in QEMU:
  Fix Committed

Bug description:
  Thread cancellation (and certain other implementation-internal things
  such as set*id() and timers) are implemented in userspace on Linux by
  stealing a couple of the realtime signals for internal use by the
  implementation, leaving them unavailable to applications.
  Unfortunately, this bites qemu application-level emulation when the
  application being run uses thread cancellation or other features that
  need such signals. The signal handler is unable to be set (because
  sigaction on the host rejects the signal numbers) and attempts to send
  the signals result in it being received not by the emulated
  application code, but by the libc/libpthread code on which qemu is
  running; this in turn seems to cause qemu to crash.

  The best solution I can think of is for qemu to steal one of the
  realtime signals for its own use, and multiplex signal numbers outside
  the range SIGRTMIN..SIGRTMAX, as well as the stolen signal itself, on
  top of this stolen signal. This would both allow cancellation to work,
  and would allow applications the full range of realtime signals when
  the guest has more signals than the host (e.g. MIPS running on x86
  host).

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1068900/+subscriptions

[Qemu-devel] [Bug 1068900] Re: Thread cancellation broken in app-level emulation

[Aurelien Jarno]

** Changed in: qemu
       Status: Fix Committed => New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1068900

Title:
  Thread cancellation broken in app-level emulation

Status in QEMU:
  New

Bug description:
  Thread cancellation (and certain other implementation-internal things
  such as set*id() and timers) are implemented in userspace on Linux by
  stealing a couple of the realtime signals for internal use by the
  implementation, leaving them unavailable to applications.
  Unfortunately, this bites qemu application-level emulation when the
  application being run uses thread cancellation or other features that
  need such signals. The signal handler is unable to be set (because
  sigaction on the host rejects the signal numbers) and attempts to send
  the signals result in it being received not by the emulated
  application code, but by the libc/libpthread code on which qemu is
  running; this in turn seems to cause qemu to crash.

  The best solution I can think of is for qemu to steal one of the
  realtime signals for its own use, and multiplex signal numbers outside
  the range SIGRTMIN..SIGRTMAX, as well as the stolen signal itself, on
  top of this stolen signal. This would both allow cancellation to work,
  and would allow applications the full range of realtime signals when
  the guest has more signals than the host (e.g. MIPS running on x86
  host).

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1068900/+subscriptions

[Qemu-devel] [Bug 1068900] Re: Thread cancellation broken in app-level emulation

[Thomas Huth]

The URL from comment #1 is unfortunately not valid anymore. If this
issue is still pending, could you please post your patch again to the
qemu-devel mailing list to get it discussed and included? Thanks!

** Changed in: qemu
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1068900

Title:
  Thread cancellation broken in app-level emulation

Status in QEMU:
  Incomplete

Bug description:
  Thread cancellation (and certain other implementation-internal things
  such as set*id() and timers) are implemented in userspace on Linux by
  stealing a couple of the realtime signals for internal use by the
  implementation, leaving them unavailable to applications.
  Unfortunately, this bites qemu application-level emulation when the
  application being run uses thread cancellation or other features that
  need such signals. The signal handler is unable to be set (because
  sigaction on the host rejects the signal numbers) and attempts to send
  the signals result in it being received not by the emulated
  application code, but by the libc/libpthread code on which qemu is
  running; this in turn seems to cause qemu to crash.

  The best solution I can think of is for qemu to steal one of the
  realtime signals for its own use, and multiplex signal numbers outside
  the range SIGRTMIN..SIGRTMAX, as well as the stolen signal itself, on
  top of this stolen signal. This would both allow cancellation to work,
  and would allow applications the full range of realtime signals when
  the guest has more signals than the host (e.g. MIPS running on x86
  host).

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1068900/+subscriptions

[Qemu-devel] [Bug 1068900] Re: Thread cancellation broken in app-level emulation

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1068900

Title:
  Thread cancellation broken in app-level emulation

Status in QEMU:
  Expired

Bug description:
  Thread cancellation (and certain other implementation-internal things
  such as set*id() and timers) are implemented in userspace on Linux by
  stealing a couple of the realtime signals for internal use by the
  implementation, leaving them unavailable to applications.
  Unfortunately, this bites qemu application-level emulation when the
  application being run uses thread cancellation or other features that
  need such signals. The signal handler is unable to be set (because
  sigaction on the host rejects the signal numbers) and attempts to send
  the signals result in it being received not by the emulated
  application code, but by the libc/libpthread code on which qemu is
  running; this in turn seems to cause qemu to crash.

  The best solution I can think of is for qemu to steal one of the
  realtime signals for its own use, and multiplex signal numbers outside
  the range SIGRTMIN..SIGRTMAX, as well as the stolen signal itself, on
  top of this stolen signal. This would both allow cancellation to work,
  and would allow applications the full range of realtime signals when
  the guest has more signals than the host (e.g. MIPS running on x86
  host).

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1068900/+subscriptions