Re: gEDA-user: problems with PCB and large board
gene wrote: more nets in your design than most PCB users ;)) Yep, there's a bucket load of stuff in this. This is my first layout, I hope it's not too much for the first time. There's a lot of repeated sections, so if you know how to step and repeat, I'd be interested in knowing how it's done. See the link to and instructions on use of pcb-hier-cells script at http://www.gedasymbols.org/user/john_griessen/ John -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: problems with PCB and large board
IE: in the file src/hid/gtk/gui-netlist-window.c, line 388, change the + 1 to a + 2. Hope that resolves the issue, if not - run valgrind again, and it may get further. OK, if I run the program normally, it'll crash with the segmentation error. If I run it under valgrind - it doesn't crash. When the rats appear, they completely flood the screen, making it one big mass of bronze color. I was able to turn off the rats and see my components. Finally, I closed out without saving. If you still want to use my layout, I will send it to you - it's probably going to be more efficient to solve the problem. Here's the valgrind output: g...@geno:~/avTek/hardware/schematic$ cat pcblog.stdout g...@geno:~/avTek/hardware/schematic$ cat pcblog.stderr ==5686== Memcheck, a memory error detector. ==5686== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==5686== Using LibVEX rev 1854, a library for dynamic binary translation. ==5686== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==5686== Using valgrind-3.3.1, a dynamic binary instrumentation framework. ==5686== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==5686== For more details, rerun with: -v ==5686== ==5686== Invalid read of size 4 ==5686==at 0x808AE9B: LOCtoPadRat_callback (find.c:2217) ==5686==by 0x80BA88C: __r_search (rtree.c:539) ==5686==by 0x80BA8E2: __r_search (rtree.c:589) ==5686==by 0x80BA8E2: __r_search (rtree.c:589) ==5686==by 0x80BA8E2: __r_search (rtree.c:589) ==5686==by 0x80BA8E2: __r_search (rtree.c:589) ==5686==by 0x80BA8E2: __r_search (rtree.c:589) ==5686==by 0x80BA95D: r_search (rtree.c:625) ==5686==by 0x808E197: LookupLOConnectionsToPad (find.c:2272) ==5686==by 0x8090760: DoIt (find.c:869) ==5686==by 0x8091B95: RatFindHook (find.c:3247) ==5686==by 0x80B2F11: GatherSubnets (rats.c:469) ==5686== Address 0x7a74c1c is 2,228 bytes inside a block of size 184,000 free'd ==5686==at 0x40238BD: realloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==5686==by 0x809EA80: MyRealloc (mymem.c:676) ==5686==by 0x809EFB3: GetRatMemory (mymem.c:308) ==5686==by 0x8077461: CreateNewRat (create.c:472) ==5686==by 0x80B4537: AddAllRats (rats.c:654) ==5686==by 0x8062840: ActionAddRats (action.c:3628) ==5686==by 0x80C81A3: hid_actionv (actions.c:219) ==5686==by 0x80C7DAF: hid_parse_actions (actions.c:287) ==5686==by 0x80E28DA: ghid_menu_cb (gui-top-window.c:633) ==5686==by 0x45441DE: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-2.0.so.0.1600.6) ==5686==by 0x4536E68: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1600.6) ==5686==by 0x454B61A: (within /usr/lib/libgobject-2.0.so.0.1600.6) ==5686== ==5686== Invalid read of size 4 ==5686==at 0x808AEA8: LOCtoPadRat_callback (find.c:2219) ==5686==by 0x80BA88C: __r_search (rtree.c:539) ==5686==by 0x80BA8E2: __r_search (rtree.c:589) ==5686==by 0x80BA8E2: __r_search (rtree.c:589) ==5686==by 0x80BA8E2: __r_search (rtree.c:589) ==5686==by 0x80BA8E2: __r_search (rtree.c:589) ==5686==by 0x80BA8E2: __r_search (rtree.c:589) ==5686==by 0x80BA95D: r_search (rtree.c:625) ==5686==by 0x808E197: LookupLOConnectionsToPad (find.c:2272) ==5686==by 0x8090760: DoIt (find.c:869) ==5686==by 0x8091B95: RatFindHook (find.c:3247) ==5686==by 0x80B2F11: GatherSubnets (rats.c:469) ==5686== Address 0x7a74c5c is 2,292 bytes inside a block of size 184,000 free'd ==5686==at 0x40238BD: realloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==5686==by 0x809EA80: MyRealloc (mymem.c:676) ==5686==by 0x809EFB3: GetRatMemory (mymem.c:308) ==5686==by 0x8077461: CreateNewRat (create.c:472) ==5686==by 0x80B4537: AddAllRats (rats.c:654) ==5686==by 0x8062840: ActionAddRats (action.c:3628) ==5686==by 0x80C81A3: hid_actionv (actions.c:219) ==5686==by 0x80C7DAF: hid_parse_actions (actions.c:287) ==5686==by 0x80E28DA: ghid_menu_cb (gui-top-window.c:633) ==5686==by 0x45441DE: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-2.0.so.0.1600.6) ==5686==by 0x4536E68: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1600.6) ==5686==by 0x454B61A: (within /usr/lib/libgobject-2.0.so.0.1600.6) ==5686== ==5686== Invalid read of size 4 ==5686==at 0x808AF00: LOCtoPadRat_callback (find.c:2219) ==5686==by 0x80BA88C: __r_search (rtree.c:539) ==5686==by 0x80BA8E2: __r_search (rtree.c:589) ==5686==by 0x80BA8E2: __r_search (rtree.c:589) ==5686==by 0x80BA8E2: __r_search (rtree.c:589) ==5686==by 0x80BA8E2: __r_search (rtree.c:589) ==5686==by 0x80BA8E2: __r_search (rtree.c:589) ==5686==by 0x80BA95D: r_search (rtree.c:625) ==5686==by 0x808E197: LookupLOConnectionsToPad (find.c:2272) ==5686==by 0x8090760: DoIt (find.c:869) ==5686==by 0x8091B95: RatFindHook (find.c:3247) ==5686==by 0x80B2F11: GatherSubnets (rats.c:469) ==5686== Address 0x7a74c34 is 2,252 bytes
Re: gEDA-user: problems with PCB and large board
On Wed, 2008-12-24 at 07:02 -0500, gene wrote: IE: in the file src/hid/gtk/gui-netlist-window.c, line 388, change the + 1 to a + 2. Hope that resolves the issue, if not - run valgrind again, and it may get further. OK, if I run the program normally, it'll crash with the segmentation error. If I run it under valgrind - it doesn't crash. When the rats appear, they completely flood the screen, making it one big mass of bronze color. I was able to turn off the rats and see my components. Finally, I closed out without saving. If you still want to use my layout, I will send it to you - it's probably going to be more efficient to solve the problem. Here's the valgrind output: Sure, send the board to me. I'll treat it as confidential and delete it afterwards. 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
Re: gEDA-user: problems with PCB and large board
On Wed, 2008-12-24 at 12:57 +, Peter Clifton wrote:
On Wed, 2008-12-24 at 07:02 -0500, gene wrote:
OK, if I run the program normally, it'll crash with the segmentation
error. If I run it under valgrind - it doesn't crash. When the rats
appear, they completely flood the screen, making it one big mass of
bronze color. I was able to turn off the rats and see my components.
Finally, I closed out without saving. If you still want to use my
layout, I will send it to you - it's probably going to be more efficient
to solve the problem. Here's the valgrind output:
Sure, send the board to me. I'll treat it as confidential and delete it
afterwards.
Ok, hold that thought for a moment..
Try the attached patch (should fix the issue).
Valgrind is a wonderful tool ;)
If it stops the crash, could you just confirm for me that valgrind is
then happy, and doesn't report any problems.
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!)
From aa6797de10a632ad82c786536df494f5031e8c04 Mon Sep 17 00:00:00 2001
From: Peter Clifton pc...@cam.ac.uk
Date: Wed, 24 Dec 2008 13:05:31 +
Subject: [PATCH] Fix regenerate rats r-tree after re-allocating a new rat array
Fixes crashes observed on a board with a large number of rats.
---
src/mymem.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/src/mymem.c b/src/mymem.c
index f6b6957..cb481b4 100644
--- a/src/mymem.c
+++ b/src/mymem.c
@@ -305,10 +305,19 @@ GetRatMemory (DataTypePtr Data)
if (Data-RatN = Data-RatMax)
{
Data-RatMax += STEP_RAT;
+ /* all of the pointers move, so rebuild the whole tree */
+ if (Data-rat_tree)
+r_destroy_tree (Data-rat_tree);
rat = MyRealloc (rat, Data-RatMax * sizeof (RatType),
GetRatMemory());
Data-Rat = rat;
memset (rat + Data-RatN, 0, STEP_RAT * sizeof (RatType));
+ Data-rat_tree = r_create_tree (NULL, 0, 0);
+ RAT_LOOP (Data);
+ {
+r_insert_entry (Data-rat_tree, (BoxTypePtr) line, 0);
+ }
+ END_LOOP;
}
return (rat + Data-RatN++);
}
--
1.6.0.4
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: problems with PCB and large board
Peter Clifton wrote: Ok, hold that thought for a moment.. Try the attached patch (should fix the issue). Valgrind is a wonderful tool ;) If it stops the crash, could you just confirm for me that valgrind is then happy, and doesn't report any problems. Best wishes, Thanks Peter, it works! I also have the first patch installed as well. Here's the output from valgrind: g...@geno:~/avTek/hardware/schematic$ cat pcblog.stdout g...@geno:~/avTek/hardware/schematic$ cat pcblog.stderr ==5440== Memcheck, a memory error detector. ==5440== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==5440== Using LibVEX rev 1854, a library for dynamic binary translation. ==5440== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==5440== Using valgrind-3.3.1, a dynamic binary instrumentation framework. ==5440== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==5440== For more details, rerun with: -v ==5440== ==5440== ==5440== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 191 from 3) ==5440== malloc/free: in use at exit: 24,489,918 bytes in 120,756 blocks. ==5440== malloc/free: 741,760 allocs, 621,004 frees, 276,167,310 bytes allocated. ==5440== For counts of detected errors, rerun with: -v ==5440== searching for pointers to 120,756 not-freed blocks. ==5440== checked 24,531,988 bytes. ==5440== ==5440== LEAK SUMMARY: ==5440==definitely lost: 118,254 bytes in 11,638 blocks. ==5440== possibly lost: 622,518 bytes in 713 blocks. ==5440==still reachable: 23,749,146 bytes in 108,405 blocks. ==5440== suppressed: 0 bytes in 0 blocks. ==5440== Rerun with --leak-check=full to see details of leaked memory. g...@geno:~/avTek/hardware/schematic$ Merry Christmas! gene ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: problems with PCB and large board
On Wed, 2008-12-24 at 16:30 -0500, gene wrote: Thanks Peter, it works! I also have the first patch installed as well. Here's the output from valgrind: [snip] ==5440== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 191 from 3) That's what we like to see! Glad it worked. (And turns out that latter bug wasn't my fault... you probably just have more nets in your design than most PCB users ;)) If you find stock PCB is too slow, come ping me back and I'll get you to try the OpenGL version I've been working on. It gives a significant improvement on frame-rate for complex boards. Merry Christmas! -- 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: problems with PCB and large board
==5440== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 191 from 3) (And turns out that latter bug wasn't my fault... you probably just have more nets in your design than most PCB users ;)) Yep, there's a bucket load of stuff in this. This is my first layout, I hope it's not too much for the first time. There's a lot of repeated sections, so if you know how to step and repeat, I'd be interested in knowing how it's done. If you find stock PCB is too slow, come ping me back and I'll get you to try the OpenGL version I've been working on. It gives a significant improvement on frame-rate for complex boards. Sure, I'm willing to try it out. gene ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: problems with PCB and large board
Sorry to not get back last night - this time I crashed :) Let's see if I can hit on all these points: Gene, you can send a test file to one or more the developers (Dan, DJ, Ben, myself) privately, if you don't want to make it publicly available. Maybe - I have to think about that. This represents a great deal of work on my part so I'm just a tad jumpy about it. But if I can't move forward then I really have little choice. Would you need just the .pcb file or also the schematic? Definitely. The rats nest optimizer should never crash. Yes, it's the rats nest optimizer (keyboard shortcut o. Executing the load netlist works. Optimize Netlist resuts in the sementation fault. I just wanted to see all the rats become visible. Another good test, is to run pcb under valgrind (slow), and send us the output. I see that valgrind is some sort of forensic tool set - never heard of it before now. Regardless, I don't currently have it. However, I tried loading pcb in gdb (I am less than novice on this, so sort of winging it). Running the same sequence as before, gdb reports the segmentation fault as: (gdb) run Starting program: /usr/local/bin/pcb Program received signal SIGSEGV, Segmentation fault. LOCtoPadRat_callback (b=0xb70498a8, cl=0xbfd8b720) at find.c:2217 2217 if (!TEST_FLAG (TheFlag, rat)) (gdb) bt #0 LOCtoPadRat_callback (b=0xb70498a8, cl=0xbfd8b720) at find.c:2217 #1 0x080ba88d in __r_search (node=0x959cf40, query=0xbfd8b77c, arg=0xbfd8b6cc) at rtree.c:539 #2 0x080ba8e3 in __r_search (node=0x95feba0, query=0xbfd8b77c, arg=0xbfd8b6cc) at rtree.c:589 #3 0x080ba8e3 in __r_search (node=0x98fee40, query=0xbfd8b77c, arg=0xbfd8b6cc) at rtree.c:589 #4 0x080ba8e3 in __r_search (node=0x9653bb0, query=0xbfd8b77c, arg=0xbfd8b6cc) at rtree.c:589 #5 0x080ba8e3 in __r_search (node=0x97c6aa0, query=0xbfd8b77c, arg=0xbfd8b6cc) at rtree.c:589 #6 0x080ba8e3 in __r_search (node=0x9567d38, query=0xbfd8b77c, arg=0xbfd8b6cc) at rtree.c:589 #7 0x080ba95e in r_search (rtree=0x8e88078, query=0xbfd8b720, check_region=0, found_rectangle=0x808ae90 LOCtoPadRat_callback, cl=0xbfd8b720) at rtree.c:625 #8 0x0808e198 in LookupLOConnectionsToPad (Pad=0x8b41d88, LayerGroup=1) at find.c:2272 #9 0x08090761 in DoIt (AndRats=1 '\001', AndDraw=0 '\0') at find.c:869 #10 0x08091b96 in RatFindHook (type=512, ptr1=0xb6fe2ba8, ptr2=0x8b41d88, ptr3=0x8b41d88, undo=0 '\0', AndRats=1 '\001') at find.c:3247 #11 0x080b2f12 in GatherSubnets (Netl=0x8ec23f0, NoWarn=0 '\0', AndRats=value optimized out) at rats.c:469 #12 0x080b41bd in AddAllRats (SelectedOnly=-88 '¨', funcp=0) at rats.c:740 #13 0x08062841 in ActionAddRats (argc=1, argv=0x905a000, x=0, y=0) at action.c:3628 #14 0x080c81a4 in hid_actionv (name=0x8775470 AddRats, argc=1, argv=0x905a000) at hid/common/actions.c:219 #15 0x080c7db0 in hid_parse_actions (rstr=0x8332950 AddRats(AllRats), function=0x80c80c0 hid_actionv) at hid/common/actions.c:287 #16 0x080e28cb in ghid_menu_cb (action=0x8357df8, data=0x8126480) at hid/gtk/gui-top-window.c:633 #17 0xb7a121df in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 ---Type return to continue, or q return to quit--- #18 0xb7a04e69 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #19 0xb7a1961b in g_signal_handler_disconnect () from /usr/lib/libgobject-2.0.so.0 #20 0xb7a1b2af in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #21 0xb7a1b5f9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #22 0xb7be2985 in gtk_widget_get_action () from /usr/lib/libgtk-x11-2.0.so.0 #23 0xb7be4d44 in gtk_action_new () from /usr/lib/libgtk-x11-2.0.so.0 #24 0xb7a04e69 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #25 0xb7a1961b in g_signal_handler_disconnect () from /usr/lib/libgobject-2.0.so.0 #26 0xb7a1afd7 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #27 0xb7a1b5f9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #28 0xb7bde85f in gtk_accel_group_activate () from /usr/lib/libgtk-x11-2.0.so.0 #29 0xb7bde96a in gtk_accel_groups_activate () from /usr/lib/libgtk-x11-2.0.so.0 #30 0xb7e05662 in gtk_window_activate_key () from /usr/lib/libgtk-x11-2.0.so.0 #31 0xb7e056fc in gtk_window_activate_key () from /usr/lib/libgtk-x11-2.0.so.0 #32 0xb7cd2154 in gtk_marshal_BOOLEAN__VOID () from /usr/lib/libgtk-x11-2.0.so.0 #33 0xb7a03789 in g_value_set_static_boxed () from /usr/lib/libgobject-2.0.so.0 #34 0xb7a04e69 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #35 0xb7a197aa in g_signal_handler_disconnect () from /usr/lib/libgobject-2.0.so.0 #36 0xb7a1afd7 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #37 0xb7a1b5f9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #38 0xb7df0db7 in gtk_widget_get_default_style () from /usr/lib/libgtk-x11-2.0.so.0 #39 0xb7ccb48d in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #40 0xb7ccc608 in gtk_main_do_event () from
Re: gEDA-user: problems with PCB and large board
On Tue, 2008-12-23 at 05:43 -0500, gene wrote: Sorry to not get back last night - this time I crashed :) Let's see if I can hit on all these points: Gene, you can send a test file to one or more the developers (Dan, DJ, Ben, myself) privately, if you don't want to make it publicly available. Maybe - I have to think about that. This represents a great deal of work on my part so I'm just a tad jumpy about it. But if I can't move forward then I really have little choice. Would you need just the .pcb file or also the schematic? It would just need to be the minimum PCB file required to reproduce the crash. If you can make a copy, remove 50% of the components, that's even better. (The smaller the test-case, the better). I see that valgrind is some sort of forensic tool set - never heard of it before now. Regardless, I don't currently have it. If you can't send us a board, it may well be useful to grab valgrind apt-get install valgrind on debian or ubuntu, and run it under that: valgrind pcb pcblog.stdout 2pcblog.stderr. I say this because I'm suspecting that the crash you're describing is more complex than GDB makes out - otherwise we'd have seen it before. Program received signal SIGSEGV, Segmentation fault. LOCtoPadRat_callback (b=0xb70498a8, cl=0xbfd8b720) at find.c:2217 2217 if (!TEST_FLAG (TheFlag, rat)) (gdb) bt #0 LOCtoPadRat_callback (b=0xb70498a8, cl=0xbfd8b720) at find.c:2217 Ok, thanks.. that trace is useful - in that it tells us where the problem finally manifests, however what isn't clear, is just how some invalid pointer got into the rats r-tree in the first place. Valgrind might help there. Could you reproduce the crash once more under GDB, and if the backtrace looks the same, type: print rat (and if that doesn't work, print b) If the compiler hasn't optimised those away, it ought to tell us whether we're looking at a NULL pointer dereference, or (sadly more likely), some kind of corrupt pointer. Thanks for helping us get to the bottom of this. 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: problems with PCB and large board
On Tue, 2008-12-23 at 13:07 +, Peter Clifton wrote: On Tue, 2008-12-23 at 05:43 -0500, gene wrote: Maybe - I have to think about that. This represents a great deal of work on my part so I'm just a tad jumpy about it. But if I can't move forward then I really have little choice. Would you need just the .pcb file or also the schematic? It would just need to be the minimum PCB file required to reproduce the crash. If you can make a copy, remove 50% of the components, that's even better. (The smaller the test-case, the better). Specifically, we'd need a PCB file which had been saved after doing the load netlist operation. (Or we'd need the netlist along with the board). -- 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: problems with PCB and large board
I'm at work at the moment, so will tackle this when I get home tonight. thanks for the support! gene ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: problems with PCB and large board
If you can't send us a board, it may well be useful to grab valgrind apt-get install valgrind on debian or ubuntu, and run it under that: valgrind pcb pcblog.stdout 2pcblog.stderr. I run slackware, and see there is prebuilt package for valgrind - I'll give it a try and let you know how it goes. Could you reproduce the crash once more under GDB, and if the backtrace looks the same, type: print rat (and if that doesn't work, print b) If the compiler hasn't optimised those away, it ought to tell us whether we're looking at a NULL pointer dereference, or (sadly more likely), some kind of corrupt pointer. It's very repeatable. Here's the result: (gdb) run pcb Starting program: /usr/local/bin/pcb pcb Program received signal SIGSEGV, Segmentation fault. LOCtoPadRat_callback (b=0xb70ad8a8, cl=0xbffaa920) at find.c:2217 2217 if (!TEST_FLAG (TheFlag, rat)) (gdb) bt #0 LOCtoPadRat_callback (b=0xb70ad8a8, cl=0xbffaa920) at find.c:2217 #1 0x080ba88d in __r_search (node=0x9597c98, query=0xbffaa97c, arg=0xbffaa8cc) at rtree.c:539 #2 0x080ba8e3 in __r_search (node=0x9624108, query=0xbffaa97c, arg=0xbffaa8cc) at rtree.c:589 #3 0x080ba8e3 in __r_search (node=0x98ebe78, query=0xbffaa97c, arg=0xbffaa8cc) at rtree.c:589 #4 0x080ba8e3 in __r_search (node=0x9678f20, query=0xbffaa97c, arg=0xbffaa8cc) at rtree.c:589 #5 0x080ba8e3 in __r_search (node=0x9805ee0, query=0xbffaa97c, arg=0xbffaa8cc) at rtree.c:589 #6 0x080ba8e3 in __r_search (node=0x9561fc8, query=0xbffaa97c, arg=0xbffaa8cc) at rtree.c:589 #7 0x080ba95e in r_search (rtree=0x8ebd198, query=0xbffaa920, check_region=0, found_rectangle=0x808ae90 LOCtoPadRat_callback, cl=0xbffaa920) at rtree.c:625 #8 0x0808e198 in LookupLOConnectionsToPad (Pad=0x8b42470, LayerGroup=1) at find.c:2272 #9 0x08090761 in DoIt (AndRats=1 '\001', AndDraw=0 '\0') at find.c:869 #10 0x08091b96 in RatFindHook (type=512, ptr1=0xb7046ba8, ptr2=0x8b42470, ptr3=0x8b42470, undo=0 '\0', AndRats=1 '\001') at find.c:3247 #11 0x080b2f12 in GatherSubnets (Netl=0x904f7b0, NoWarn=0 '\0', AndRats=value optimized out) at rats.c:469 #12 0x080b41bd in AddAllRats (SelectedOnly=-88 '¨', funcp=0) at rats.c:740 #13 0x08062841 in ActionAddRats (argc=1, argv=0x8db6568, x=0, y=0) at action.c:3628 #14 0x080c81a4 in hid_actionv (name=0x9050c50 AddRats, argc=1, argv=0x8db6568) at hid/common/actions.c:219 #15 0x080c7db0 in hid_parse_actions (rstr=0x83328f8 AddRats(AllRats), function=0x80c80c0 hid_actionv) at hid/common/actions.c:287 #16 0x080e28cb in ghid_menu_cb (action=0x83579f8, data=0x8126480) at hid/gtk/gui-top-window.c:633 #17 0xb7a761df in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 ---Type return to continue, or q return to quit--- #18 0xb7a68e69 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #19 0xb7a7d61b in g_signal_handler_disconnect () from /usr/lib/libgobject-2.0.so.0 #20 0xb7a7f2af in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #21 0xb7a7f5f9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #22 0xb7c46985 in gtk_widget_get_action () from /usr/lib/libgtk-x11-2.0.so.0 #23 0xb7c48d44 in gtk_action_new () from /usr/lib/libgtk-x11-2.0.so.0 #24 0xb7a68e69 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #25 0xb7a7d61b in g_signal_handler_disconnect () from /usr/lib/libgobject-2.0.so.0 #26 0xb7a7efd7 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #27 0xb7a7f5f9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #28 0xb7c4285f in gtk_accel_group_activate () from /usr/lib/libgtk-x11-2.0.so.0 #29 0xb7c4296a in gtk_accel_groups_activate () from /usr/lib/libgtk-x11-2.0.so.0 #30 0xb7e69662 in gtk_window_activate_key () from /usr/lib/libgtk-x11-2.0.so.0 #31 0xb7e696fc in gtk_window_activate_key () from /usr/lib/libgtk-x11-2.0.so.0 #32 0xb7d36154 in gtk_marshal_BOOLEAN__VOID () from /usr/lib/libgtk-x11-2.0.so.0 #33 0xb7a67789 in g_value_set_static_boxed () from /usr/lib/libgobject-2.0.so.0 #34 0xb7a68e69 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #35 0xb7a7d7aa in g_signal_handler_disconnect () from /usr/lib/libgobject-2.0.so.0 #36 0xb7a7efd7 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #37 0xb7a7f5f9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #38 0xb7e54db7 in gtk_widget_get_default_style () from /usr/lib/libgtk-x11-2.0.so.0 #39 0xb7d2f48d in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #40 0xb7d30608 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #41 0xb7bb20ea in gdk_add_client_message_filter () from /usr/lib/libgdk-x11-2.0.so.0 #42 0xb79c5146 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #43 0xb79c84f3 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #44 0xb79c88d7 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #45 0xb7d30ae4 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #46 0x080e27d0 in ghid_do_export (options=0x0) at
Re: gEDA-user: problems with PCB and large board
valgrind output: pcb.stderr g...@geno:~/avTek/hardware/schematic$ valgrind pcb pcblog.stdout 2pcblog.stderr Segmentation fault g...@geno:~/avTek/hardware/schematic$ cat pcblog.stderr ==3971== Memcheck, a memory error detector. ==3971== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==3971== Using LibVEX rev 1854, a library for dynamic binary translation. ==3971== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==3971== Using valgrind-3.3.1, a dynamic binary instrumentation framework. ==3971== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==3971== For more details, rerun with: -v ==3971== ==3971== Invalid read of size 4 ==3971==at 0x45C1FE5: g_strjoinv (in /usr/lib/libglib-2.0.so.0.1600.6) ==3971==by 0x80D89CD: net_model_create (gui-netlist-window.c:391) ==3971==by 0x80D8EB8: ghid_netlist_window_show (gui-netlist-window.c:693) ==3971==by 0x80D948F: ghid_netlist_window_update (gui-netlist-window.c:952) ==3971==by 0x80D94B6: NetlistChanged (gui-netlist-window.c:977) ==3971==by 0x80C81A3: hid_actionv (actions.c:219) ==3971==by 0x80C8222: hid_action (actions.c:182) ==3971==by 0x8060E26: ActionLoadFrom (action.c:5633) ==3971==by 0x80C81A3: hid_actionv (actions.c:219) ==3971==by 0x80C81FD: hid_actionl (actions.c:197) ==3971==by 0x80CB994: Load (gtkhid-main.c:1813) ==3971==by 0x80C81A3: hid_actionv (actions.c:219) ==3971== Address 0x59d1b3c is 0 bytes after a block of size 4 alloc'd ==3971==at 0x4022909: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==3971==by 0x45A9044: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1600.6) ==3971==by 0x80D89AD: net_model_create (gui-netlist-window.c:388) ==3971==by 0x80D8EB8: ghid_netlist_window_show (gui-netlist-window.c:693) ==3971==by 0x80D948F: ghid_netlist_window_update (gui-netlist-window.c:952) ==3971==by 0x80D94B6: NetlistChanged (gui-netlist-window.c:977) ==3971==by 0x80C81A3: hid_actionv (actions.c:219) ==3971==by 0x80C8222: hid_action (actions.c:182) ==3971==by 0x8060E26: ActionLoadFrom (action.c:5633) ==3971==by 0x80C81A3: hid_actionv (actions.c:219) ==3971==by 0x80C81FD: hid_actionl (actions.c:197) ==3971==by 0x80CB994: Load (gtkhid-main.c:1813) ==3971== ==3971== Invalid read of size 1 ==3971==at 0x40247A6: strlen (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==3971==by 0x45C1FFD: g_strjoinv (in /usr/lib/libglib-2.0.so.0.1600.6) ==3971==by 0x80D89CD: net_model_create (gui-netlist-window.c:391) ==3971==by 0x80D8EB8: ghid_netlist_window_show (gui-netlist-window.c:693) ==3971==by 0x80D948F: ghid_netlist_window_update (gui-netlist-window.c:952) ==3971==by 0x80D94B6: NetlistChanged (gui-netlist-window.c:977) ==3971==by 0x80C81A3: hid_actionv (actions.c:219) ==3971==by 0x80C8222: hid_action (actions.c:182) ==3971==by 0x8060E26: ActionLoadFrom (action.c:5633) ==3971==by 0x80C81A3: hid_actionv (actions.c:219) ==3971==by 0x80C81FD: hid_actionl (actions.c:197) ==3971==by 0x80CB994: Load (gtkhid-main.c:1813) ==3971== Address 0x5aa7a60 is not stack'd, malloc'd or (recently) free'd ==3971== ==3971== Invalid read of size 1 ==3971==at 0x40247B1: strlen (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==3971==by 0x45C1FFD: g_strjoinv (in /usr/lib/libglib-2.0.so.0.1600.6) ==3971==by 0x80D89CD: net_model_create (gui-netlist-window.c:391) ==3971==by 0x80D8EB8: ghid_netlist_window_show (gui-netlist-window.c:693) ==3971==by 0x80D948F: ghid_netlist_window_update (gui-netlist-window.c:952) ==3971==by 0x80D94B6: NetlistChanged (gui-netlist-window.c:977) ==3971==by 0x80C81A3: hid_actionv (actions.c:219) ==3971==by 0x80C8222: hid_action (actions.c:182) ==3971==by 0x8060E26: ActionLoadFrom (action.c:5633) ==3971==by 0x80C81A3: hid_actionv (actions.c:219) ==3971==by 0x80C81FD: hid_actionl (actions.c:197) ==3971==by 0x80CB994: Load (gtkhid-main.c:1813) ==3971== Address 0x5aa7a61 is not stack'd, malloc'd or (recently) free'd ==3971== ==3971== Invalid read of size 4 ==3971==at 0x45C2001: g_strjoinv (in /usr/lib/libglib-2.0.so.0.1600.6) ==3971==by 0x80D89CD: net_model_create (gui-netlist-window.c:391) ==3971==by 0x80D8EB8: ghid_netlist_window_show (gui-netlist-window.c:693) ==3971==by 0x80D948F: ghid_netlist_window_update (gui-netlist-window.c:952) ==3971==by 0x80D94B6: NetlistChanged (gui-netlist-window.c:977) ==3971==by 0x80C81A3: hid_actionv (actions.c:219) ==3971==by 0x80C8222: hid_action (actions.c:182) ==3971==by 0x8060E26: ActionLoadFrom (action.c:5633) ==3971==by 0x80C81A3: hid_actionv (actions.c:219) ==3971==by 0x80C81FD: hid_actionl (actions.c:197) ==3971==by 0x80CB994: Load (gtkhid-main.c:1813) ==3971==by 0x80C81A3: hid_actionv (actions.c:219) ==3971== Address 0x59d1b40 is 4 bytes after a block of size 4 alloc'd ==3971==at 0x4022909: calloc (in
Re: gEDA-user: problems with PCB and large board
On Tue, 2008-12-23 at 19:13 -0500, gene wrote: ==3971== Invalid read of size 1 ==3971==at 0x40247B1: strlen (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==3971==by 0x45C1FFD: g_strjoinv (in /usr/lib/libglib-2.0.so.0.1600.6) ==3971==by 0x80D89CD: net_model_create (gui-netlist-window.c:391) Thanks.. I think that might land the blame on my shoulders... I'll have a poke and see what logic I messed up when I last touched that function. Notice how valgrind quit out much much sooner than the gdb backtrace. Often the real bug lies far before the crash occured. ==3971==by 0x80D8EB8: ghid_netlist_window_show (gui-netlist-window.c:693) ==3971==by 0x80D948F: ghid_netlist_window_update (gui-netlist-window.c:952) ==3971==by 0x80D94B6: NetlistChanged (gui-netlist-window.c:977) ==3971==by 0x80C81A3: hid_actionv (actions.c:219) ==3971==by 0x80C8222: hid_action (actions.c:182) ==3971==by 0x8060E26: ActionLoadFrom (action.c:5633) ==3971==by 0x80C81A3: hid_actionv (actions.c:219) ==3971==by 0x80C81FD: hid_actionl (actions.c:197) ==3971==by 0x80CB994: Load (gtkhid-main.c:1813) ==3971== Address 0x5aa7a61 is not stack'd, malloc'd or (recently) free'd -- 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: problems with PCB and large board
On Wed, 2008-12-24 at 01:02 +, Peter Clifton wrote: On Tue, 2008-12-23 at 19:13 -0500, gene wrote: ==3971== Invalid read of size 1 ==3971==at 0x40247B1: strlen (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==3971==by 0x45C1FFD: g_strjoinv (in /usr/lib/libglib-2.0.so.0.1600.6) ==3971==by 0x80D89CD: net_model_create (gui-netlist-window.c:391) Thanks.. I think that might land the blame on my shoulders... I'll have a poke and see what logic I messed up when I last touched that function. Notice how valgrind quit out much much sooner than the gdb backtrace. Often the real bug lies far before the crash occured. I pushed a fix to CVS. Could you update and rebuild? Alternatively, if you have the PCB sources from the last release, just apply this one line edit: diff --git a/src/hid/gtk/gui-netlist-window.c b/src/hid/gtk/gui-netlist-window.c index 147b05a..a37b063 100644 --- a/src/hid/gtk/gui-netlist-window.c +++ b/src/hid/gtk/gui-netlist-window.c @@ -385,7 +385,7 @@ net_model_create (void) parent_iter = new_iter; parent_ptr = parent_iter; -join_array = g_new0 (char *, try_depth + 1); +join_array = g_new0 (char *, try_depth + 2); memcpy (join_array, path_segments, sizeof (char *) * (try_depth + 1)); hash_string = g_strjoinv (NET_HIERARCHY_SEPARATOR, join_array); IE: in the file src/hid/gtk/gui-netlist-window.c, line 388, change the + 1 to a + 2. Hope that resolves the issue, if not - run valgrind again, and it may get further. -- 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: problems with PCB and large board
I can load the netlist from the menu, but when I try to optimize, the program bombs out with segmentation fault. Not surprising. The optimizer can be somewhat fragile at times. (The global puller is worse). Loading that brought the program to it's knees, You can see it trying to paint the screen, but it's painfully slow. The cross-hairs simply can't keep up with the mouse. The lesstif one works around this by only redrawing when the system is idle, which makes it a bit more usable for these heavy-draw cases. One last thing - is it possible to load all the parts into the work area but not located on the board itself? Nope, sorry. Now that I think of it, maybe the correct method is to make a large area, disperse all the parts, then draw an outline layer that represents the actual board. Is the accepted method? Yup. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: problems with PCB and large board
On Mon, 2008-12-22 at 22:40 -0500, DJ Delorie wrote: Loading that brought the program to it's knees, You can see it trying to paint the screen, but it's painfully slow. The cross-hairs simply can't keep up with the mouse. The lesstif one works around this by only redrawing when the system is idle, which makes it a bit more usable for these heavy-draw cases. GTK does this too - so lesstif ought not to win on those grounds. I don't expect you'd see a great deal of difference between them in fact. If you do try lesstif, and there is, please let me know. What is somewhat rubbish is that it always invalidates the whole screen, even when a partial repaint could make do. plug Try the GL enabled version I've been working on: git clone git://repo.or.cz/geda-pcb/pcjc2.git You want the before_pours branch, so then do: git checkout -b before_pours origin/before_pours (Which creates you a local branch called before_pours, based off the remote one.) The GL version is slightly less snappy than stock PCB for simple boards, but it seems to scale much better with increased board complexity. It has some experimental stuff which makes rendering boards with polygons faster as well. Seriously... test it! feedback is good, and will help to see this work merged. /plug One last thing - is it possible to load all the parts into the work area but not located on the board itself? Nope, sorry. But it probably will be possible in the future ;) -- 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: problems with PCB and large board
GTK does this too - so lesstif ought not to win on those grounds. Ah, good. /me wonders how much thindraw helps in these situations. I know if you have a lot of pads it slows things down (four lines instead of one). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: problems with PCB and large board
On Mon, 2008-12-22 at 22:40 -0500, DJ Delorie wrote: I can load the netlist from the menu, but when I try to optimize, the program bombs out with segmentation fault. Not surprising. The optimizer can be somewhat fragile at times. (The global puller is worse). Now, did Gene mean optimise as in Connects - Optimise routed tracks, or Connects - Optimise rats net (as in o shortcut). I read it as meaning the latter, at which point we really could do with a gdb backtrace of the problem, or (ideally) a test schematic so we can reproduce the problem here. gdb --args pcb path_to_board.pcb When it crashes, type bt (enter), and copy us the output. Gene, you can send a test file to one or more the developers (Dan, DJ, Ben, myself) privately, if you don't want to make it publicly available. Another good test, is to run pcb under valgrind (slow), and send us the output. 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
Re: gEDA-user: problems with PCB and large board
Now, did Gene mean optimise as in Connects - Optimise routed tracks, or Connects - Optimise rats net (as in o shortcut). Oh, good catch. I guess as the author of the other optimizer, I'm biased ;-) I read it as meaning the latter, at which point we really could do with a gdb backtrace of the problem, or (ideally) a test schematic so we can reproduce the problem here. Definitely. The rats nest optimizer should never crash. Another good test, is to run pcb under valgrind (slow), and send us the output. I have an even slower malloc checker I wrote myself that I can unleash on it, but if it's already crashing, that may not be needed. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
