Eclipse Community Forums: Test and Performance Tools Platform (TPTP)

Home » Archived » Test and Performance Tools Platform (TPTP) » Porting issue

Fri, 29 February 2008 07:51

Eclipse User

Originally posted by: ck2329.mail.ru

Dear TPTP commiters

Now im porting TPTP javaprofiler (JVMTI) to MIPS-based system running
under Linux. After long fight - im able to run ACServer and profiler libs.
Im able to connect to AC from eclipse gui, able to receive agent list.

Then im runnning my java application on MIPS target with attached HeapProf
:

java '-agentlib:JPIBootLoader=JPIAgent:server=enabled;CGProf' -jar
ConsumerProducer2.jar

Then im attaching to this process from Eclipse GUI(ussing Attach to Agent
feature). Then right click on process in Profiling Monitor window and then
i choose Start Monitoring.

Agent receives [Resume Command] but no data is transfered to Eclipse.

If i run same command line as above but in standalone mode - trace.trcxml
file has lot of info (and if i load this file to Eclipse then results are
OK)- thus i think my agent is able to collect data from JAVAVM.

So as i think problem may be in two parts - shared mem channel between AC
and agent or in socket channel between AC and Eclipse(sniffer shows that
only commands are passed between AC and Eclipse, but not data).

I cant see any errors in MARTINI log or AC server log :-(

What part of code should i examine to find out the reason of this issue?

Re: Porting issue [message #124867 is a reply to message #124852]

Fri, 29 February 2008 07:55

Eclipse User

Originally posted by: ck2329.mail.ru

I ported only ACServer and .so files from
AC_HOME\plugins\org.eclipse.tptp.javaprofiler\

Probably any java parts are required ???

Re: Porting issue [message #124901 is a reply to message #124867]

Fri, 29 February 2008 10:26

Eclipse User

Originally posted by: ck2329.mail.ru

Now i deternmined that in case of server=enabled agent doesnt receive
CECStartEvent from VM (in case of server=standalone event comes ). Thus
agent dosnt change m_profilerIsActive variable to the true state and
because of it agent doesnt send any info to AC

Re: Porting issue [message #124994 is a reply to message #124901]

Sun, 02 March 2008 04:01

Eclipse User

Andrew V. Novoselsky wrote:
> Now i deternmined that in case of server=enabled agent doesnt receive
> CECStartEvent from VM (in case of server=standalone event comes ). Thus
> agent dosnt change m_profilerIsActive variable to the true state and
> because of it agent doesnt send any info to AC
>

According to your description, the problem lies somewhere in the
communication channel between the workbench and the profiler runtime side.

The "server=standalone" mode instructs the profiling runtime to start
data collection immediately and to write all data into a trace file
(default is trace.trcxml). AC is not used in this mode.

In "server=enabled" mode, the profiling runtime waits for a "start"
command from the workbench. This command is sent to the Agent Controller
and directed to the ACCollector component of the JVMTI Profiler. This
component uses JPIAgent to translate this command into 2 "profiler
runtime" commands: ECAttach and ECStart. You may want to place some
logging code in strategic places to see where this chain breaks.

On a side note: have you considered contributing your work back to the
TPTP project? ;)

HTH,
Asaf

--
Asaf Yaffe
Eclipse TPTP Committer, JVMTI Profiler

Re: Porting issue [message #125056 is a reply to message #124994]

Mon, 03 March 2008 02:16

Eclipse User

Originally posted by: ck2329.mail.ru

Problem is not resolved yet. I will keep you informed.

Regarding contribution - now it is too yearly stage for considering this.
First i need to bring TPTP to work.

Re: Porting issue [message #125069 is a reply to message #124994]

Mon, 03 March 2008 06:16

Eclipse User

Originally posted by: ck2329.mail.ru

Now ECAttach and ECStart are ok

But i mentioned one more issue:

I have interactive app(which requires user input), when i start profiling
with server=enabled, i have following situiation -
1) Until i have no actions from Eclipse (like discover agent or something)
everething is OK - app is works normal. Im able to make input and see
output from app, also i can see that JVMTI events are coming to my
profiler.
2) When i try to attach to agent(using profiling menu in Eclipse) i see
following output (i compiled agent with debug options):
[AC command: SourceID:1 DestID:109 getContextID:-1
CommandName:notifyReference IID:org.eclipse.tptp.Agent]
And afterthat my test app seems to be dead - i cant do any input, no
events are coming from VM etc.

Do you have any suggestions ?

In case of offline degugging (server=standalone) everething is OK

Thanks in advance.

Re: Porting issue [message #125080 is a reply to message #125069]

Mon, 03 March 2008 06:22

Eclipse User

Originally posted by: ck2329.mail.ru

Uff... Just after posting previous message i found that if i do follwoing
steps
1) Start AC
2) Start profiling with server=enabled [App is OK]
3) Open Agents tab in Open Profile Dialog... dialog in Attach to Agent
4) JVMTI agent receives request from AC [App seems to be dead]
5) Kill AC process
6) App becomes OK !!!! it is possible to make input and see output

