Re: gEDA-user: What stops PCB autorouter/toporouter from working right?

[John Griessen <john@xxxxxxxxxxxxxx>]

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 %MEM    TIME+  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@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user