[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: gschem start fails



On Tue, 2008-03-04 at 20:50 +0100, Stefan Salewski wrote:
> Hello,
> 
> some weeks ago I installed gEDA 1.4 shipped with Gentoo-Linux (AMD64).
> 
> gschen was working fine.
> 
> Now I cant start gschem any more.
> 
> Trying to start from Bash shell pops up a window, which immediately
> closes again. There is no message concerning the problem in gschem.log.
> I tried option -v, but this makes no difference. I have removed .gEDA/
> -- no difference. I have used Gentoo's "revdep-rebuild" command to check
> for library inconsistency -- no success.
> 
> I guess that complete reinstall of gEDA will fix the problem, but before
> I will try to find the reason for the bug.
> 
> I do not know much about gdb...
> 
> Tried "gdb gschem" which gives this output:
> 
> stefan@AMD64-X2 ~ $ gdb gschem
> GNU gdb 6.7.1
> Copyright (C) 2007 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-pc-linux-gnu"...
> (no debugging symbols found)
> Using host libthread_db library "/lib/libthread_db.so.1".
> (gdb) run
> Starting program: /usr/bin/gschem 
> (no debugging symbols found)

Without debug symbols, this will be hard to trace further.

> ---Type <return> to continue, or q <return> to quit---
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00002b8467b7f356 in g_make_page_smob () from /usr/lib/libgeda.so.33
> (gdb) 


Is it possible that something upgraded guile? I'm guessing wildly here,
but looking at g_make_page_smob, it only calls:

scm_must_malloc

sets some values in the returned smob (after having _not_ checked if the
allocation succeeded), then returns via (the macro?)
SCM_RETURN_NEWSMOB()


Does running under valgrind give any more enlightening output as to
where the bad memory was allocated?


-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user