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 11:31:33 +0500

I just tried it on Windows XP and its working fine there. So this
problem comes only on Windows 7.

-Taimoor

On Thu, Aug 29, 2013 at 12:10 AM, Taimoor Mirza <address@hidden> wrote:
> 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]