segfault crash after using Move Object to Current Layer

I should note that the line you try to move to another layer also vanishes when you hit 'm', so that also shows something Bad is happening in the Move to Layer operation.

This bug exists in current git HEAD and I also reproduced it exactly in my 2011-05-13 build. In my 2011-02-21T023427+0000 git HEAD build, it causes a lockup of pcb rather than an immediate segfault, but the line still disappears when 'm' is hit and the optimize rats causes the lockup.

Verified lockup or crash in git HEAD all the way back to 2010-01-01 and in the 20091103 build I have. Ubuntu 11.04 (Natty)'s pcb package, version 20100929-2, also shows the bug (lockup on 'o').

FWIW, I've noticed a similar problem when I open and manipulate a .pcb file generated by pstoedit. When I try to move the polygons generated by the 'pcbfill' pstoedit output driver onto the 'silk' layer, they vanish instead of moving. I have to edit the .pcb file in a text editor to move the polygons to the silk layer.

A commit was made which affects this bug
git master commit 498e5dd36d279a16f2eff27b69967c6aa9f7c31f
http://git.gpleda.org/?p=pcb.git;a=commit;h=498e5dd36d279a16f2eff27b69967c6aa9f7c31f

commit 498e5dd36d279a16f2eff27b69967c6aa9f7c31f
Author: Peter Clifton <email address hidden>
Commit: Peter Clifton <email address hidden>

    move.c: Adjust the object counters when moving objects between layers

    This fixes a crash introduced by
    commit 2ce35292b9e96da38cb56878005aba20891689eb,
    "Convert board objects to GLists of g_slice allocated memory"

    It doesn't fix entirity of the defect reported in that bug, but
    it restores the prior behaviour where PCB would hang, not segfault.

    Reported-by: Colin Bennett <email address hidden>

    Affects-bug: lp-783640

This board has an illegal (or at least strange) layer group setup.. there is no layer on the second layer group (solder side), and that is where teh crux of the problem lies.

@Peter Clifton: I didn't realize it was illegal/strange, but rather thought it represented a single-sided PCB.

If you fix up the PCB file's layer group definition, even if you insist on grouping layers 1 and 2, e.g.:

Groups("1,2,c:s")

Then it works properly.

I suspect the thing to do is to teach PCB to recognise the buggy file on load time, and either fix it up or refuse to load it.

Basically PCB doesn't think the second layer belongs to anything (I'm surprised it doesn't cause more breakage than it has done).

If PCB is writing out layer groupings like this, then there is a bug. If the file was hand-edited to this state, then I think we just need to deal with loading it (or rejecting loading it) gracefully.

Trying with current Git master I can't reproduce any unexpected behaviour, much less a crash. Looking at the age and discussion of the bug I expect it to be fixed. If it persists, please open a new one or re-open this one. Thanks for reporting with test case.