qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Christof Schulze <christof.schulze@gmx.net>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] qemu-user + networking issues / segfaults
Date: Sat, 24 Aug 2013 00:21:57 +0200	[thread overview]
Message-ID: <1516087.xyo50bTIdQ@siegfried> (raw)

[-- Attachment #1: Type: text/plain, Size: 2428 bytes --]

Hello qemu-devel list,

This is my first post to this list and I am not sure whether this
actually is the correct Mailinglist.  I recently compiled qemu-1.6.0
on an arm platform for the purpose of running the binary only
otrdecoder-software which is available for a 64bit linux only. I
pursued the following steps:
* creating a chroot on my x64-box that contained the otrdecoder and
  all libraries it needs to run
* test-run the otrdecoder from within the chroot (it works)
* copying this chroot to my arm box, where I compiled qemu previously
* copying qemu and all required libs to the chroot
* copying a shell to the chroot
* copying libnss* libraries from my 64bit system and from my arm
  system to the chroot
* test network connectivity from within the chroot using native
  nslookup and native ping (it works)
* from within the chroot I ran the otrdecoder using qemu-x86_64 which
  works up to a point where it segfaults.
  
running qemu using the -strace flag and comparing the output with a
successful strace from my 64bit-box reveals that the segfault happens
after an munmap and before (or at) the spot where a socket() operation
is run.

This is the operation that should be run:
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3

I am not sure if qemu segfaults because 
* there are actually libs missing in the chroot 
* the syscall is not supported
* the binary does crazy things and is not supported by qemu-user
  
At the same time running the 64bit version of ping results in a
segfault as well which might be related.

this is what the segfault of the otrdecoder shows:
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
SYS_369(0, 0x4, 0, 0xbe9f6d48, 0x4)     = 0
SYS_369(0, 0x4, 0, 0xbe9f8dd8, 0x4)     = 0
SYS_369(0, 0x4, 0xbe9f8dd8, 0, 0xbe9f8dd8) = 0
futex(0xb6dcf7d0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(2, "qemu: uncaught target signal 11 "..., 67qemu: uncaught target signal 
11 (Segmentation fault) - core dumped
) = 67
rt_sigaction(SIGSEGV, {SIG_DFL, ~[RTMIN RT_1], SA_INTERRUPT|SA_NODEFER|
0x5199d28}, NULL, 8) = 0
kill(30161, SIGSEGV)                    = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

What can I do to investigate further and get this fixed besides trying
to emulate a full-blown system?

Christof

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

             reply	other threads:[~2013-08-23 22:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-23 22:21 Christof Schulze [this message]
2013-08-29 21:27 ` [Qemu-devel] qemu-user + networking issues / segfaults Christof Schulze
2013-09-04 15:35   ` Richard Henderson
2013-09-06 10:38     ` [Qemu-devel] qemu-user-x86_64 segfaults on armv5 (WAS: qemu-user + networking issues / segfaults) Christof Schulze
2013-09-06 21:28       ` Christof Schulze

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1516087.xyo50bTIdQ@siegfried \
    --to=christof.schulze@gmx.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).