[Qemu-devel] [Bug 1594394] Re: Using setreuid / setegid crashes x86_64 user-mode target

2017-12-20 Thread VinceLe
I guess this is happening to my attempts to use pbuilder for cross-
building armel / mipsel packages

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

Title:
  Using setreuid / setegid crashes x86_64 user-mode target

Status in QEMU:
  New

Bug description:
  When setreuid() or setegid() are called from x86_64 target code in
  user mode, qemu crashes inside the NPTL signal handlers.  x86 targets
  do not directly use a syscall to handle setreuid() / setegid();
  instead the x86 NPTL implementation sets up a temporary data region in
  memory (__xidcmd) and issues a signal (SIGRT1) to all threads,
  allowing the handler for that signal to issue the syscall.  Under
  qemu, __xidcmd remains null (see variable display below backtrace).

  Backtrace:
  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0x3fff85c74fc0 (LWP 74517)]
  0x6017491c in sighandler_setxid (sig=33, si=0x3fff85c72d08, 
ctx=0x3fff85c71f90) at nptl-init.c:263
  263 nptl-init.c: No such file or directory.
  (gdb) thread apply all bt

  Thread 3 (Thread 0x3fff87e8efc0 (LWP 74515)):
  #0  0x601cc430 in syscall ()
  #1  0x60109080 in futex_wait (val=, ev=) at /build/qemu/util/qemu-thread-posix.c:292
  #2  qemu_event_wait (ev=0x62367bb0 ) at 
/build/qemu/util/qemu-thread-posix.c:399
  #3  0x6010f73c in call_rcu_thread (opaque=) at 
/build/qemu/util/rcu.c:250
  #4  0x60176f8c in start_thread (arg=0x3fff87e8efc0) at 
pthread_create.c:336
  #5  0x601cebf4 in clone ()

  Thread 2 (Thread 0x3fff85c74fc0 (LWP 74517)):
  #0  0x6017491c in sighandler_setxid (sig=33, si=0x3fff85c72d08, 
ctx=0x3fff85c71f90) at nptl-init.c:263
  #1  
  #2  0x601cc42c in syscall ()
  #3  0x60044b08 in safe_futex (val3=, uaddr2=0x0, 
timeout=, val=, op=128, uaddr=) at 
/build/qemu/linux-user/syscall.c:748
  #4  do_futex (val3=, uaddr2=275186650880, timeout=0, val=1129, 
op=128, uaddr=275186651116) at /build/qemu/linux-user/syscall.c:6201
  #5  do_syscall (cpu_env=0x1000abfd350, num=, 
arg1=275186651116, arg2=, arg3=1129, arg4=0, arg5=275186650880, 
arg6=, arg7=0, arg8=0)
  at /build/qemu/linux-user/syscall.c:10651
  #6  0x600347b8 in cpu_loop (env=0x1000abfd350) at 
/build/qemu/linux-user/main.c:317
  #7  0x60036ae0 in clone_func (arg=0x3fffc4c2ca38) at 
/build/qemu/linux-user/syscall.c:5445
  #8  0x60176f8c in start_thread (arg=0x3fff85c74fc0) at 
pthread_create.c:336
  #9  0x601cebf4 in clone ()

  Thread 1 (Thread 0x1000aa05000 (LWP 74511)):
  #0  0x601cc430 in syscall ()
  #1  0x60044b08 in safe_futex (val3=, uaddr2=0x0, 
timeout=, val=, op=128, uaddr=) at 
/build/qemu/linux-user/syscall.c:748
  #2  do_futex (val3=, uaddr2=1, timeout=0, val=1, op=128, 
uaddr=275078324992) at /build/qemu/linux-user/syscall.c:6201
  #3  do_syscall (cpu_env=0x1000aa23890, num=, 
arg1=275078324992, arg2=, arg3=1, arg4=0, arg5=1, 
arg6=, arg7=0, arg8=0) at /build/qemu/linux-user/syscall.c:10651
  #4  0x600347b8 in cpu_loop (env=0x1000aa23890) at 
/build/qemu/linux-user/main.c:317
  #5  0x600020e4 in main (argc=, argv=, 
envp=) at /build/qemu/linux-user/main.c:4779
  (gdb) p __xidcmd
  $1 = (struct xid_command *) 0x0

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



[Qemu-devel] [Bug 1583420] Re: Please support "-soundhw none"

2017-08-11 Thread VinceLe
It looks like qemu without any specific -soundhw CLI option uses pulseaudio.
So I still think a -soundhw none would be nice to have.

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

Title:
  Please support "-soundhw none"

Status in QEMU:
  Invalid

Bug description:
  qemu currently provides a default set of sound hardware.  The -soundhw
  option can change that default set, such as by using "-soundhw pcspkr"
  to disable most of it, but no "-soundhw none" option exists to disable
  all of it.  As far as I can tell, disabling the default sound hardware
  requires specifying -nodefaults and then manually specifying all the
  desired hardware, leaving out sound hardware.

  Please consider adding support for "-soundhw none", to disable all the
  default sound hardware.

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



[Qemu-devel] [Bug 717628] [NEW] qemu should ungrab mouse cursor where it is located in guest OS

2011-02-12 Thread VinceLe
Public bug reported:

When ungrabbing with CTRL-ALT, the host OS mouse cursor should be warped
at the location it was inside the guest OS for better user experience.

The same should be done with grabbing, when the window is clicked and
the focus grabbed from the host OS, the mouse should be warped in the
guest to the location where the click happened.

The rationale is, that it is the same mouse pointer and it should not
appear to change location when un/grabbing...

** 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/717628

Title:
  qemu should ungrab mouse cursor where it is located in guest OS

Status in QEMU:
  New

Bug description:
  When ungrabbing with CTRL-ALT, the host OS mouse cursor should be
  warped at the location it was inside the guest OS for better user
  experience.

  The same should be done with grabbing, when the window is clicked and
  the focus grabbed from the host OS, the mouse should be warped in the
  guest to the location where the click happened.

  The rationale is, that it is the same mouse pointer and it should not
  appear to change location when un/grabbing...