Someone with more experience please correct me if I&#= 39;m wrong, but I think that removing the text from the rtree is basically = the entire point of EraseText. It removes the object from the rtree, and fl= ags the area for being redrawn. If the object is removed from the rtree the= n it wont be found when drawing occurs, and so it wont be drawn. So, I'= m not sure that commenting that line is the right thing to do.

It looks like, in most cases, you can get away with commenting this l= ine because almost all of the functions that call EraseText also try to rem= ove the object from the rtree anyway, but not all of them. If you compile w= ith debugging enabled, you get a failed assertion in when you change text. = Just put some text on an empty layout, put the arrow over it, hit n, input = new text, hit enter, and crash.

I think maybe a the error= is actually in EraseObject, which calls EraseText for both TEXT_TYPE and E= LEMENTNAME_TYPE. This is problematic for two reasons. First, if EraseObject= is getting an element name, then as you noted, lptr will be pointing to an= element not a layer (the result of SearchObjectByID), as you pointed out. = Second, the text types associated with element names are not stored in the = layer rtree, but rather in one of the PCB->Data rtrees.

I think a better solution is that when EraseObject gets an ELEMENTNAME_TY= PE, it should call EraseElementName instead of EraseText.

I pushed this fix to the repo home/cparker/LP1631059.

Th= is has highlighted a couple other problems though. When you undo changing t= he size of a text type (not an element name) it disappears. There's als= o an issue of UndoChangeSize using the Thickness parameter, which is of typ= e Coord, but for text objects, the Size parameter is of type int. So there&= #39;s still a mismatch there. Could be the cause and effect. I'll look = into it a bit more later.

On Thu, Oct 6, 2016 at 12:26 PM, Milan Prochac (milan AT prochac DOT sk) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com>= wrote:

On 06.10.2016 11:44, Richard Rasker (rasker AT linetec DOT nl) [via geda-user AT delorie DOT com] wrote:

Hello,

There appears to be a little segfault problem in PCB version 1.99z,
build Sep 13 2016 at 08:12:51, used on Linux Mint 17.3 KDE:

When I change the size of a RefDes text using the S key, and then try to undo this action using the U key, PCB crashes. This also happens when
the resize action is followed by other actions; when subsequently
undoing these using U, PCB crashes the moment that it tries to undo the
RefDes text resize. As far as I can tell, this bug only pertains to
Refdes text, not to other elements.

It's not a big deal, but still a little annoying to have some minutes o= f
work vanish when unthinkingly pressing the U key.

Best regards,

Richard Rasker

Bug logged and patch provided here: https://bugs.launchpa= d.net/pcb/+bug/1631059

Patch solves the issue (2 issues in fact), undo/redo works fine. But second= pair of eyes should check if the patch has some unwanted side effects. Mor= e details on Launchpad.

Milan