pcb

Undo in Names Only mode causes uninitialized variable access

Bug #1018103 reported by Russ Dill
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gEDA project
Confirmed
Critical
Unassigned
pcb
New
Undecided
Unassigned

Bug Description

Open PCB
Enable only names mode
Hit F2 (line drawing tool)
click on two locations on the canvas (draw line segment)
hit u

Traumflug (mah-jump-ing)
Changed in geda-project:
importance: Undecided → Critical
Revision history for this message
Traumflug (mah-jump-ing) wrote :

Confirmed. It happens after two clicks, no third click to end drawing the current line.

Backtrace:
#0 ActionUndo (argc=1, argv=0x0, x=8427520, y=8739024) at action.c:6286
#1 0x000000000049b48c in hid_actionv (name=name@entry=0xd16c10 "Undo", argc=argc@entry=0, argv=argv@entry=0x0)
    at hid/common/actions.c:243
#2 0x000000000049b9d9 in hid_parse_actionstring (rstr=0x975200 "Undo()", require_parens=require_parens@entry=1 '\001')
    at hid/common/actions.c:327
#3 0x000000000049ba8a in hid_parse_actions (str_=<optimized out>) at hid/common/actions.c:415
#4 0x00000000004cb538 in ghid_menu_cb (node=0x9751b0, action=<optimized out>) at hid/gtk/gui-top-window.c:365
#5 0x00007ffff5d1e2d5 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
[...]

Changed in geda-project:
status: New → Confirmed
Revision history for this message
Traumflug (mah-jump-ing) wrote :

It's the same crash point as with bug 930787.

Revision history for this message
Traumflug (mah-jump-ing) wrote :

The story is apparently as following: hittung Undo() tries to restore to a previous state and to find out what this previous state is, it queries with SearchObjectByLocation() for the object to remove. This works in normal mode. It does not work in names-only mode, because in this case SearchObjectByLocation() doesn't accept a line object and returns empty, NO_TYPE.

The comment in action.c, line 6281, stating that this query always succeeds, is wrong.

I can see four solutions:

1. Add a lot more special case code to check not only for mode flags like ONLYNAMESFLAG in search.c, but also under which conditions this search happens. This easily makes one special case for every other case. 3 names modes x 12 drawing modes = 36 cases.

2. Disable modes like track drawing mode while in names only mode. Also a lot of code and on top of this, unexpected user behaviour ("I can't draw tracks anymore and don't know why").

3. Try to make Undo() independent from this query. It's "Undo", after all, no "undo the object under the crosshair", after all.

4. Remove these special modes. That'd be LOCKNAMESFLAG, HIDENAMESFLAG and ONLYNAMESFLAG. Chances are good they're barely known anyways and modal behaviour is usually considered to be bad for an inutitive user interface. It should certainly be possible to prefer or avoid text by the standard means (hiding or activating the corresponding layers).

5.: 3. and 4. together.

I tend to do 4., then 3.

Revision history for this message
Traumflug (mah-jump-ing) wrote :

Just pushed three commits to make the undo code independent from the current cursor location (3. in above list). This should fix this particular bug. It's on branch LP1018103.

There are still 3 more cases with SearchObjectByLocation(), which all cause a segfault when in 'names only' mode.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.