Failed autorouter, missing pins in netlist, bad undo serial, etc etc

[Keantoken]

Debian Sid AMD64

Steps to reproduce from new project in pcb-gtk 20140316:

1: Place 10-pin headers on schematic (HEADER10_1)

2: Name them (a,b,c, and so on).

3: Select rats layer and line tool, and draw rats between the headers.

4: Connect -> autoroute all rats

Example output:

Can't find pin 4 called for in netlist.
Can't find pin 8 called for in netlist.
Can't find pin 7 called for in netlist.
Can't find pin 3 called for in netlist.
Can't find pin 4 called for in netlist.
Can't find pin 4 called for in netlist.
Can't find pin 3 called for in netlist.
Can't find pin 3 called for in netlist.
Can't find pin 9 called for in netlist.
Can't find pin 10 called for in netlist.
Can't find pin 9 called for in netlist.
Can't find pin 1 called for in netlist.
Can't find pin 2 called for in netlist.
Can't find pin 10 called for in netlist.
Can't find pin 2 called for in netlist.
Can't find pin 1 called for in netlist.
0 of 0 nets successfully routed.
Total added wire length = 0, 0 vias added

5: Undo, and notice bad undo serial number in the message log.

ERROR: Bad undo serial number 17 in undo stack - expecting 16 or lower
       Please save your work and report this bug.

6: Notice that even after you have undone the rats, you cannot redraw the rats:

Both connections already in netlist - cannot merge nets

I got it to work once and only once, but I don't know how. Maybe I am just doing it wrong? Autorouting without a netlist should be easy but so far there's only crickets on the IRC channel, and can't find any tutorials about it.

[Keantoken (keantoken)]

I can cause a segfault with test.pcb this way:

1: open test.pcb

2: Connects-> erase ratsnest.

3: Draw rat from a-10 to B-8

4: Connects -> autoroute all rats

strace output attached

gdb backtrace:

(gdb) backtrace
#0 0x000000000043a128 in ?? ()
#1 0x000000000043dba5 in AutoRoute ()
#2 0x0000000000430ebf in ?? ()
#3 0x000000000049f479 in hid_actionv ()
#4 0x000000000049fa1a in ?? ()
#5 0x00000000004cf588 in ?? ()
#6 0x00007ffff5f862d5 in g_closure_invoke ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7 0x00007ffff5f9803c in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8 0x00007ffff5fa0698 in g_signal_emit_valist ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9 0x00007ffff5fa08ff in g_signal_emit ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x00007ffff6da98d0 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#11 0x00007ffff5f86504 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#12 0x00007ffff5f9ffa7 in g_signal_emit_valist ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#13 0x00007ffff5fa08ff in g_signal_emit ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#14 0x00007ffff6f7dc56 in gtk_widget_activate ()
---Type <return> to continue, or q <return> to quit---
   from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#15 0x00007ffff6e7998d in gtk_menu_shell_activate_item ()
   from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#16 0x00007ffff6e79d2b in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#17 0x00007ffff6e67a7f in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#18 0x00007ffff5f862d5 in g_closure_invoke ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x00007ffff5f97f32 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x00007ffff5fa01a5 in g_signal_emit_valist ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#21 0x00007ffff5fa08ff in g_signal_emit ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#22 0x00007ffff6f7eecc in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#23 0x00007ffff6e661c4 in gtk_propagate_event ()
   from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#24 0x00007ffff6e6665b in gtk_main_do_event ()
   from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#25 0x00007ffff6ad9bbc in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#26 0x00007ffff73c8c3d in g_main_context_dispatch ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x00007ffff73c8f20 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#28 0x00007ffff73c9242 in g_main_loop_run ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#29 0x00007ffff6e655d7 in gtk_main ()
   from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#30 0x00000000004d1072 in ghid_do_export ()
#31 0x0000000000426b7e in main ()

[Keantoken (keantoken)]

BTW I even had XFCE crash once while reproduing the above segfault.

I have almost NEVER had a linux installation that didn't fill the terminal with gtk and Glib errors.
For PCB, whenever I:

A: click on the blank canvas
B: move the mouse on to the canvas from the edge of the window.
C: let the mouse stop on the canvas and then move it

I get the following messages:

(pcb-gtk:2293): GLib-CRITICAL **: Source ID 128 was not found when attempting to remove it

(pcb-gtk:2293): GLib-CRITICAL **: Source ID 274 was not found when attempting to remove it

[Traumflug (mah-jump-ing)]

I take that there are Gtk warnings. Just like with almost every other Gtk application.

If there are other bugs, please report them seperately ... after searching for similar ones.

[Chad Parker (parker-charles)]

Regarding the original bug report:

1. The undo errors have been solved by other bug fixes.

2. I believe the "can't find pin" errors are the result of the names chosen for the connectors. Replacing "a", "b", and "c", with "J1", "J2", and "J3" (in the file prior to loading) allows the connections to autoroute normally.

Note: see this page on the wiki
http://wiki.geda-project.org/geda:pcb_tips
specifically the 4th bullet of the section titled "I want to draw a track between two segments on the same net, but PCB won't let me! Why?" which notes that lower case letters at the end of ref des are used to indicate slots on devices.

[Chad Parker (parker-charles)]

Regarding the segmentation fault reported by keantoken I believe this is also related to the choice of reference designators. Following the outlined procedure with the file containing J1, J2, and J3 instead does not fault. (note that it must be replaced in both the element definitions and in the net list.)

Executing the procedure on the original file with pcb built with debugging symbols defined, results in an assertion failure:

Assertion failed: (__next_one__), function CreateRouteData, file autoroute.c, line 1154.

The assertion is actually inside the LIST_LOOP macro and is executed in the first argument to the macro is null.

[Chad Parker (parker-charles)]

I guess there are a couple of options for things we can do with this.

One option would be to allow any string to be a reference designator. This would be the ideal solution in my opinion. However, it may break compatibility with the current interaction between gschem and pcb.

Another alternative is to prohibit reference designators that are strings of one or more lower case letters. This strikes me as more of a cludge, but, keeps everything playing nicely together. We would have to apply this check in a lot of places though... off the top of my head: Loading pcb files, loading netlists, adding elements to the layout, changing the designator text of an element...

Unfortunately, I think the second solution is the more likely one for now.

[DJ Delorie (djdelorie)]

I would like to get rid of the "trailing lower case letters means slot" think about refdes's, although I say this KNOWING that it would break backward compatibility... sigh.

[Chad Parker (parker-charles)]

Agreed. However, because of the compatibility issues, that might have to be a future 5.0 thing.

One question is, does pcb actually care about slots? I guess if you want to be able to reassign slots while doing layout, then this is useful information to have. Do we have that capability now? If not, then why does this sensitivity currently exist? For future expansion?

In other software that I've used, you have to define what sets of pins are swappable with which other sets. It's not done with ref-des.