Re: gEDA-user: What stops PCB autorouter/toporouter from working right?
On Wed, 2011-02-23 at 21:26 -0600, John Griessen wrote: On 02/23/2011 09:09 PM, John Griessen wrote: ==32105== Whatever the reason, Valgrind cannot continue. Sorry. Seems like the problem may not even be related to pcb... But it's triggered by pcb. The swap amount grows fast at first, then when about 3GB of RAm is used the rate slows to only 4 or so MB every other 2 secs. Every other time it goes down, but overall increases til it runs out. That's why it segfaults at 1.5 minutes. Is this kind of thing coming from compiler, or hardware, or? We have a winner from git bisect: 089fbaf59c78fe75475db737e7e2827cd745d570 is the first bad commit commit 089fbaf59c78fe75475db737e7e2827cd745d570 Author: Newell Jensen pillar2...@gmail.com Date: Sun Jan 23 01:46:53 2011 -0500 Initial C++ compatibility patch Doesn't cover lesstif or batch hids. Makes source code build without warnings on C, and build with warnings on C++. I do wish people would test their refactoring patches... -- 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!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: What stops PCB autorouter/toporouter from working right?
I do wish people would test I did test. I just didn't test 100% of what users can do. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: What stops PCB autorouter/toporouter from working right?
On Thu, 2011-02-24 at 18:52 -0500, DJ Delorie wrote: I do wish people would test I did test. I just didn't test 100% of what users can do. I was being unnecessarily mean I guess - its not like I've never broken anything through lack of adequate testing. The patch did have non-mechanical changes to the autorouter though, so a cursory check to ensure it still worked would have been nice. Btw.. the problem was fairly trivial and I just pushed a fix. -- 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!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: What stops PCB autorouter/toporouter from working right?
Btw.. the problem was fairly trivial and I just pushed a fix. Saw it, thanks! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: What stops PCB autorouter/toporouter from working right?
On Thu, 2011-02-24 at 19:07 -0500, DJ Delorie wrote: Btw.. the problem was fairly trivial and I just pushed a fix. Saw it, thanks! git bisect is such a blessing for regressions ;) We do a pretty good service turnaround on this kind of bug - John emailed me off list to note I could reproduce the bug using the LED example in the sources, and it took about 20 minutes of bisecting (I started way back), to find the commit. Total fix time was about 30 mins after I sat down to look at the problem. -- 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!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: What stops PCB autorouter/toporouter from working right?
On Thu, Feb 24, 2011 at 11:50:55PM +, Peter Clifton wrote: We have a winner from git bisect: 089fbaf59c78fe75475db737e7e2827cd745d570 is the first bad commit Git bisect can do wonders :) It seems that for loops in src/autoroute.c:BreakManyEdges() call directionIncrement() but ignore the return value. -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: What stops PCB autorouter/toporouter from working right?
On 02/23/2011 01:04 PM, John Griessen wrote: I have 1.6GB RAM free before starting connects--autoroute and all the RAM but 64K is used during autoroute for 12 seconds of CPU time over about 40 seconds. I wasn't reporting CPU time right though, it uses minutes, and I needed to subtract the time when I start to be meaningful. It's more like 5 or 6 minutes til it seg faults. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: What stops PCB autorouter/toporouter from working right?
On 02/23/2011 01:20 PM, John Griessen wrote: I wasn't reporting CPU time right though, top TIME+ uses minutes, and I needed to subtract the time when I start to be meaningful. It's more like 5 or 6 minutes of top TIME+, but only 1.5 minutes wall clock time til it seg faults. JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: What stops PCB autorouter/toporouter from working right?
On Wed, 2011-02-23 at 13:20 -0600, John Griessen wrote: On 02/23/2011 01:04 PM, John Griessen wrote: I have 1.6GB RAM free before starting connects--autoroute and all the RAM but 64K is used during autoroute for 12 seconds of CPU time over about 40 seconds. I wasn't reporting CPU time right though, it uses minutes, and I needed to subtract the time when I start to be meaningful. It's more like 5 or 6 minutes til it seg faults. Might well have eaten all your ram until it got a bad allocation, then dereferenced the NULL pointer it got. (Just a guess). Can you send the design file for me to investigate? -- 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!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: What stops PCB autorouter/toporouter from working right?
On 02/23/2011 01:39 PM, John Griessen wrote: On 02/23/2011 01:20 PM, John Griessen wrote: I wasn't reporting CPU time right though, top TIME+ uses minutes, and I needed to subtract the time when I start to be meaningful. It's more like 5 or 6 minutes of top TIME+, but only 1.5 minutes wall clock time til it seg faults. I ran this: valgrind --trace-children=yes pcb tek_tm_flex.pcb to get: HEAP SUMMARY: ==32108== in use at exit: 0 bytes in 0 blocks ==32108== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==32108== ==32108== All heap blocks were freed -- no leaks are possible ==32108== ==32108== For counts of detected and suppressed errors, rerun with: -v ==32108== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 6) PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 32m 1.6g 3008 D 15.9 82.3 2:19.18 memcheck-x86-li ==32105== Invalid write of size 8 ==32105==at 0x80A67CC: heap_insert (heap.c:186) ==32105==by 0x807515F: blocker_to_heap (autoroute.c:2448) ==32105==by 0x80D2BDF: __r_search (rtree.c:542) ==32105==by 0x80D2BFD: __r_search (rtree.c:592) ==32105==by 0x80D2BFD: __r_search (rtree.c:592) ==32105==by 0x80D2BFD: __r_search (rtree.c:592) ==32105==by 0x80D2BFD: __r_search (rtree.c:592) ==32105==by 0x80D2C7C: r_search (rtree.c:631) ==32105==by 0x80760EE: BreakManyEdges (autoroute.c:2843) ==32105==by 0x8078AE8: RouteOne (autoroute.c:4468) ==32105==by 0x807A11E: RouteAll (autoroute.c:4833) ==32105==by 0x807B894: AutoRoute (autoroute.c:5294) ==32105== Address 0xc is not stack'd, malloc'd or (recently) free'd ==32105== ==32105== ==32105== Process terminating with default action of signal 11 (SIGSEGV) ==32105== Access not within mapped region at address 0xC ==32105==at 0x80A67CC: heap_insert (heap.c:186) ==32105==by 0x807515F: blocker_to_heap (autoroute.c:2448) ==32105==by 0x80D2BDF: __r_search (rtree.c:542) ==32105==by 0x80D2BFD: __r_search (rtree.c:592) ==32105==by 0x80D2BFD: __r_search (rtree.c:592) ==32105==by 0x80D2BFD: __r_search (rtree.c:592) ==32105==by 0x80D2BFD: __r_search (rtree.c:592) ==32105==by 0x80D2C7C: r_search (rtree.c:631) ==32105==by 0x80760EE: BreakManyEdges (autoroute.c:2843) ==32105==by 0x8078AE8: RouteOne (autoroute.c:4468) ==32105==by 0x807A11E: RouteAll (autoroute.c:4833) ==32105==by 0x807B894: AutoRoute (autoroute.c:5294) ==32105== If you believe this happened as a result of a stack ==32105== overflow in your program's main thread (unlikely but ==32105== possible), you can try to increase the size of the ==32105== main thread stack using the --main-stacksize= flag. ==32105== The main thread stack size used in this run was 8388608. ==32105== ==32105== HEAP SUMMARY: ==32105== in use at exit: 2,251,685,103 bytes in 1,495,836 blocks ==32105== total heap usage: 1,763,572 allocs, 267,735 frees, 2,276,285,110 bytes allocated ==32105== ==32105== ==32105== Valgrind's memory management: out of memory: ==32105==newSuperblock's request for 5984256 bytes failed. ==32105==3100770304 bytes have already been allocated. ==32105== Valgrind cannot continue. Sorry. ==32105== ==32105== There are several possible reasons for this. ==32105== - You have some kind of memory limit in place. Look at the ==32105== output of 'ulimit -a'. Is there a limit on the size of ==32105== virtual memory or address space? ==32105== - You have run out of swap space. ==32105== - Valgrind has a bug. If you think this is the case or you are ==32105== not sure, please let us know and we'll try to fix it. ==32105== Please note that programs can take substantially more memory than ==32105== normal when running under Valgrind tools, eg. up to twice or ==32105== more, depending on the tool. On a 64-bit machine, Valgrind ==32105== should be able to make use of up 32GB memory. On a 32-bit ==32105== machine, Valgrind should be able to use all the memory available ==32105== to a single process, up to 4GB if that's how you have your ==32105== kernel configured. Most 32-bit Linux setups allow a maximum of ==32105== 3GB per process. ==32105== ==32105== Whatever the reason, Valgrind cannot continue. Sorry. Seems like the problem may not even be related to pcb... Hmmm JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: What stops PCB autorouter/toporouter from working right?
On 02/23/2011 09:09 PM, John Griessen wrote: ==32105== Whatever the reason, Valgrind cannot continue. Sorry. Seems like the problem may not even be related to pcb... But it's triggered by pcb. The swap amount grows fast at first, then when about 3GB of RAm is used the rate slows to only 4 or so MB every other 2 secs. Every other time it goes down, but overall increases til it runs out. That's why it segfaults at 1.5 minutes. Is this kind of thing coming from compiler, or hardware, or? JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
