on device debugging, breakpoint does not work for some files.

[taycho1]

Hi,

In Codewarrior and Carbide, breakpoint does not work for some files when doing on device debugging.

In Codewarrior, I looked at the symbolics view of my process and found that only part of my application (composed of 20+ cpp files) exist. That's about 1/3, from the start of link order view. If I set breakpoint in one of those files exist in symbolics view, it works fine. If I set in other files, it does not work.

Strangely enough, if I change the order in Link Order view, additional 10 files are added to symbolics, not removing the first added ones. By doing this again, I successfully made it possible to set breakpoint to any file.

In Carbide, I couldn't find similar things so failed to set to 2/3 of the files. In this case XXX_S60_3_0_Phone(GCCE)_Debug_[S60_3rd_MR].exe list does only have 1/3 of files. For those listed files, breakpoint works fine.

I don't have any idea why this happens in Codewarrior or Carbide. Any idea or workaround?

Regards,
Tay

[mayankkedia]

Were you able to solve the issue..as i am also facing the same sort of problems..most of the times ODD doesnt hit the right breakpoints..how to resolve the same?

Cheers
mayank

[jplauril]

Are these breakpoints in static interface DLL's loaded by another static interface DLL? TRK can't see these, according to the on-device debugging guide shipped included with Carbide.

[lenclud]

I can't set any breakpoints at all in my application, so the on target debugger is just an on target application launcher That's all it does, nothing more.

When asking to break on entry point I get the following error message upon starting the debug session:

--------------------------------------------------------------
Error stopping at E32Main.
Reason: Target request failed: Symbol lookup failed in symbolics?
Continue?
Yes No
--------------------------------------------------------------

Our software solution includes quite a few DLLs, Servers EXEs and a large application.

[bytes]

Hi,

I too getting the same error.

Is this because of large number of files ( I have hundreds of files to built my exe).

Please let me know some pointers for this.

-Venu

I can't set any breakpoints at all in my application, so the on target debugger is just an on target application launcher That's all it does, nothing more.

When asking to break on entry point I get the following error message upon starting the debug session:

--------------------------------------------------------------
Error stopping at E32Main.
Reason: Target request failed: Symbol lookup failed in symbolics?
Continue?
Yes No
--------------------------------------------------------------

Our software solution includes quite a few DLLs, Servers EXEs and a large application.

[marta_rn]

Hi all ,

I am experimenting too the same problem. My issue is for UIQ 3.0, and TRK 2.8. I have read that might be because of the number or source files... any progress in this?
May another cause be involved?

Thanks for your help,

Marta

[Symbian_Neil]

Works fine with me.

I guess you might be missing something. One of the things that come to my mind is the bld.inf. Try to have a bld.inf in a format that it includes all the bld.inf's that are there in the entire project.

General format could be

PRJ_PLATFORMS

PRJ_MMPFILES

Under PRJ_MMPFILES
you could include all the bld.inf's with the relative path to this one.
example
#include "..\abc\pqr\bld.inf"
#include "..\def\bld.inf"
etc

[ruchirvasavada]

Hi,

Is this problem solved..??

I am facing exactly the same problem. My project has one EXE which is having multiple static libs. I wish to debug in the source code of one of the libs, but break point never gets resolved. I can set the breakpoints in some files, which are directly compiled in the exe.

Additionally, in the executable view of Carbide (v 1.3 Professional), I don't get to see the *.cpp files related to the the exe file. I always get an error message which is something like this...

"An error occured. See error log for more details. Reason -120917130".

The detailed error log was really a long list. The initial line of that detailed page was something like this --> java.lang.ArrayIndexOutOfBoundsException: -120917130.

Can someone throw some light on above issues..??

Thanks,
Ruchir

[aml_1989]

I've had the problem before, and found it was because of my PKG file.

Check it does reference to the \gcce\udeb\ folder.

Full path can be copied/pasted from Executables tab, to the right of Console.

Andy.

[Symbian_Neil]

I've had the problem before, and found it was because of my PKG file.

Check it does reference to the \gcce\udeb\ folder.

Full path can be copied/pasted from Executables tab, to the right of Console.

Andy.

Rather than hard-code, you could use a more flexible path in the source like :

"$(EPOCROOT)Epoc32\release\$(PLATFORM)\$(TARGET)\abc.exe"

Works well in carbide, but note, it might not work if you are in habit of using commandline.

[ruchirvasavada]

I have checked the path in the PKG file. Things are all fine but problem still persists....

Upon further investigating this problem, I could dig out that the breakpoints remain unresolved only in the source files for one of the many LIBs. Breakpoints in rest all files are getting resolved properly. Again, the way static library are arranged in the main MMP file is also playing some role in this.

I have seen many threads on this issue.. looks like this is an endemic problem... I have initiated a new thread also in hope to get some reply..

