CodeLite IDE

verifed as implemented in version 2.5.x, thanks a lot Eran!

Hint: option added into debugger settings

still a problem on windows xp sp2, v 2.5.2.4031

Breakpoints are failing to set in a .dll sourcefile, even after I have successfully stepped into that sourcefile (<fullpathto>/utilexc.cpp) and codelite is displaying it. Similar to one of OP's reports, I'm getting the message indicating failure to find the source file that codelite has me positioned in.

DEBUG>>00001213-break-insert "\"C:/dev/wxwidgets/wxWidgets-2.8.10/src/msw/utilsexc.cpp:284\""
DEBUG>>00001213^error,msg="No source file named C:/dev/wxwidgets/wxWidgets-2.8.10/src/msw/utilsexc.cpp."
Breakpoint creation unsuccessful
ERROR: failed to place breakpoint: "^error,msg="No source file named C:/dev/wxwidgets/wxWidgets-2.8.10/src/msw/utilsexc.cpp.""
No source file named C:/dev/wxwidgets/wxWidgets-2.8.10/src/msw/utilsexc.cpp.

(I'm trying to figure out a problem I'm having with wxExecute/wxProcess and have a locally built version of wxwidgets I'm working with. FWIW, the build is BUILD=debug MONOLITHIC=1 UNICODE=0 shared=1)

Suggestions?

(p.s. other problem, appears that 'break at main' is ignored if one of the 'pending', or perhaps its 'wait til main to set up bps' options is selected, I haven't tried to isolate specific cause of that failure.)

dlh wrote:(p.s. other problem, appears that 'break at main' is ignored if one of the 'pending', or perhaps its 'wait til main to set up bps' options is selected, I haven't tried to isolate specific cause of that failure.)

to set breakpoints after application started, codelite inserts a temporary breakpoint into main, and once hit it will apply all breakpoints and then issues a continue.
This is probably the symptom you see

Eran

Hmm, I found the 'Use file name only for breakpoints (NO full paths)' option and enabled it, and now it appears the breakpoints can be set.

What''s history of that option ????

by default codelite sets breakpoints with full paths (since the Makefile produced by codelite are using full paths) - however, if you are using some custom makefile the paths of the files kept in the debugging symbols *may* not be a full path and gdb might fail in finding the file. However, I came to realize that gdb may succeed in finding the file if we set it without any path at all, just the file name - this is why this option exists

Eran

Hi,

I'm also experiencing problems with debugging a DLL.
"Apply breakpoints after main function is hit" seems to do the trick. The downside is: I have to set the breakpoint
over and over again. CL seems to "forget" the breakpoint after the debugging session has ended.

Regards,
Fredo

Morkel wrote:Hi,

I'm also experiencing problems with debugging a DLL.
"Apply breakpoints after main function is hit" seems to do the trick. The downside is: I have to set the breakpoint
over and over again. CL seems to "forget" the breakpoint after the debugging session has ended.

Regards,
Fredo

Strange, this seems to be working fine here

can you provide more details? OS/codelite version/maybe a reproduction workspace

Eran