Patrick,
  This bug looks like dup of bug #332427

*** Bug 333092 has been marked as a duplicate of this bug. ***

*** Bug 333093 has been marked as a duplicate of this bug. ***

I tried more steps in console and I found log will be crash after call getcellvalue.

Patrick: Trace for log crash ?

Steps:
1. Go to Evolution-Tasks
2. In python,
   from ldtp import *
   getcellvalue ('frmEvolution-Tasks','tblTasks',0,2)
   log ('test','info')

Crash:
 pstack core
core 'core' of 2797:
-----------------  lwp# 1 / thread# 1  --------------------
 d2768a35 __pollsys (80fa320, 2, 0, 0) + 15
 d272afde poll     (80fa320, 2, ffffffff) + 52
 d253ab35 g_main_context_iterate (80a4438, 1, 1, 80a4d20) + 399
 d253b172 g_main_loop_run (80aa800) + 1ba
 d211f40e bonobo_main (d23a00e0, d2500960, 80472f8, d238c098, d27fb840, 804731c) + 5e
 d238ea30 cspi_main (d27fb840, 804731c, d27fd8f0, 804731c, 8061b08, 7fffffff) + 18
 d238c098 SPI_event_main (7fffffff, 7fffffff, 2, 0, 0, 0) + 18
 08061b08 main     (0, 804734c, 8047350) + 108
 08060efa _start   (0, 0, 8047484, 80474a5, 80474c6, 8047603) + 7a
-----------------  lwp# 2 / thread# 2  --------------------
 d2768a35 __pollsys (d24b9fc4, 1, 0, 0) + 15
 d272afde poll     (d24b9fc4, 1, ffffffff) + 52
 080618d2 ldtp_server_thread (0) + 62
 d2767744 _thr_setup (d24e2400) + 51
 d2767990 _lwp_start (d24e2400, 0, 0, 0, 0, 0)
-----------------  lwp# 3 / thread# 3  --------------------
 d27237c2 realfree (809c49c) + 48
 d2723e34 cleanfree (0) + 59
 d272328e _malloc_unlocked (8, 0, 3, d26c3f84, 7ffffff2, 8100b9d) + a2
 d27231c7 malloc   (4) + 37
 d263e113 xmlStrndup (8110f48, 3) + 37
 d263e180 xmlStrdup (8110f48) + 34
 d263e8dd xmlStrcat (0, 8110f48) + 49
 d25f04c6 xmlNodeListGetString (810ee88, 8103ca0, 1) + 13a
 080661f4 ldtp_request_fill_request (80a7940, 8103f78, 80, d1fedfa0) + 194
 080641fb handle_request (80fd800, 810b7b8, d1fedfa0) + 3b
 08065a78 handle_client (80ab2e0) + 338
 d2767744 _thr_setup (d1ed0000) + 51
 d2767990 _lwp_start (d1ed0000, 0, 0, 0, 0, 0)
-----------------  lwp# 4 / thread# 4  --------------------
 d2768a35 __pollsys (8100090, 9, 0, 0) + 15
 d272afde poll     (8100090, 9, ffffffff) + 52
 d253ab35 g_main_context_iterate (8100f40, 1, 1, 80fe7d0) + 399
 d253b172 g_main_loop_run (80ffb50) + 1ba
 d22c7732 link_io_thread_fn (0) + 1e
 d2554383 g_thread_create_proxy (80fe7d0) + 11b
 d2767744 _thr_setup (d1ed0400) + 51
 d2767990 _lwp_start (d1ed0400, 0, 0, 0, 0, 0)

Created attachment 61288 [details] [review]
Proposed patch

Assuming that this patch should fix the crash

Patrick: Comitted in CVS, can you please check it ?

Verified.

I checkout and build by gcc. This bug fixed. But I still got crash when I use Dave's build. We use the same source but Dave use Sun CBE build environment.

bash-3.00$ pstack ./core
core './core' of 748:   ldtp
-----------------  lwp# 1 / thread# 1  --------------------
 d2768d25 __pollsys (80faab0, 2, 0, 0) + 15
 d272b292 poll     (80faab0, 2, ffffffff) + 52
 d253aa61 g_main_context_iterate (80a5778, 1, 1, 809ebc8) + 399
 d253b09e g_main_loop_run (80ab900) + 1ba
 d210f3b2 bonobo_main (d2390050, d2500960, 8047238, d237c00c, d27fb840, 804725c) + 5e
 d237e9a4 cspi_main (d27fb840, 804725c, d27fd8f0, 804725c, 8061c18, 7fffffff) + 18
 d237c00c SPI_event_main (7fffffff, 7fffffff, 2, 0, 0, 0) + 18
 08061c18 main     (1, 8047284, 804728c) + 108
 0806100a _start   (1, 80473d4, 0, 80473d9, 804740d, 8047422) + 7a
