Re: gEDA: CVS gschem crashes often

[David Carr <dc-at-NOSPAMdcarr_dot_org>]

Carlos,

I changed line that was causing the build failure to this:
backup_filename = g_strdup_printf("%s%c%s",dirname, G_DIR_SEPARATOR, 
only_filename);

This allowed the build to complete sucessfully and I haven't observed 
any further crashes.  I'm not sure though if the autosave functionality 
still works after this change.  Where should I see the backup files?

-David Carr

David Carr wrote:

> Carlos,
>
> It appears that you are correct...
>
> Here's what gdb says:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1218398528 (LWP 10909)]
> 0xb7f6b760 in s_page_autosave (toplevel=0x8263b40) at s_page.nw:629
> 629     s_page.nw: No such file or directory.
>        in s_page.nw
> (gdb) bt
> #0  0xb7f6b760 in s_page_autosave (toplevel=0x8263b40) at s_page.nw:629
> #1  0xb7bd1006 in g_main_context_wakeup () from /usr/lib/libglib-2.0.so.0
> #2  0xb7bcf4ee in g_main_context_dispatch () from 
> /usr/lib/libglib-2.0.so.0
> #3  0xb7bd24f6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
> #4  0xb7bd27e3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
> #5  0xb7928e65 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
> #6  0x08057cc4 in main_prog (closure=0x0, argc=1, argv=0xbfc9cee4) at 
> gschem.nw:377
> #7  0xb7eeaac9 in scm_boot_guile () from /usr/lib/libguile.so.12
> #8  0x08057e64 in main (argc=1, argv=0xbfc9cee4) at gschem.nw:422
>
> Curiously, my source tree doesn't have a s_page.nw as far as I can tell.
>
> I checked out a fresh gschem tree from CVS and got this build error:
>
> if gcc -DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. 
> -I../intl -I../include  -I/usr/include/gtk-2.0 
> -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo 
> -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 
> -I/usr/lib/glib-2.0/include     -Wall -g -O2 -MT o_misc.o -MD -MP -MF 
> ".deps/o_misc.Tpo" -c -o o_misc.o o_misc.c; \
> then mv -f ".deps/o_misc.Tpo" ".deps/o_misc.Po"; else rm -f 
> ".deps/o_misc.Tpo"; exit 1; fi
> ./noweb/o_misc.nw: In function ‘o_autosave_backups’:
> ./noweb/o_misc.nw:1765: error: syntax error before 
> ‘AUTOSAVE_BACKUP_FILENAME_STRING’
>
> The offending line looks like this:
>    backup_filename = 
> g_strdup_printf("%s%c"AUTOSAVE_BACKUP_FILENAME_STRING,
>                      dirname, G_DIR_SEPARATOR, only_filename);
>
> grep -R AUTOSAVE_BACKUP_FILENAME_STRING *
> doesn't turn up any instances of AUTOSAVE_BACKUP_FILENAME_STRING in my 
> tree, perhaps I need to update my libgeda.
>
> Also, my first thought was to put a comma between "%s%c" and 
> AUTOSAVE_BACKUP_FILENAME_STRING to fix the syntax error but it appears 
> that there are too many arguments to the function.
> Let me know what else I can do...
>
> -David Carr
>
> Carlos Nieves Ónega wrote:
>
>> Hi David,
>> I think this could have to do with the autosave feature I added a while
>> ago. Every 2 minutes (by default), the schematic is saved to a backup
>> copy, so this could be the problem. It used to segfault because of
>> saving the schematic inside a timer callback function. I thought I fixed
>> the situation on 18-11-2005, as the ChangeLog shows.
>> I'd appreciate more info about the segfault (message shown, if any, gdb
>> trace, or whatever I could use to chase the problem). Is anyone else
>> having this problem?
>>
>> Thanks,
>>
>> Carlos
>>
>> El dom, 27-11-2005 a las 12:48 -0600, David Carr escribió:
>>  
>>
>>> Hey guys,
>>>
>>> I'm just finishing up my main machine from gentoo to ubuntu.  
>>> Because the
>>> ubuntu geda packages are a bit stale I decided to build gschem from 
>>> CVS. I checked out on 11/23 and built from scratch using a CVS 
>>> libgeda, and
>>> gcc-4.0.  The build was sucessful but gschem would segfault often (once
>>> every 2-3 minutes).  I haven't had time to look into the problem 
>>> further
>>> or run it under gdb but I thought I'd at least report back.
>>>
>>> I needed to work on a design so I built the latest released version on
>>> gschem with the same CVS libgeda as above and everything has been 
>>> fine so
>>> far.  I guess this means the problems are related to gschem and not
>>> libgeda.
>>>
>>> Is anyone else experiencing this issue or could it possibly be a 
>>> gcc-4.0
>>> problem?
>>>
>>> -David Carr
>>>
>>>   
>>