GNOME Bugzilla – Bug 474799
Breakpoints not working in attached processes
Last modified: 2008-02-10 20:35:44 UTC
Please describe the problem: In default cases breakpoints work very well. If I work on my local project I'm able to set breakpoints and they work. It does even work to open a C file from a dependency library and set a breakpoint there. Very useful! So no problem. What not works is setting breakpoints while attaching to a existing process. For example I use Anjuta to debug Enlightenment 0.17. Attach works and if E17 crash the thread, stack, locals,... windows work well. But breakpoints don't work. E17 doesn't stop at any breakpoints. I tried also to debug some other attached applications with the same result. Is there a known problem with breakpoints in attached processes? Should I open a new bug? Steps to reproduce: Yes Actual results: Attach a process and set a breakpoint. Expected results: gdb should stop at this breakpoint Does this happen every time? Yes Other information:
I repeated the test with a very simple C++ application. I set a breakpoint in each line and no breakpoint works. If I break the demo application with Crtl-C at scanf() Anjuta shows me the breaking. I attached the demo application and the gdb message window content.
Created attachment 95172 [details] Test application for gdb attach mode
Created attachment 95173 [details] The gdb message window content
I think one line "scanf(str, "%s");" in your sample program is wrong, it should be "scanf("%s", str);". Anyway, I have tried after this correction and it breakpoints seens to work in attached program here. So perhaps, I have fixed this problem without seeing it. I'm currently not at home, so I have accessed only to my own development version. I will be back on Friday and I will check at least with the latest SVN version and if I don't find anything I will get the official 2.2 version. Perhaps you can try the latest SVN version on your side. Then, another possibility is that the problem comes from your setup. By example when I have checked, I have put your sample in a directory containing space in the name and breakpoints where not working due to this (This is another bug). But according to the gdb message window, the breakpoints are even not send to gdb (so the problem is rather in Anjuta). Else, perhaps it is due to the order in which you enter the command. So, could you try the following: 1. Create a C++ project using Anjuta 2. Modify main.cc to use your code with the right scanf line 3. Compile->Run autogenerate 4. You shouldn't have any breakpoints defined, clear them all and exit if it is not the case. 5. Run your program in another terminal (it should wait input from the user) 6. In Anjuta, make sure that the debugger plugin is loaded 7. Open main.cc and put a breakpoint just after the scanf line 8. Debugger->Attach to your program (your program will be stopped) 9. Debugger->Continue (your program will run again) 10. Enter a string in the terminal where your program is running 11. Check that Anjuta is not stopped
I have just checked now with Anjuta version 2.2.0 and I get the same problem. I think I have fixed this bug in the development version when I have changed the breakpoints (2007-08-25). But, I have not back ported these in the stable version because it is a quite important change of the debugger interface and it is even not completed. I mark this bug as fixed (in the devlopment version). You can try to use the development version or can reopen the bug if you need a fix in the stable version.
When do you plan to release this development version as beta or stable version? For now I need this feature only to remote debug E17. So I'll use gdb on the console as all the time before.
I don't know but I think the debugger is not ready yet even for a beta version.
Any news on that bug? Is a solution included in the next stable? I tried it with Anjuta 2.3.1 and it doesn't work. Sometimes it simply doesn't work and sometimes Anjuta crash. But I couldn't get it working.
It was considered as fixed by me as I have not been able to reproduce it with my version of Anjuta from 14 August 2007. But Anjuta 2.3.1 has been released later so it should work with this version. I have just retry again with the latest version on SVN and it's working fine with your small sample program. Could you try again with this small program ? I think the problem is not linked to the attach program function. It could be because the file path name is not handled correctly (perhaps it includes some unexpected characters by example). Then, you could try with the latest version from SVN, I have still made a few changes around breakpoint after version 2.3.1. Else could you send me the content of the debugger message window. It's very strange that in the content that you send me the 8 of August. The plugin doesn't even try to set a breakpoint. Take care that you can set breakpoints only when the target is stopped (in your version the breakpoint function is not disabled). When the attached target is stopped, if you try to set a breakpoint, do you see the marker in the text editor. I have made a anjuta project with your file, and open this project before attaching the debugger to one instance of this program running in another terminal window. I don't know if it's working is you don't have the corresponding anjuta project opened. Have you created an Anjuta project for debugging E17 ?
I've tested it again with Anjuta 2.3.3 and now it works nearly perfect with E17. Only I don't see the yellow arrow at the current source position. Should I create a new bug report for this or may this fit here?
It would be better to create a new bug report. Then, with which editor do you get this, Scintilla or GtkSourceView ? I remember that I have get more trouble with GtkSourceView. And, do you get this all the time or only from time to time ?
I use the Scintilla editor. And I get it only from time to time. I'll try to reproduce it and then create a new bug report.
Ok, so I have already seen it here (with Scintilla) too, but I haven't found yet why it appears. I'm closing this bug. If the yellow arrow disappear again here, I will try to investigate this too.