-----------------  lwp# 2 / thread# 2  --------------------
 d2768d25 __pollsys (d24b9fc4, 1, 0, 0) + 15
 d272b292 poll     (d24b9fc4, 1, ffffffff) + 52
 080619e2 ldtp_server_thread (0) + 62
 d2767a34 _thr_setup (d24e2400) + 51
 d2767c80 _lwp_start (d24e2400, 0, 0, 0, 0, 0)
-----------------  lwp# 3 / thread# 3  --------------------
 d27238c2 realfree (809d1fc) + 48
 d2723f34 cleanfree (0) + 59
 d27233c3 _malloc_unlocked (20, d1fddef0, 1b, d25a3e38, d1fdde7c, d253fad3) + d7 d27232c7 malloc   (1b) + 37
 d253fad3 standard_malloc (1b) + 1b
 d253fb82 g_malloc (1b) + 32
 d255f450 g_vasprintf (d1fddef0, 8088224, d1fddf38) + 38
 d254f93b g_strdup_vprintf (8088224, d1fddf38) + 2b
 d2541b4d g_print  (8088224, 80aba38) + 2d
 080664e9 ldtp_request_fill_request (80a8a60, 80ff700, f6, d1fddfa0) + 1e9
 080642bb handle_request (80fe800, 811f168, d1fddfa0) + 3b
 08065cc8 handle_client (80ac440) + 338
 d2767a34 _thr_setup (d1ec0000) + 51
 d2767c80 _lwp_start (d1ec0000, 0, 0, 0, 0, 0)
-----------------  lwp# 4 / thread# 4  --------------------
 d2768d25 __pollsys (80f99d8, 9, 0, 0) + 15
 d272b292 poll     (80f99d8, 9, ffffffff) + 52
 d253aa61 g_main_context_iterate (8103c00, 1, 1, 8103c88) + 399
 d253b09e g_main_loop_run (81005c8) + 1ba
 d22b773a link_io_thread_fn (0) + 1e
 d2554267 g_thread_create_proxy (8103c88) + 11b
 d2767a34 _thr_setup (d1ec0400) + 51
 d2767c80 _lwp_start (d1ec0400, 0, 0, 0, 0, 0)

Based on comment #10 reopening the bug.

Created attachment 63786 [details] [review]
Sun CBE build environment patch based on comment #10

Patrick, can you please verify this ?

Sorry for so late. Now I tried July 4th build. 
getcellvalue ( frmEvolution-Tasks , tblTasks , 0 , 2 ) 
return nothing. May be a regression on getcellvalue.

getcellvalue ( frmEvolution-Tasks , tblTasks , 0 , 2 ) 

gives me the right answer

It should return the title of the first task.
I tried gecellvalue for tblMessage in Mail and it also return nothing.

yes, I am seeing expected behaviour only. I get

getcellvalue ('frmEvolution-Inbox*','ttblMessages',0,4) --> Mail subject
getcellvalue ('frmEvolution-Tasks','tblTasks',0,2) --> Task name

Output in my system:

