qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Problems with QEMU sdcard while using glib 2.33.8


From: Taimoor Mirza
Subject: Re: [Qemu-devel] Problems with QEMU sdcard while using glib 2.33.8
Date: Thu, 29 Aug 2013 00:10:48 +0500

Hi Stefan,

Below is result of bt:

Breakpoint 1, 0x006ac304 in abort ()
(gdb) bt
#0  0x006ac304 in abort ()
#1  0x00553052 in _fu10846____stack_chk_guard () at qemu-coroutine.c:111
#2  0x0040d746 in _fu473____stack_chk_guard () at block.c:4294
#3  0x00413cc7 in _fu805____stack_chk_guard () at block.c:2530
#4  0x00413cc7 in _fu805____stack_chk_guard () at block.c:2530
#5  0x00414875 in bdrv_rw_co_entry (opaque=0xa90f8d8) at block.c:2172
#6  _fu836____stack_chk_guard () at block.c:2167
#7  0x004439f8 in _fu1936____stack_chk_guard () at coroutine-win32.c:57
#8  0x767dbff2 in KERNEL32!GetQueuedCompletionStatus ()
   from C:\windows\syswow64\kernel32.dll
#9  0x035e3be8 in ?? ()
#10 0x767dbfaa in KERNEL32!GetQueuedCompletionStatus ()
   from C:\windows\syswow64\kernel32.dll
#11 0x019c3c70 in ?? ()
Cannot access memory at address 0xa080000
(gdb)

Thanks,
Taimoor

On Wed, Aug 28, 2013 at 6:38 PM, Stefan Hajnoczi <address@hidden> wrote:
> On Wed, Aug 28, 2013 at 04:17:24PM +0500, Taimoor Mirza wrote:
>> Thanks for your reply. Below are answers
>>
>> $ grep CONFIG_COROUTINE_BACKEND config-host.mak
>> CONFIG_COROUTINE_BACKEND=win32
>>
>> (gdb) r
>> Starting program: C:\tools\qemu\qemu-system-arm.exe
>> -M realview-eb -m 256 -kernel Debug\\\\KD2.out -sd fat:16:rw:C:\\testCard
>> [New Thread 3836.0x404]
>> [New Thread 3836.0x87c]
>> [New Thread 3836.0xd14]
>> [New Thread 3836.0xc58]
>> [Inferior 1 (process 3836) exited with code 03]
>> (gdb) bt
>> No stack.
>
> It seems that gdb on Windows does not catch abort(3) - perhaps because
> SIGABRT is not used (on Linux gdb will intercept SIGABRT and return to
> the gdb prompt).
>
> So you may need to set a breakpoint on abort(3) instead:
>
>  (gdb) b abort
>  (gdb) r
>  [...runs until abort(3) is called...]
>  (gdb) bt



reply via email to

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