gEDA-user: Strange segfaults in gschem when adding big symbols
Hello, I am using geda version 20070526 on gentoo 32 bit system, glibc 2.7. Whenever I want to place big symbol on a schematic page (like 500pin Xilinx, or event titleblock A1), gschem segfaults or looks up using 100% cpu power - no reaction on keyboard/mouse. I wanted to trace the problem with gdb but when I attach gdb to gschem it works right - no segfaults or lookups. I have the same situation on 2 different machines, but both with the same gentoo system and the same kernel 2.6.24. Can somebody tell me what to do or what should I try? I am new to geda, but I really want to switch to it from my current closed source tools. Best Regards, Michael ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Strange segfaults in gschem when adding big symbols
On Tue, 2008-03-18 at 13:04 +0100, michalwd1979 wrote: Hello, I am using geda version 20070526 on gentoo 32 bit system, glibc 2.7. Whenever I want to place big symbol on a schematic page (like 500pin Xilinx, or event titleblock A1), gschem segfaults or looks up using 100% cpu power - no reaction on keyboard/mouse. I wanted to trace the problem with gdb but when I attach gdb to gschem it works right - no segfaults or lookups. I have the same situation on 2 different machines, but both with the same gentoo system and the same kernel 2.6.24. Can somebody tell me what to do or what should I try? I am new to geda, but I really want to switch to it from my current closed source tools. Can you send us an example of a symbol which causes the segfault, or get a backtrace? Run gschem under gdb: gdb gschem type run (enter) and then when it crashes, type bt (enter), and post us the output. I can't recall the right use flag or config option for building packages in gentoo which aren't stripped of debugging info, but its something like nostrip in the make.conf or on a command line option. We'll need output from a non-stripped version of gschem for this tracing to be of any use. try: FEATURES=nostrip emerge --oneshot geda You could also try with the 1.4.0 version. which is in unstable. I think the rune is something like: ACCEPT_KEYWORDS=~x86 FEATURES=nostrip emerge --oneshot geda (The --oneshot is to avoid listing the package as manually installed, although it probably is already.. you would definately use it if you needed to rebuild any system libraries with nostrip to get a decent backtrace, so that automatic removals can still work when the library is no longer needed). Best regards, -- 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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Strange segfaults in gschem when adding big symbols
On Tue, 2008-03-18 at 13:04 +0100, michalwd1979 wrote:
Hello,
I am using geda version 20070526 on gentoo 32 bit system, glibc 2.7.
Whenever I want to place big symbol on a schematic page (like 500pin
Xilinx, or event titleblock A1), gschem segfaults or looks up using
100% cpu power - no reaction on keyboard/mouse. I wanted to trace the
problem with gdb but when I attach gdb to gschem it works right - no
segfaults or lookups.
Doh, sorry - missed that bit!
Try running under valgrind. There will be a lot of warnings, but most
are harmless. Let it run, then press enter several times (making a mark
you can see on the console), and then perform the required action to
make it crash.
Valgrind will get very verbose and tell you if there are any issues with
bad memory usage.
My valgrind command line looks like this:
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind
--suppressions=valgrind/gdk.supp --suppressions=valgrind/guile.supp
--suppressions=valgrind/x11.supp --suppressions=valgrind/gschem.supp gschem
I've attached the suppression files, which would live in the valgrind/
directory relative to where I'm running valgrind from.
Good luck!
--
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!)
{
insert some suppression name here
Memcheck:Leak
fun:malloc
fun:*
fun:*
obj:/usr/lib/libgdk-x11-2.0.so.0.400.14
}
{
insert a suppression name here
Memcheck:Leak
fun:calloc
fun:XkbGetMap
obj:/usr/lib/libgdk-x11-2.0.so.0.400.14
fun:gdk_keymap_translate_keyboard_state
}
{
insert a suppression name here
Memcheck:Leak
fun:malloc
fun:XAddConnectionWatch
fun:gdk_display_open
fun:gdk_display_open_default_libgtk_only
}
{
insert a suppression name here
Memcheck:Leak
fun:malloc
fun:*
obj:/usr/lib/libgdk-x11-2.0.so.0.400.14
obj:/usr/lib/libgdk-x11-2.0.so.0.400.14
}
{
insert a suppression name here
Memcheck:Leak
fun:malloc
fun:_X11TransConnectDisplay
fun:XOpenDisplay
fun:gdk_display_open
}
{
insert a suppression name here
Memcheck:Leak
fun:malloc
obj:/usr/lib/libgdk-x11-2.0.so.0.400.14
obj:/usr/lib/libgdk-x11-2.0.so.0.400.14
}
{
insert a suppression name here
Memcheck:Leak
obj:/usr/lib/libgdk-x11-2.0.so.0.400.14
}
{
insert a suppression name here
Memcheck:Leak
fun:malloc
fun:XOpenDisplay
fun:gdk_display_open
fun:gdk_display_open_default_libgtk_only
}
{
insert a suppression name here
Memcheck:Leak
fun:calloc
fun:XOpenDisplay
fun:gdk_display_open
fun:gdk_display_open_default_libgtk_only
}
{
insert a suppression name here
Memcheck:Param
write(buf)
obj:/lib/ld-2.6.so
fun:_X11TransWrite
fun:_XFlushInt
fun:_XReply
fun:XInternAtom
fun:gdk_x11_atom_to_xatom_for_display
fun:gdk_x11_get_xatom_by_name_for_display
fun:setup_toplevel_window
fun:gdk_window_new
fun:gdk_display_open
fun:gdk_display_open_default_libgtk_only
fun:gtk_init_check
}
{
Should this one be real perhaps
Memcheck:Param
write(buf)
obj:/lib/ld-2.6.so
fun:_X11TransWrite
fun:_XFlushInt
fun:_XFlushGCCache
fun:XDrawLine
fun:gdk_x11_draw_segments
fun:gdk_draw_segments
fun:gdk_window_draw_segments
fun:gdk_draw_line
fun:o_line_draw
}
{
Should this one be real perhaps
Memcheck:Param
write(buf)
obj:/lib/ld-2.6.so
fun:_X11TransWrite
fun:_XFlushInt
fun:XDrawLine
fun:gdk_x11_draw_segments
fun:gdk_draw_segments
fun:gdk_window_draw_segments
fun:gdk_draw_line
fun:o_line_draw
}
{
insert a suppression name here
Memcheck:Param
writev(vector[...])
obj:/lib/ld-2.6.so
fun:_X11TransSocketWritev
fun:_X11TransWritev
fun:_XSend
fun:XDrawPoints
fun:gdk_x11_draw_points
fun:gdk_draw_points
fun:gdk_pixmap_draw_points
fun:gdk_draw_points
fun:x_grid_draw
}
{
insert a suppression name here
Memcheck:Param
write(buf)
obj:/lib/ld-2.6.so
fun:_X11TransWrite
fun:_XFlushInt
fun:_XEventsQueued
fun:XPending
fun:_gdk_events_queue
fun:gdk_event_dispatch
fun:g_main_context_dispatch
fun:g_main_context_iterate
fun:g_main_loop_run
fun:gtk_main
fun:main_prog
}
{
insert a suppression name here
Memcheck:Param
write(buf)
obj:/lib/ld-2.6.so
fun:_X11TransWrite
fun:_XFlushInt
fun:XFlush
fun:gdk_display_flush
fun:gdk_window_process_all_updates
fun:gtk_container_idle_sizer
fun:gdk_threads_dispatch
fun:g_idle_dispatch
fun:g_main_context_dispatch
fun:g_main_context_iterate
fun:g_main_loop_run
}
# guile valgrind suppression file
{
guilegc
Memcheck:Value4
fun:scm_c_hook_run
}
{
guilegc
Memcheck:Cond
fun:scm_c_hook_run
}
{
guilegc
Memcheck:Value4
fun:scm_gc_mark_dependencies
}
{
guilegc
Memcheck:Cond
Re: gEDA-user: Strange segfaults in gschem when adding big symbols
Thanks, I will try this today evening, however I already done the following: start gschem - it runs OK start gdb on different terminal gdb attach pid_of_gschem gdb continue load big symbol to gschem - and it is OK play with schematic, then quit gdb program terminated normally But If don't attach gdb to running gschem it fails as I said. I think that this might be specific to my system, but I'm not sure. I will send a backtrace today in evening, but I am not sure if gschem fails when I run it from gdb... Michael Can you send us an example of a symbol which causes the segfault, or get a backtrace? Run gschem under gdb: gdb gschem type run (enter) and then when it crashes, type bt (enter), and post us the output. I can't recall the right use flag or config option for building packages in gentoo which aren't stripped of debugging info, but its something like nostrip in the make.conf or on a command line option. We'll need output from a non-stripped version of gschem for this tracing to be of any use. try: FEATURES=nostrip emerge --oneshot geda You could also try with the 1.4.0 version. which is in unstable. I think the rune is something like: ACCEPT_KEYWORDS=~x86 FEATURES=nostrip emerge --oneshot geda (The --oneshot is to avoid listing the package as manually installed, although it probably is already.. you would definately use it if you needed to rebuild any system libraries with nostrip to get a decent backtrace, so that automatic removals can still work when the library is no longer needed). Best regards, -- 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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Strange segfaults in gschem when adding big symbols
The symbols are from standard library: Xilinx: XC2S100-5PQ208C - 100% CPU usage, titleblock: title-A1 - segfault I have also found that it usually not crashes when you load schematic to it first, rather you need to start up on empty page, or page with tileblock only. Anyway I will try to do a backtrace today, please give me some time - I am trying to fix my new toy now (RS RLC bridge about 35 years old :-)). Michael Dnia 18 marca 2008 15:13 Peter Clifton [EMAIL PROTECTED] napisał(a): Can you send an example of the symbol which causes the crash (privately if you want), and I'll see if I can reproduce on the latest gEDA code from the git repository. Best wishes, -- 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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Strange (laser) print defects
Hi all. Though this evidently is not a software defect, I'm wondering if someone on the list knows the cause of this problem or experienced similar effects. I was testing another paper (touted by a local electronics magazine as 'ideal') for my quick-and-dirty toner-transfer PCBs, and found a strange defect, hard to describe. (see: http://jcoppens.com/misc/laser1.jpg and http://jcoppens.com/misc/laser2.jpg ) The right part of each pic is normal typewriter paper, the left one is on the new paper I'm testing. The faults are systematic: - The appear always on the same spot in the board, independent from where I print it on the sheet. - They never appear on the 'normal' paper. - Printer settings and source file is exactly the same, of course. (I did experiment with different settings, but no difference was noted on the printout). First feeling was that some particle on the paper surface 'exploded', and blew away the toner before it got fixated. But this shouldn't happen systematically on the same spot. Problems with the paper/toner transport? They should show on both printouts, shouldn't they? Ideas? John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Strange (laser) print defects
That's very bizzare. It's the kind of thing I'd ask about on the Homebrew_PCBs yahoo group. I've seen all sorts of defects using TT, but nothing systematic like that. Have you tried rotating the board 90 degrees on the paper? I wonder if there's a charge buildup or something in your printer, which interacts with the paper. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Strange (laser) print defects
On Tue, Mar 18, 2008 at 9:14 AM, John Coppens [EMAIL PROTECTED] wrote: I was testing another paper (touted by a local electronics magazine as 'ideal') for my quick-and-dirty toner-transfer PCBs, and found a strange defect, hard to describe. (see: http://jcoppens.com/misc/laser1.jpg and http://jcoppens.com/misc/laser2.jpg ) Permission denied (403) errors when attempting to view the pictures. -- Samuel A. Falvo II ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Strange (laser) print defects
On Tue, 18 Mar 2008 09:46:41 -0700 Samuel A. Falvo II [EMAIL PROTECTED] wrote: Permission denied (403) errors when attempting to view the pictures. Strange, just tested them (again), and they show fine. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Strange (laser) print defects
On Tue, 18 Mar 2008 12:46:30 -0400 DJ Delorie [EMAIL PROTECTED] wrote: That's very bizzare. It's the kind of thing I'd ask about on the Homebrew_PCBs yahoo group. I've seen all sorts of defects using TT, but nothing systematic like that. Ok... Didn't know about that group. Thanks for the hint. Have you tried rotating the board 90 degrees on the paper? I wonder if there's a charge buildup or something in your printer, which interacts with the paper. I haven't rotated yet, but I did change the position of the board left/right with no change. Also, the image drum is 76 mm circumference, and there's nothing printed 76 mm before the defect. It _does_ look like a static problem. I'll do some more testing when I get more paper. Thanks, John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Strange (laser) print defects
On Tuesday 18 March 2008, John Coppens wrote: Hi all. Though this evidently is not a software defect, I'm wondering if someone on the list knows the cause of this problem or experienced similar effects. I was testing another paper (touted by a local electronics magazine as 'ideal') for my quick-and-dirty toner-transfer PCBs, and found a strange defect, hard to describe. (see: http://jcoppens.com/misc/laser1.jpg and http://jcoppens.com/misc/laser2.jpg ) The right part of each pic is normal typewriter paper, the left one is on the new paper I'm testing. The faults are systematic: - The appear always on the same spot in the board, independent from where I print it on the sheet. - They never appear on the 'normal' paper. - Printer settings and source file is exactly the same, of course. (I did experiment with different settings, but no difference was noted on the printout). First feeling was that some particle on the paper surface 'exploded', and blew away the toner before it got fixated. But this shouldn't happen systematically on the same spot. Problems with the paper/toner transport? They should show on both printouts, shouldn't they? One would certainly think so John. You may be onto something with the before its fixated idea though, This is a laser, and the heat to fuse (fixate the image) might be related to it. What I think I would do is waste a couple sheets, but make the first run with the printer set at half density, the next one at 25% etc to see if it goes away. I'm thinking there might be a liquid buildup there that would spatter away as the heat was applied to this much less porous medium, particularly if the heating effect at that point was coming in at an angle. The transfer images appear to have plenty of toner, and reducing it via the density setting might at least prove the theory. It appears to have density to spare in your scans. If that has no effect, then I'm afraid I don't have any better clues other than to try another, different transfer medium. Ideas? John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) sushi, n.: When that-which-may-still-be-alive is put on top of rice and strapped on with electrical tape. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Strange (laser) print defects
On Tuesday 18 March 2008, Samuel A. Falvo II wrote: On Tue, Mar 18, 2008 at 9:14 AM, John Coppens [EMAIL PROTECTED] wrote: I was testing another paper (touted by a local electronics magazine as 'ideal') for my quick-and-dirty toner-transfer PCBs, and found a strange defect, hard to describe. (see: http://jcoppens.com/misc/laser1.jpg and http://jcoppens.com/misc/laser2.jpg ) Permission denied (403) errors when attempting to view the pictures. Thats odd, FF3b4 loaded them almost instantly here. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) management, n.: The art of getting other people to do all the work. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: DRC question...
Guys, Thanks for the feedback and input on the annulus vs. min width issue. I also vote for changing this. Seems a bug to me. Thanks again, Roger Traylor ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Publication Quality Schematic Symbols
On Tue, Mar 18, 2008 at 2:08 PM, Steven Michalske [EMAIL PROTECTED] wrote: John, I started writing a document today and was wondering if you had released these. I am in the process of finishing up an initial release. I did a fair amount of work on the symbols (and the naming spec) last week. The list of completed symbols is below. Since these symbols are a little smaller than the majority of gschem symbols it was necessary to do a set rather than just a few at a time. I wasn't planning on releasing the set for another few weeks. If you need something sooner and the something you need is listed below I could try to get something out sooner. (* jcl *) MOSFET N and P Enhancement and Depletion four sizes (two largest have body diodes) (the largest has an outline circle) BJT NPN and PNP two sizes (the largest has an outline circle) JFET N and P, three sizes (largest has an outline circle) OPAMP five terminal (+,-,out,V+,V-) seven terminal (+,-,out,V+,V-,Trim,Trim) CAPS two sizes DIODES two sizes Resistors three sizes one size pot (arrow wiper) three sizes of four terminal shunts Phone Jacks Switchcraft i, ii, iii MISC (almost complete) TL431 Triac SCR -- http://www.luciani.org ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: DRC question...
Traylor Roger wrote: Guys, Thanks for the feedback and input on the annulus vs. min width issue. I also vote for changing this. Seems a bug to me. It has already been changed. -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Strange (laser) print defects
On Tue, 18 Mar 2008 14:09:30 -0400 Gene Heskett [EMAIL PROTECTED] wrote: I'm thinking there might be a liquid buildup there that would spatter away as the heat was applied to this much less porous medium, particularly if the heating effect at that point was coming in at an angle. Neither the paper nor the toner contain any liquid, so that ouldn't be the source (If the paper were the source of the problem, it wouldn't repeat on the same spot. The problem _is_ pre-fixating, as those mini-clouds are fixated. I'm somewhat miffed at the problem - my quick 'n dirty process is failing badly here (at least the quick part). Anyway, the density change is a good idea, and I'll try to get some more sheet tomorrow. Thanks! John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Strange (laser) print defects
On Tuesday 18 March 2008, John Coppens wrote: On Tue, 18 Mar 2008 14:09:30 -0400 Gene Heskett [EMAIL PROTECTED] wrote: I'm thinking there might be a liquid buildup there that would spatter away as the heat was applied to this much less porous medium, particularly if the heating effect at that point was coming in at an angle. Neither the paper nor the toner contain any liquid, so that ouldn't be the source (If the paper were the source of the problem, it wouldn't repeat on the same spot. There is something in the toner that while not liquid, is certainly thermalplastic, and that generally involves something that could be volatile, maybe even explosive at high temps. Toner recipes of course are guarded by armed guards and pit bulls 24/7 as that is the 'magic twanger' that makes it all work. Most printer folks would have no problem killing those who would try to obtain that very proprietary info without being part of the crew that actually mixes it. It is all a very cloak and dagger business. The problem _is_ pre-fixating, as those mini-clouds are fixated. I'm somewhat miffed at the problem - my quick 'n dirty process is failing badly here (at least the quick part). Sounds like! Anyway, the density change is a good idea, and I'll try to get some more sheet tomorrow. Thanks! Let me know if my thoughts were worth the electrons to send them :) John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Real Programs don't use shared text. Otherwise, how can they use functions for scratch space after they are finished calling them? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