[mpinsonneault]

Please start by upgrading to v1.3 and see if the problem persists.

Regards,

Matt P.

[MKechlibar]

I have absolutely the same problem here. Even with the latest build (34) of Carbide.c++ 1.3.1. Again, my workspace is huge, some 40 DLLs and about a thousand source files, if not more.

I cannot hit breakpoints in any DLL or
even the GUI application, not even E32Main. The message is:

Error stopping at E32Main.
Reason: Target request failed: Symbol lookup failed in symbolics?
Continue?
Yes No

I cannot even see the RDebug::Print messages from the debugged application. Also, the following two strange things happen.

First, during the launch of the ODD process, it spends awful time in "Launching delegate" and "Connecting to backend..." phases. An order of 2 minutes and more. This was not the case with beta versions of 1.3, the startup used to be really quick, but now it happens even in older Carbide.c++ 1.3 builds. So, my guess is that something is wrong with the workspace.

After these 2 minutes, the app launches, but symbol lookup fails.

Following those problems, I installed an older version of Carbide, namely 1.3.0, build 24. The situation was not much better. Startup of the ODD process still took about 2 minutes, and symbol lookup failed once again. The only positive result was that I could see the RDebug::Print messages in the Unframed data log.

I tried all of the above with TRKs 2.8.9, 2.8.6 and 2.7.0. The behavior was still the same.

The 2-minute with the "Connecting to backend..." message is extremely strange. I tried to:

- restart Windows, no difference
- uninstall Nokia PC Suite, no difference
- stop firewall and antivirus, no difference

I cannot think of any other possible external cause of this pause and failure of ODD. There is a strange log in the workspace's log file:

!ENTRY org.eclipse.debug.core 4 120 2008-06-05 15:18:11.375
!MESSAGE Error logged from Debug Core:
!STACK 0
org.omg.CORBA.BAD_OPERATION: vmcid: SUN minor code: 231 completed: No
at com.sun.corba.se.impl.logging.ORBUtilSystemException.extractObjectFailed(Unknown Source)
at com.sun.corba.se.impl.logging.ORBUtilSystemException.extractObjectFailed(Unknown Source)
at com.sun.corba.se.impl.corba.AnyImpl.extract_Object(Unknown Source)
at com.freescale.cdt.debug.cw.CWCorbaMgr.anyToObject(Unknown Source)
at com.freescale.cdt.debug.cw.CWCallback.SharedLibraryLoaded(Unknown Source)
at cwdbg.DebuggerCallbackPOA._invoke(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(Unknown Source)
at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(Unknown Source)
at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(Unknown Source)
at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(Unknown Source)
at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(Unknown Source)
Caused by: org.omg.CORBA.TypeCodePackage.BadKind
at com.sun.corba.se.impl.corba.TypeCodeImpl.id(Unknown Source)
... 14 more

and such a log is created each time I try to ODD.

I tried to create a new empty workspace and import one of the hello-world applications from S60Ex into it. This time, on-device debugging worked and no strange log in the log file! So I have a strong suspicion that the problem is workspace-related.

I have tried to remove the .settings subdirectory of the workspace, and re-create the workspace again, with all the 40-something projects on place. The behavior did not change at all. Still 2-minute pause and then failure to find symbols.

Is it possible that Carbide.c++ cannot manage a too-big-workspace?

I must admit that I am totally desperate.

[mpinsonneault]

I have absolutely the same problem here. Even with the latest build (34) of Carbide.c++ 1.3.1. Again, my workspace is huge, some 40 DLLs and about a thousand source files, if not more.

I cannot hit breakpoints in any DLL or
even the GUI application, not even E32Main.

I think we need to get engineering involved in this one. Have you used our Bugzilla system? Please go to https://xdabug001.ext.nokia.com/bugzilla/, create a login, and submit this issue there. We'll get an engineer in touch with you and see if we can track down what's going on.

Regards,

Matt P.

[wapawapa]

As Matt said, let's get these issues into Bugzilla so we can get Nokia engineers looking at them. It sounds like there are two different problems.

1) Some executables are built with symbolics for only some of the source files. I have not seen this before and suspect it's specific to something in your source code. Either GCCE (I assume, or are you using RVCT?) is not generating the symbolics properly, or our Dwarf2 reader is seeing something it doesn't like and bailing out part way through. Please log a Bugzilla for this and attach an executable that shows the problem. We don't need source code. You can make the attachment private if you have concerns about others seeing it.

2) The other issue is the "Target request failed: Symbol lookup failed in symbolics" error and the probably related OmniOrb exceptions in the error log. Let's get this logged as well. In the meantime, I'm curious if you can debug that helloworld example from your existing workspace. That should tell us if it's a problem with the workspace itself or just the project you're trying to debug.