This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re : [gdbserver][WinCE][ARM] gdbserver crash: issue with GetThreadContext???
- From: Matthieu H <maat_h at yahoo dot fr>
- To: gdb at sourceware dot org
- Date: Thu, 10 Feb 2011 13:22:18 +0000 (GMT)
- Subject: Re : [gdbserver][WinCE][ARM] gdbserver crash: issue with GetThreadContext???
- References: <391678.86646.qm@web29502.mail.ird.yahoo.com>
- Reply-to: Matthieu H <mhameau at yahoo dot fr>
well, maybe the fix is correct???
When I apply my "patch", here is the output I have.
The debug crashs before reaching the function though :-(
$ ./gdb haret-debug.exe
GNU gdb 6.8
Copyright (C) 2008 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 "--host=i686-pc-cygwin --target=arm-mingw32ce"...
(gdb) b mmu_trampoline
Breakpoint 1 at 0x2ec14: file src/wince/asmstuff.S, line 149.
(gdb) target remote 169.254.2.1:9999
Remote debugging using 169.254.2.1:9999
warning: Can not parse XML target description; XML support was disabled at
compile time
[New Thread 1983314530]
warning: Can not parse XML library list; XML support was disabled at compile
time
0x00000000 in ?? ()
(gdb) continue
Continuing.
[D:SMEM] smem_heap_info: static, address = 0x615030c0
Remote APIs client DLL attached
[14:11:38][haret-debug.exe][1983314530]DEB_HTC_PATH = SOFTWARE\HTC\
[A][I][haret-48][XT9IME]IME_Engine_Western: 2.2.20123425.00
[AutoTestLib] Inittialize called by SIPIME
[AutoTestLib] Fails : Open registry key : SIPIME
[A][I][haret-48][XT9IME]++ [ImeInquire]
[A][I][haret-48][XT9IME]-- [ImeInquire] elapsed time = 3
[A][I][haret-48][XT9IME]++ [ImeSetActiveContext]
[A][I][haret-48][XT9IME]++ [ImeSetActiveContext]
[A][I][haret-48][XT9IME]-- [ImeSetActiveContext] elapsed time = 4
[A][I][haret-48][XT9IME]++ [ImeSetActiveContext]
[A][R][haret-48][XT9IME][ShareMemory::create] m_pData = 53f00004 m_size 12
m_status 1
[A][I][haret-48][XT9IME]++ [eT9ImeMgr::LoadObjects]
[A][R][haret-48][XT9IME][ShareMemory::create] m_pData = 53c00004 m_size 36440
m_status 1
[A][R][haret-48][XT9IME][ShareMemory::create] m_pData = 53d00004 m_size 4864
m_status 1
[A][R][haret-48][XT9IME][InternalDBBuffer::Load] databaseFile =
\Windows\eT9.HQD.kdb
[A][R][haret-48][XT9IME][ShareMemory::create] m_pData = 5f700004 m_size 695
m_status 1
[A][R][haret-48][XT9IME][InternalDBBuffer::Load] m_buffer = 5f700004
[A][R][haret-48][XT9IME][ShareMemory::create] m_pData = 5f800004 m_size 20480
m_status 1
[A][R][haret-48][XT9IME][ShareMemory::create] m_pData = 5f900004 m_size 3200
m_status 1
[A][R][haret-48][XT9IME][ShareMemory::create] m_pData = 5fa00004 m_size 20480
m_status 1
[A][R][haret-48][XT9IME][InternalDBBuffer::Load] databaseFile =
\Windows\FRlsUN_xt9s.ldb
[A][R][haret-48][XT9IME][ShareMemory::create] m_pData = 5fb00004 m_size 117129
m_status 1
[A][R][haret-48][XT9IME][InternalDBBuffer::Load] m_buffer = 5fb00004
[A][R][haret-48][XT9IME][ShareMemory::create] m_pData = 5fc00004 m_size 21840
m_status 1
[A][I][haret-48][XT9IME]-- [eT9ImeMgr::LoadObjects] elapsed time = 4124
[A][I][haret-48][XT9IME][IME] GetGlobalMode: eMode = 1
[A][I][haret-48][XT9IME][IME] eT9ImeMgr::GetSIPStyleFromAP: unspecified
[A][I][haret-48][XT9IME][IME] eT9ImeMgr::GetSIPStyleFromAP2: NORMAL_STATE
[A][I][haret-48][XT9IME][IME] eT9ImeMgr::GetSIPStyleFromAP2: NORMAL_STATE
[A][I][haret-48][XT9IME][IME] eT9ImeMgr::NotifySipSpecialUI: NORMAL_STATE
[A][I][haret-48][XT9IME][AT_WRITE_STATEVAR] CurrentET9Style: 0
[A][I][haret-48][XT9IME][IME] SetMode :1
[A][I][haret-48][XT9IME]-- [ImeSetActiveContext] elapsed time = 4182
[A][I][haret-48][XT9IME]++ [eT9ImeMgr::LoadObjects]
[A][I][haret-48][XT9IME]-- [eT9ImeMgr::LoadObjects] elapsed time = 3
[A][I][haret-48][XT9IME][IME] GetGlobalMode: eMode = 1
[A][I][haret-48][XT9IME][IME] eT9ImeMgr::GetSIPStyleFromAP: unspecified
[A][I][haret-48][XT9IME][IME] eT9ImeMgr::GetSIPStyleFromAP2: NORMAL_STATE
[A][I][haret-48][XT9IME][IME] eT9ImeMgr::GetSIPStyleFromAP2: NORMAL_STATE
[A][I][haret-48][XT9IME][IME] eT9ImeMgr::NotifySipSpecialUI: NORMAL_STATE
[A][I][haret-48][XT9IME][AT_WRITE_STATEVAR] CurrentET9Style: 0
[A][I][haret-48][XT9IME][IME] SetMode :1
[A][I][haret-48][XT9IME]-- [ImeSetActiveContext] elapsed time = 4247
[D:DISP]QComSurf::convert_888_to_8888_asm - m_nWidth = 17, m_nHeight = 80,
(uint32*)srcPtr = 0x5a06ab1c, src_stride = 4294967244d, (uint32*)ptr=
0x54083000, m_n
StrideBytes = 128
Remote connection closed
----- Message d'origine ----
> De : Matthieu H <maat_h@yahoo.fr>
> À : gdb@sourceware.org
> Envoyé le : Jeu 10 février 2011, 11h 59min 29s
> Objet : [gdbserver][WinCE][ARM] gdbserver crash: issue with
GetThreadContext???
>
> Hello guys,
>
> I'm trying to do a remote debug using following tools:
> HOST is a PC => gdb v6.8 compiled with gcc (i686 mingw32) under latest cygwin
> environment
> TARGET is a HTC Windows Mobile 6.5 phone (based on WinCE 5.2) powered by ARM11
>
> MSM7227 => gdbserver v6.8 compiled under Ubuntu 10.0 with cegcc v0.55
> (arm-mingw32ce)
>
> I'm having an issue with gdbserver, it is crashing immediately when I launch
>it.
> Here are the traces I get (without my debug messages):
> > Starting inferior
> > Process /haret/haret-debug.exe created; pid = 2012847982
> then process crash without further message.
> It is not even listening to connections, I even dont launch gdb on host side,
>it
>
> crashs by itself without any help :-)
>
> I put some traces, and I figured out that the call to function
> GetThreadContext(), in arm_get_thread_context() in win32-arm-low.c was somehow
>
> corrupting the "current_inferior" ptid global data, causing the function
> "current_inferior_ptid()" to return 0.
>
> The program crashes in child_fetch_inferior_registers() at this line:
> > win32_thread_info *th = thread_rec (current_inferior_ptid (), TRUE);
> Call to current_inferior_pid() returns 0, causing thread_rec(...) to crash
>when
>
> trying to get the thread data context.
>
> I tried many things:
> - looking for known bugs in gdb bug database (nothing found)
> - looking for this kind of bug in gdb mailing list (nothing found)
> - looking the different revisions of source code in gdb CVS and trying
>different
>
> modifications (not worked)
> - i tried with gbdserver v6.7, v6.8, v7.2 but no success
>
> I'm running out of solutions here...
> The only workaround I found was to replace this line by this one:
> /* Fetch register(s) from the current thread context. */
> static void
> child_fetch_inferior_registers (struct regcache *regcache, int r)
> {
> int regno;
> - win32_thread_info *th = thread_rec (current_inferior_ptid (), TRUE);
> + win32_thread_info *th = thread_rec (current_inferior_ptid (), FALSE);
>
> This tells gdbserver not to load the context of the thread (=it does not call
> GetThreadContext() so "current_inferior" is not corrupted)
> It's a dirty workaround cause I believe the thread context is required when
> debugging!
> But at least I can connect using gdb on my host PC.
> The program crash later anyway, I believe the workaround is not good :-)
>
> Can you please help me?
> Any idea what could be wrong?
>
> GetThreadContext returns value "TRUE", meaning function succeed... maybe
> arguments are wrong... but I'm not expert in gdb enough to say that.
>
> Many thanks for your kind help
>
> Matthieu
>
>
>
>