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

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 2>pcblog.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@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user