bash-3.00$ python
Python 2.4.2 (#1, Jun  2 2006, 20:49:53) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> from ldtp import *
>>> getcellvalue ('frmEvolution-Inbox*','ttblMessages',0,4)
getcellvalue ( frmEvolution-Inbox* , ttblMessages , 0 , 4 )
>>>



Search key based on regular expression: frmEvolution-Inbox*
Search key based on regular expression: frmEvolution-Inbox*
Property: parent - Value: evolution-2.6
app_name: evolution-2.6
Property: label - Value: Evolution - Inbox (9 total)
window_name: Evolution - Inbox (9 total)
Appname: evolution-2.6
Accessible application name: evolution-2.6
Application: evolution-2.6      - Role: application
Child count: 1 of evolution-2.6
Stripped space: Evolution-Inbox(9total)
Before strip Evolution - Inbox (9 total) - After Evolution-Inbox(9total)
Locale MSG: Evolution - Inbox (9 total) - UTF8 - Evolution - Inbox (9 total)
Context: Evolution - Inbox (9 total) In_Locale:  D     ution - Inbox (9 total) Child_name: Evolution - Inbox (9 total)
Window: frmEvolution-Inbox* - Object: ttblMessages
Property: child_index - Value: 0
Property: parent - Value: uknMessages
Parent name: uknMessages - Context name: frmEvolution-Inbox*
Property: uknMessages - Value:

Property: child_index - Value: 0
Property: parent - Value: scpn1
Parent name: scpn1 - Context name: frmEvolution-Inbox*
Property: scpn1 - Value:

Property: child_index - Value: 0
Property: parent - Value: splt1
Parent name: splt1 - Context name: frmEvolution-Inbox*
Property: splt1 - Value:

Property: child_index - Value: 1
Property: parent - Value: flr6
Parent name: flr6 - Context name: frmEvolution-Inbox*
Property: flr6 - Value:

Property: child_index - Value: 0
Property: parent - Value: pnl29
Parent name: pnl29 - Context name: frmEvolution-Inbox*
Property: pnl29 - Value:

Property: child_index - Value: 0
Property: parent - Value: pnl28
Parent name: pnl28 - Context name: frmEvolution-Inbox*
Property: pnl28 - Value:

Property: child_index - Value: 0
Property: parent - Value: ptab1
Parent name: ptab1 - Context name: frmEvolution-Inbox*
Property: ptab1 - Value:

Property: child_index - Value: 0
Property: parent - Value: ptl1
Parent name: ptl1 - Context name: frmEvolution-Inbox*
Property: ptl1 - Value:

Property: child_index - Value: 1
Property: parent - Value: splt0
Parent name: splt0 - Context name: frmEvolution-Inbox*
Property: splt0 - Value:

Property: child_index - Value: 0
Property: parent - Value: flr2
Parent name: flr2 - Context name: frmEvolution-Inbox*
Property: flr2 - Value:

Property: child_index - Value: 2
Property: parent - Value: pnl0
Parent name: pnl0 - Context name: frmEvolution-Inbox*
Property: pnl0 - Value:

Property: child_index - Value: 0
Property: parent - Value: flr0
Parent name: flr0 - Context name: frmEvolution-Inbox*
Property: flr0 - Value:

Property: child_index - Value: 0
Property: parent - Value: frmEvolution-Inbox(9total)
Parent name: frmEvolution-Inbox(9total) - Context name: frmEvolution-Inbox*
Property: label - Value: Messages
Label: Messages - Messages
Locale MSG: Messages - UTF8 - Messages
Object matches
Tree table - number of rows:9   Column: 6
Child type is 55 Table cell is a text object
resp_len = 117
Sending..
149
Response packet: <?xml version="1.0" encoding="utf-8"?><RESPONSE><ID>944590199</ID><STATUS><CODE>0</CODE><MESSAGE>Successfully completed</MESSAGE></STATUS></RESPONSE>
Msg:
Bytes sent: 153
Client packet len: 0
<cause>Packet received from client is not valid</cause>
handle_client: error:
resp_len = 117
Sending..
170

the response packet that I receive is something like this:

Response packet: <?xml version="1.0" encoding="utf-8"?><RESPONSE><ID>466343861</ID><STATUS><CODE>0</CODE><MESSAGE>Successfully completed</MESSAGE></STATUS><DATA><LENGTH>14</LENGTH><VALUE><![CDATA[Happy New year]]></VALUE></DATA></RESPONSE>
Msg:
Bytes sent: 226


Patrick: Are you using the latest CVS code for ldtp? or are you running ldtp 0.3.1 (as indicated in the title?) I think you will not face this problem in the latest code.

(In reply to comment #18)
> the response packet that I receive is something like this:
> 
> Response packet: <?xml version="1.0"
> encoding="utf-8"?><RESPONSE><ID>466343861</ID><STATUS><CODE>0</CODE><MESSAGE>Successfully
> completed</MESSAGE></STATUS><DATA><LENGTH>14</LENGTH><VALUE><![CDATA[Happy New
> year]]></VALUE></DATA></RESPONSE>
> Msg:
> Bytes sent: 226
> 
> 
> Patrick: Are you using the latest CVS code for ldtp? or are you running ldtp
> 0.3.1 (as indicated in the title?) I think you will not face this problem in
> the latest code.
> 

I guess so. I got ldtp latest package from our RE, Dave who did some automatic nightly build from cvs. I will make sure with him about this build. 

I think this has been fixed Upstream. Can someone verify this?

Patrick, can you verify that this is fixed? 

Verified in latest build.