GNOME Bugzilla – Bug 543637
crash in Anjuta IDE: Creating a new project f...
Last modified: 2008-08-15 23:31:42 UTC
Version: 2.5.0 What were you doing when the application crashed? Creating a new project form existing source. Distribution: Fedora release 9 (Sulphur) Gnome Release: 2.22.3 2008-07-01 (Red Hat, Inc) BugBuddy Version: 2.22.0 System: Linux 2.6.25.3-18.fc9.i686 #1 SMP Tue May 13 05:38:53 EDT 2008 i686 X Vendor: The X.Org Foundation X Vendor Release: 10499905 Selinux: No Accessibility: Enabled GTK+ Theme: Clearlooks Icon Theme: Fedora Memory status: size: 98131968 vsize: 98131968 resident: 31698944 share: 18063360 rss: 31698944 rss_rlim: 4294967295 CPU usage: start_time: 1216405207 rtime: 362 utime: 328 stime: 34 cutime:0 cstime: 1 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/anjuta' [Thread debugging using libthread_db enabled] [New Thread 0xb8035760 (LWP 13363)] 0x00110416 in __kernel_vsyscall ()
+ Trace 203205
Thread 1 (Thread 0xb8035760 (LWP 13363))
The program is running. Quit anyway (and detach it)? (y or n) [answered Y; input not from terminal] ----------- .xsession-errors --------------------- Python: Ruby: Scheme: Sh: SML: SQL: Tcl: Vera: Verilog: Vim: OPENING /home/duni/Workspaces/Software/led_test/hardware.h as C++ language file OPENING /home/duni/Workspaces/Software/led_test/main.c as C language file OPENING /home/duni/Workspaces/Software/led_test/main.c as C language file OPENING /home/duni/Workspaces/Software/led_test/main.c as C language file ** Message: Spawning script --------------------------------------------------
*** Bug 543634 has been marked as a duplicate of this bug. ***
These lines are interesting:
+ Trace 203229
but in particular "path=0x0, languages=0x0". That means that on do_import_sources () function the call to prj_elements_list = ianjuta_project_manager_get_elements (pm, IANJUTA_PROJECT_MANAGER_SOURCE, NULL); fails, returning NULL or anyway something with zero elements. Then the for loop is skipped an the GPtrArrays not initialized. Does your project have any files in it? I've now put some asserts so that your project loading should not crash anymore. I think anyway there's something wrong with project_manager. What do you think Johannes? thanks, Massimo
@Massimo: It's possible that it returns NULL if gnome-build fails to find real source files (Makefile.am scripting can confuse it). It should NOT return empty element though, you may want to check this.
> Does your project have any files in it? Yes, it is a Makefile project, it has: main.c hardware.h Makefile and 2 additional folders - /debug & /target > It's possible that it returns NULL if gnome-build fails to find real source files (Makefile.am scripting can confuse it). Well, as that's a simple makefile project with 3 files, is there any problem with that?
Hi! > Well, as that's a simple makefile project with 3 files, is there any problem > with that? Yes, because it's completely impossible to parse Makefiles they are supported very badly. It's not easy to parse Makefile.am either but that works far better.
Hm, means that, that symbol_db is scanning the Makefile.am, and not the project folder to collect the sources and to make the symbol database - do I get that right? If that's so, I have to warn Massimo, that all the bugs I filed are related to my makefile projects - I'm using only simple makefile projects to compile code for my AVR targets. Is there any way to overcome this issue, for example if I create a Makefile.am, which is useless to me, but where symbol_db or whatever plugin is involved could find what it needs?
Well, with this patch http://bugzilla.gnome.org/attachment.cgi?id=114807 on bug #358479 I disable the population of projects that haven't 'good' sources. In that case your project shouldn't populate but also shouldn't crash. I think then that this is, as Johannes said, a problem of 'Makefile' parsing. (In reply to comment #6) > Hm, > means that, that symbol_db is scanning the Makefile.am, and not the project > folder to collect the sources and to make the symbol database - do I get that > right? > If that's so, I have to warn Massimo, that all the bugs I filed are related to > my makefile projects - I'm using only simple makefile projects to compile code > for my AVR targets. > Is there any way to overcome this issue, for example if I create a Makefile.am, > which is useless to me, but where symbol_db or whatever plugin is involved > could find what it needs? >
Thank you! I've now used some Makefile.am and configure.in templates in order to "simulate" good sources and symbol-db is working very well. Once the sources are good, the symbols are being generated properly. By now I'm using only makefiles, but I will try to use the autotools for my avr projects too. It's definitely the more "civilized" way, and I'm sure the more compatible one. I still experience some minor problems with the updating of the symbols - ex. old c files need to be changed (just to add and delete something) and then saved in order to be included in the symbols tree. But those are only minor bugs, which don't belong here. As a conclusion - symbol-db works fine with a good autotools project. I think, that the bug could be marked as fixed. However, I have a question, just out of interest - I've spent some time investigating the symbol-db code, but it was too much for my programmers skills. I was wondering, what is the basic working concept of how the plugin scans the project files and the included libraries and is aware of their structure. If you could take some minutes to write me an email with a short explanation, I will be very thankful. Best Regards, Danail Nedyalkov
(In reply to comment #8) > As a conclusion - symbol-db works fine with a good autotools project. > I think, that the bug could be marked as fixed. good. > > > However, I have a question, just out of interest - I've spent some time > investigating the symbol-db code, but it was too much for my programmers > skills. I was wondering, what is the basic working concept of how the plugin > scans the project files and the included libraries and is aware of their > structure. If you could take some minutes to write me an email with a short > explanation, I will be very thankful. the core of the plugin is the engine. The other components communicate with it so that it can manage a database of symbols. One component is for instance the project_manager plugin that provides the names and the paths of the project's files. The engine will then check whether they need a scan (for an update) or not. The project_manager plugin also gives the project's required packages, for instance glib, gtkmm, glade etc. These names'll be passed to SymbolDBSystem class which will take care of processing the directories of those packages, taking the includes, and passing everything down to the engine: it'll store every information into another separated database, the global-tags one. Another component is the document/editor plugin, which will be responsible of the input events, timeouts and source buffer updating. All the other code and difficulties are in the querying, searching, performances, displaying data etc. I hope this description gives you a better vision of the big-picture. thanks for your bug-reporting, Massimo @Johannes, you can close this bug.
*** Bug 537581 has been marked as a duplicate of this bug. ***