RE:[ptp-dev] Question about the process set of ptp debugger

[jiangyangtz <yangtzj@xxxxxxxxxxx>]

> Date: Sat, 09 Jun 2007 11:06:54 +1000
> From: Clement Kam Man Chu <clement.chu@xxxxxxxxxxxxxxxxxxxxxx>
> Subject: Re: Fwd: [ptp-dev] Question about the process set of ptp
> debugger
> To: Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
> Message-ID: <4669FD2E.6060505@xxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
Hi Clement,
 
Thanks a lot for your detailed answer.

> 
> What version of ptp are you using now?
 
Unfortunately, I'm still using ptp v1.0.
The reason we still stick to ptp ver1.0 is that we have maken lots of change to ptp 1.0 so as to 
adapt it to our system. I will describe our system requirements and what we have done in another mail.
 

> 
> >> Recently I have encounted a confusing problem about the process set 
> >> operation when dealing with ptp parallel debugger.
> >> Let me describe the problem first.
> >> I have a parallel job with 4 processes and group process 0,1 and 2 
> >> to process set 0. Now I have two process sets: set0 and the Root set.
> >> Then I set a line breakpoint on process set0,i.e on process 0,1,2. 
> >> Everything goes well by now. Then when I try to set a line 
> >> breakpoints on the Root set,
> >> The UI pops a dialog window with the following message: "Error on 
> >> task:0-3"
> >>
> I tested on ptp 1.1 version and I didn't get the problem you mentioned.
> >> What causes this error?
> >> After tracing the execution of "sdm" client, we find that for the 
> >> second debug request (setting line breakpoint on Root set), there are 
> >> two responses from sdm client to UI. One response contains process 
> >> 0,1,2 and the other contains process 3.
> >>
> If there are two process sets, sdm will send two events to UI. From
> your case, the problem seems on UI side because you still got two events
> from sdm.
> >> For the second debug request, when all 4 processs return their 
> >> replies, sdm client tries to respond t o UI. However, there are two 
> >> HashEntry entries in the current
> >> "r->events" hash table. One entry is for process 0,1,2 and th other 
> >> entry for process 3. This is caused by the fact that the hash value 
> >> of the debug message from process 3 is different from the one for 
> >> process 0,1,2 since the current breakpoint number of process 3 is 1 
> >> while the current breakpoint number of process 0,1,2 is 2.
> >> It is the two hash entries that cause two reponses to UI.
> >>
> >> So, does this mean that a process cann't belong to more than 1 
> >> process set?
> >> Or two process sets in a job cann't have common elements?
> >> Or more, it is not allowed to change a process from one process set 
> >> to another process set duing a debug session?
> Even if there are two events from sdm, the breakpoint id should be the same.
> 
> 
> For example, UI requested to set breakpoint for process set "root"
> (0-3). "SetBreakpoint" command will be sent to sdm which is contained
> process (0-3). In the first event back, this event only contains
> process (0-2). Then UI will still be waiting until all processes (0-3)
> got the event back. When UI is received the second event, UI will check
> whether the process of "SetBreakpoint" command is the same as the
> process of the total events back from sdm. If they are the same, then
> UI will set breakpoint on source editor. If UI does not receive any
> event back within a specified time, it will throw a timeout exception.
>
 
We have overcome this problem with some modification to the UI code.
Anyway, thanks for your help!

> 
> Each process can be added / removed in a process set in any time.
> However, I found a bug on setting breakpoint in a process set.
> 
> For example:
> 
> for (int i=0; i<10; i++) {
> printf("test a");
> printf("test b");
> }
> 
> If set0 set a breakpoint on line "test a" and root set a breakpoint on
> line "test b", a debugger should stop on line "test a" (0, 1, 2) and
> "test b" (3). If I remove process (1, 2) from set0, then only process
> (0) should be stopped on line "test a" on next time. The bug is that
> process (0, 1, 2) still stop on line "test a". I will fix this problem
> on the latest ptp version.
> 
En..
There are still some other bugs on the BPMap operations.
 
1. in gdbmi_backend.c, AddBPMap():
   after finding an empty  bpentry (remote == -1), filling the bpenty  and increasing BPMap.nels, 
we should break the "for" loop otherwise all empty entry will be used. So "break"  should be called after "BPMap.nels++"
 
2. also in gdbmi_backend.c, RemoveBPMap(),
    for (i = 0; i < BPMap.nels; i++) //loop condition1
should be 
    for (i =  0; i < BPMap.size; i++) //loop condition2
    
    The reason is that: if we have 3 breakpoints , say ,0,1,2. Under condition 1, we must delete from 2,then 1, finally 0, 
    while condition 2 allows any operation oder!
 
 
   Also, function FindLocalBP(), FindRemoteBP() and RemoveAllBPmap() should use BPMap.size to replace BPMap.nels!
 
 
  
Best regards,
Jie Jiang

---

中国十大热门旅游景点 了解更多信息！