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

[Taimoor Mirza]

Kindly ignore last email.......it is reproducible on XP as well.

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