Re: Porting issue [message #125211 is a reply to message #125080]

Mon, 03 March 2008 08:24

Eclipse User

Andrew V. Novoselsky wrote:
> Uff... Just after posting previous message i found that if i do
> follwoing steps 1) Start AC
> 2) Start profiling with server=enabled [App is OK]
> 3) Open Agents tab in Open Profile Dialog... dialog in Attach to Agent
> 4) JVMTI agent receives request from AC [App seems to be dead]
> 5) Kill AC process
> 6) App becomes OK !!!! it is possible to make input and see output
>
>
>
Maybe this is related to the following bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=186080 ?

It was fixed in the 4.5 (HEAD) branch not long ago...

HTH,
Asaf

--
Asaf Yaffe
Eclipse TPTP Committer, JVMTI Profiler

Re: Porting issue [message #125222 is a reply to message #125211]

Mon, 03 March 2008 09:27

Eclipse User

Originally posted by: ck2329.mail.ru

Unfortunately bug fix has no effect :-(

Re: Porting issue [message #125226 is a reply to message #125211]

Mon, 03 March 2008 09:44

Eclipse User

Originally posted by: ck2329.mail.ru

Now PATCH works ! - Thank you.

but still no data is transfered to Eclipse GUI.

That is my own trace output from HeapProfiler, i see this output on every
allocation event.

as you can see jvmtiAgent_print is called - so i think i m close to
solution :-)

Krokodile: JPI/InternalObjectAllocHandler start #1(must be one more)
Krokodile: JPI/InternalObjectAllocHandler #2
Krokodile: JPI/InternalObjectAllocHandler called NotifyMpiEvent
Krokodile: JPI/CObjectAllocEventDispatcher start
Krokodile: JPI/CObjectAllocEventDispatcher calling
pConcreteObserver->HandleEvent
Krokodile: HeapProf/CObjAllocEvent start
Krokodile: JPIAgent/jvmtiAgent_print start m_jvmtiAgent_suspendIO=0.
Krokodile: JPIAgent/jvmtiAgent_print #1
Krokodile: JPIAgent/jvmtiAgent_print #2
Krokodile: JPIAgent/jvmtiAgent_print #3
Krokodile: JPIAgent/jvmtiAgent_print #4
Krokodile: JPIAgent/jvmtiAgent_print #5
Krokodile: JPIAgent/jvmtiAgent_print before enter Leave writing to
m_jvmtiAgent_outFile
Krokodile: JPIAgent/jvmtiAgent_print after Leave
Krokodile: HeapProf/CObjAllocEvent printing....
Krokodile: JPI/CObjectAllocEventDispatcher

Re: Porting issue [message #125305 is a reply to message #125226]

Tue, 04 March 2008 10:18

Eclipse User

Originally posted by: ck2329.mail.ru

Im still fighting :-)

Now i found that
DataProviderImpl::sendData(int destinationID, char buffer[], int
bufferLength, DIME_HEADER_PTR_T dimeHeader, int dimeHeaderLength)
doesnt send any data because
dataConn = getDataConnection(destinationID);(3rd row of function sendData)

returns 0

I also may say that according ro AC log :

Agent 'org.eclipse.tptp.jvmti' parsed xml cmd <Cmd dest="101" src="103"
ctxt="11"><establishDataPath
iid="org.eclipse.tptp.dataProvider"><dataConnectionID>-1</dataConnectionID ><flags>3</flags></establishDataPath></Cmd>
......
DataProviderImpl: processDataProviderCommands() called. Command name -
establishDataPath, source ID - 103, context ID - 11
......
DataProviderImpl: establishDataPath() called, connID -1

My profiler receives establishDataPath command from AC.

How can i know connection procedure sequence - i need it to check why
getDataConnection returns 0

Re: Porting issue [message #125326 is a reply to message #125305]

Tue, 04 March 2008 12:18

Eclipse User

Originally posted by: ck2329.mail.ru

Further investigation shows that hang up happends after following call
sequence:

[Agent receives establishDataPath command]
DataProviderImpl::establishDataPath
tptpStartThread(handleSharedMemMsg, (void *) dataConn, &tid, &th)
handleSharedMemMsg
ipcFlushToFunc(&(dataConn->agentMemBlockInfo),
sharedMemDataPathProcessorFunc, pRequestBlock)
ra_flushShmToFunc
ossRamboFlushToFunc

Threre is cycle with comments : /* Wait until the chunk is full or we
have been asked to stop or we have waited too long */ in function
ossRamboFlushToFunc - and thread stays forever in this cycle :-(

Re: Porting issue [message #125417 is a reply to message #125326]

Wed, 05 March 2008 08:04

Eclipse User

Originally posted by: ck2329.mail.ru

I'm still fighting...

Can anyone from TPTP commiters provide me with
Agent_to_AC_attach_procedure_sequence. This will allow me to find out
where the issue is.

Thanks in advance.

Now im fighting with shared memory transport layer - problem seems to be
caused by this part.
[off topic] I cannot understand why such a complicated data transport was
choosen for TPTP - it seems to be completely "closed". Files like
ossrambo, ossramboflush, ossipcmemory in RASharedMemory folder are
"superb" - it is impossible to maintain them without docs.[off topic end
:-(]

Re: Porting issue [message #125427 is a reply to message #125305]

Wed, 05 March 2008 08:18

Eclipse User

Hi Andrew,
Currently the following connection procedure in New AC is used. Hyades
clents and agents use other way.

This sequence assumes that at this stage Client already established
control channel to the AC.

Establishing Data Channel:

1. Client originates data channel to AC
1.1 Opens socket to AC
1.2 Sends to AC CONNECT_DATA command via 1.1
1.3 Gets responce from the AC (DATA_CONNECTION_COMPLETE) via 1.1
1.4 Extracts from the responce data channel id set by AC.

2. Client sends via control channel to the agent <establishDataPath..>
command with dataConnectionID from the point 1.4

3. Agent, receiving <establishDataPath..> command, establishes its own
data channel with AC.
3.1 Opens shared memory segment ("acbuffer" by default) created by the AC
3.2 Creates new shared memory segment ("acbuffer_clientId_agentId")
3.3 Sends CONNECT_DATA command to the AC via channel from the 3.1
3.4 Registers listener for channel 3.2 using ipcFlushToFunc() call
3.5 Receives responce from the AC and extracts data channel (3.2) id.

4. Agent requests from the AC binding of both connections:
4.1 Sends to the AC <bindDataConnection..> command with id from point
1.4 and id from the point 3.5. The command is sent via control channel
4.2 Receives from the AC <dataConnectionsBound..> responce via control
channel.

5. Agent sends to the Client <dataPathEstablished..> responce.

6. Client waits for the responce <dataPathEstablished..> and registers a
data listener for this channel.

Shared memory staff is platform dependant and should be ported.
You can check allocated shared memory segments by the ipcstat command line
system command.

Regards,
Igor

Re: Porting issue [message #125438 is a reply to message #125427]

Wed, 05 March 2008 08:49

Eclipse User

Originally posted by: ck2329.mail.ru

Hi Igor. Zdravstvuite :)

Thank you for full answer but in my case problem appears on 1.2 step.

On step 1.2 client calls DataProviderImpl::sendCONNECT_DATACommand(C++)
function[by the way - same function is present in java code] - and in this
function there is a call to ipcMemWrite. ipcMemWrite doesnt write to
sockets - it writes to SharedMem - is it correct ?

In my case ipcMemWrite writes 2 bytes to shmMem - and then this 2 bytes
are received by AC - but CONNECT_DATA_COMPLETE is not sent by AC.

Re: Porting issue [message #125452 is a reply to message #125427]

Wed, 05 March 2008 09:13

Eclipse User

Originally posted by: ck2329.mail.ru

Dear Igor - you wrote ->

3.4 Registers listener for channel 3.2 using ipcFlushToFunc() call

3.5 Receives responce from the AC and extracts data channel (3.2) id.

But in my previous post i mentioned that in my case i have following
situation :

[Agent receives establishDataPath command]

DataProviderImpl::establishDataPath

tptpStartThread(handleSharedMemMsg, (void *) dataConn, &tid, &th)

handleSharedMemMsg

ipcFlushToFunc(&(dataConn->agentMemBlockInfo)

sharedMemDataPathProcessorFunc, pRequestBlock)

ra_flushShmToFunc

ossRamboFlushToFunc

Threre is cycle with comments : /* Wait until the chunk is full or we
have been asked to stop or we have waited too long */ in function
ossRamboFlushToFunc - and thread stays forever in this cycle :-(

Thus 3.5 item never happends as i understood.

Regarding

1.2 Sends to AC CONNECT_DATA command via 1.1

1.3 Gets responce from the AC (DATA_CONNECTION_COMPLETE) via 1.1

processCONNECT_DATACall function is never called (but this function is the
only one which may send CONNECT_DATA_COMPLETE) - so i think AC doest
receive CONNECT_DATA command from agent.

Re: Porting issue [message #125463 is a reply to message #125438]

Wed, 05 March 2008 09:39

Eclipse User

Class DataProviderImpl is used on the agent side in the points 3.1-3.5.
Yes, ipcMemWrite() writes to the shared memory only.
You can try to debug the AC to find out why it doesn't send the responce.
It It seems that things are not so bad if you can read some bytes from the
shared memory on the AC side :)

Re: Porting issue [message #125475 is a reply to message #125452]

Wed, 05 March 2008 09:44

Eclipse User

Originally posted by: ck2329.mail.ru

Sorry for line breaks - i dont know why it happends.

Regarding 1.* items- ther was misunderstanding - i thought that client ==
agent. Now i understand that client == Eclipse - right ?

Re: Porting issue [message #125486 is a reply to message #125452]

Wed, 05 March 2008 09:54

Eclipse User

I refered to the Java client (org.eclipse.tptp.platform.execution)
Points 1.1-1.3 deal with sockets only.
AC processes this in transport/SocketTL/SocketListener.c module.

The idea of the data channel establishment is to get two single
connections: socket from the client to AC and shmem from the Agent to the
AC. And to bind them in the AC.

Re: Porting issue [message #125498 is a reply to message #125475]

Wed, 05 March 2008 09:55

Eclipse User

right :)

Re: Porting issue [message #125509 is a reply to message #125486]

Wed, 05 March 2008 10:11

Eclipse User

Originally posted by: ck2329.mail.ru

Got it.

But as i said before problem is with establishDataPath command. Agent
sends reply using shmMem channel - and then got no reply. In my agent log
i see that function sendCONNECT_DATACommand is called and 2 slots in
shared mem are marked as filled slots. Then in AC log i see that this 2
slots are received by AC, and then processTheMessageHeader is called for 2
times, but flags in msg are ZERO - > so CONNECT_DATA is not handeled by
AC

Re: Porting issue [message #125535 is a reply to message #125509]

Wed, 05 March 2008 11:17

Eclipse User

The received data are damaged?

Re: Porting issue [message #125545 is a reply to message #125535]

Wed, 05 March 2008 11:25

Eclipse User

Originally posted by: ck2329.mail.ru

Now i can see only zeros.

Actually now i'm trying to determine if AC receives same data as agent
writes to shm. But i'm not sure how to perform this check - can you
suggest the way?
BTW - i checked /tmp folder - acbuffer and acbuffer_clientID_agent_ID
files have zero size - is it correct ?

Re: Porting issue [message #125571 is a reply to message #125545]

Thu, 06 March 2008 02:34

Eclipse User

Can you compare received data with data sent by ipcMemWriteWithDIME()?
Dime - is 16 byte length header, added to every block.
You should port shared memory libraries to provide transparent data
channel.

You can check size of shmem segments with ipcstat command.
It might be more easy to test porting with SampleClientAC (execution
plugin) and TimeCollector agent.

Re: Porting issue [message #125621 is a reply to message #125571]

Thu, 06 March 2008 10:40

Eclipse User

Originally posted by: ck2329.mail.ru

Unfortunately i cannot compare ipcMemWriteWithDIME results - because
program fails earlier.

My agent&&AC fails on [ 3.3 Sends CONNECT_DATA command to the AC via
channel from the 3.1 ]. To be clear - shmem(with names
acbuffer_clientId_agentId and acbuffer) succesfully created and then
sendCONNECT_DATA function is called. i can see that this function writes
37 bytes(2 slots) to the shmem channel. Afterthat i see that 2 slots are
received by AC - but unfortunately something wrong with data - it seems
that all bytes are zeros.....

How can i check that the place AC is reading from is same as Agent is
writing to?
Speking in general - how can i track channel work.

Re: Porting issue [message #125633 is a reply to message #125621]

Thu, 06 March 2008 12:00

Eclipse User

DataProviderImpl::sendCONNECT_DATACommand() uses ipcMemWrite() call to
send command.
Can you compare data before call to ipcMemWrite() and the data in the AC?

This command is being sent via AC's main shmem segment - "acbuffer"

Re: Porting issue [message #125732 is a reply to message #125633]

Fri, 07 March 2008 04:43

Eclipse User

Originally posted by: ck2329.mail.ru

Dear Igor

You wrote:
"Can you compare data before call to ipcMemWrite() and the data in the AC?"

Actually i can print out what data ipcMemWrite writes to the shared mem -
it wirtes 37 bytes and mark 2 slots as filled. I also see that AC receives
2 filled slots - but when i print out this 2 slots - all bytes are 0. So
my question is - how can i check that address from which AC is reading
from is the same as Agent is writing to.

Regarding porting shared mem - i touched: ossatomic.h(to define operations
for my target processor) and ossatomictype.h(to set register as 32 bits)
- should i change something else?
BTW i build all parts with DEBUG define - can this cause a trouble ?

Re: Porting issue [message #125999 is a reply to message #125732]

Tue, 11 March 2008 07:02

Eclipse User

Originally posted by: ck2329.mail.ru

Now im comparing my debug trace outputs on windows and on my target system.

It look very similar - except one point - when i receive data and then
ossRamboFlushToFunc (ossramboflush.cpp) is called - then pMemBuffer is
callled - and membuffer is filled with 0. So data seems to be lost - how
can i check it?

Also you mentioned about ipcstat command - what is this and how to use it ?

One more - is there any "lowcost" way to replace shmem data channel with
named pipe or something else?

Re: Porting issue [message #126052 is a reply to message #125999]

Tue, 11 March 2008 08:59

Eclipse User

Hi Andrew,

ipcstat is the command to control named pipes, shmem.
You can use "man" to see details.

I beleive that shmem can be substituted by sockets or named pipes.
You see, in the scheme I sent, agent opens data channel and requests AC to
bind it. You can try to open socket or pipe channel and request to bind it
as well. Another side of this substitution is the cost of support of
profiler.
You will need to merge all changes in CVS with your code by yourself :(.

Re: Porting issue [message #126065 is a reply to message #126052]

Tue, 11 March 2008 09:18

Eclipse User

Originally posted by: ck2329.mail.ru

regarding ipcstat - im not able to find binaries or sources for it - the
only thing i found ipcs.

probably ill try to implement named pipe.

But anyway i wonder - what is the way for debugging shaerd memory channel
:-)

Re: Porting issue [message #126226 is a reply to message #126065]

Thu, 13 March 2008 03:56

Eclipse User

Originally posted by: ck2329.mail.ru

Dear Igor.

Now im throught with shmmem issues - problem was in incorrect use of
atomic operations on my platform - problem was resovled by not using
platform atomic operations - i used #if !defined
OSS_ATOMIC_USE_PLATFORM_INSTRUCTIONS branch.

Now AC is not able to send data ( profiling data from jvmti profiler
agent) to Client( Eclipse ) via socket.

As you wrote

1. Client originates data channel to AC
1.1 Opens socket to AC
1.2 Sends to AC CONNECT_DATA command via 1.1
1.3 Gets responce from the AC (DATA_CONNECTION_COMPLETE) via 1.1
1.4 Extracts from the responce data channel id set by AC.

2. Client sends via control channel to the agent <establishDataPath..>
command with dataConnectionID from the point 1.4

I checked 1.3 item - AC sends connection ID == 5000, but after that
Client(Eclipse) sends establishDatapath with connection ID == -1 , and
then (while binding) error happends, because AC cannot bind
AC&&Agent(ID==5001) with AC&&Client(ID==-1) connections.

Why this may happend?
How can i debug eclispe part - is there any logs or something?

Re: Porting issue [message #126254 is a reply to message #126226]

Thu, 13 March 2008 05:22

Eclipse User

Originally posted by: ck2329.mail.ru

Problem with sockets resolved now by rebuilding Eclipse plugin
org.eclipse.tptp.platform.execution.

Now i see that eclipse receives bytes - but "events processed" 0, still
fighting :-)

Re: Porting issue [message #126265 is a reply to message #126254]

Thu, 13 March 2008 06:43

Eclipse User

It might be useful to look at AC's log file. Set log level to DEBUG in the
AC's serviceconfig.xml and restart AC.

Re: Porting issue [message #126277 is a reply to message #126265]

Thu, 13 March 2008 07:11

Eclipse User

Originally posted by: ck2329.mail.ru

On Eclipse side ?

Re: Porting issue [message #126290 is a reply to message #126265]

Thu, 13 March 2008 07:49

Eclipse User

Originally posted by: ck2329.mail.ru

Do you mean set DEBUG level on Eclipse side? - i dont think it may help -
i dont run AC on PC(i run AC on remote target board and log file tells me
that data is sent to PC).

One more - which file should i check on Eclipse side to understand why
received bytes are not treated as events(on Eclipse status bur i see that
Eclipse receives ~100kb of data - but events counter is 0). Thanks.

Re: Porting issue [message #126353 is a reply to message #126290]

Thu, 13 March 2008 10:46

Eclipse User

Originally posted by: ck2329.mail.ru

One more question:

As i said in my very first message - im running target system on MIPS CPU
with linux and java machine target specific - should i rebuild TPTP
eclipse plugins or not ?

Re: Porting issue [message #126365 is a reply to message #126353]

Thu, 13 March 2008 10:47

Eclipse User

Originally posted by: ck2329.mail.ru

I meant rebuilt against my specific java machine and specific class path?

Re: Porting issue [message #126485 is a reply to message #126290]

Mon, 17 March 2008 03:58

Eclipse User

I mean Agent Controller's log file.
Since it resides between clients and agents, it might be useful to look at
this.

I'd suggest to start investigation with samples from TPTP Execution
Framework.
You can use SampleClientAC (org.eclipse.tptp.platform.execution) on the
Eclipse side and TimeCollector sample on the AC side. Please ensure that
agent's path in the agent.xml file is Linux like.

Andrew, we can move this long discussion to bugzilla.
Please open new one to do this.

Re: Porting issue [message #126497 is a reply to message #126353]

Mon, 17 March 2008 04:04

Eclipse User

You are launching AC on MIPS and using Eclipse on another
system(Windows/Linux)? You shouldn't rebuild Eclipse plugins.

Previous Topic:	probe targets and filters
Next Topic:	acserver crash if format in serviconfig.xml is spelled wrongly

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 22 18:07:13 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter