qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] qemu-i386 maple apt-get


From: Peter Maydell
Subject: Re: [Qemu-discuss] qemu-i386 maple apt-get
Date: Mon, 23 Nov 2015 21:51:48 +0000

On 23 November 2015 at 17:50, Franz-Josef Haider
<address@hidden> wrote:
> But this is a backtrace from directly launching cmaple.
> # qemu configure line: ./configure --prefix=/usr --static
> --target-list=i386-linux-user
>
> [1|address@hidden|~/MyDocs/maple13_i386/bin.IBM_INTEL_LINUX]LD_LIBRARY_PATH=/home/user/MyDocs/root.i686/lib:/home/user/MyDocs/maple13_i386/bin.IBM_INTEL_LINUX
> gdb /usr/bin/qemu-i386
> GNU gdb (GDB) 7.3.1-debian
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "arm-linux-gnueabi".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/bin/qemu-i386...(no debugging symbols
> found)...done.
> (gdb) run cmaple
> Starting program: /usr/bin/qemu-i386 cmaple
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x600104c0 in ?? ()
> (gdb) bt
> #0 0x600104c0 in ?? ()
> #1 0x6029b37c in ?? ()
> #2 0x6029b37c in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)

Can you try "info thread" here, and "thread apply all bt", please?

>
> And this with debugging symbols enabled:
> # qemu configure line: ./configure --prefix=/usr --enable-debug --static
> --target-list=i386-linux-user
>
> |\^/| Maple 13 (IBM INTEL LINUX)
> ._|\| |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2009
> \ MAPLE / All rights reserved. Maple is a trademark of
> <____ ____> Waterloo Maple Inc.
> | Type ? for help.

So a no-debug build doesn't crash? I suspect that this is just
bad luck that the commit in question happens to rearrange where
QEMU's code is in memory such that a random corruption or
other problem does or does not reveal obvious symptoms...

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]