I tried this (V5.3.1 Ubuntu 24.04) and cannot recreate it
Can you post the .xtc and which objects you tried to Describe?
Also, the traceback
What does 'another line' refer to?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Am 03.01.2026 04:37 schrieb Dave Bullis <sillub@users.sourceforge.net>:
I tried this (V5.3.1 Ubuntu 24.04) and cannot recreate it
Can you post the .xtc and which objects you tried to Describe?
Also, the traceback
What does 'another line' refer to?
---
**[bugs:#605] Crash in Describe**
**Status:** open
**Milestone:** Next Release
**Created:** Fri Jan 02, 2026 11:08 PM UTC by Adam Richards
**Last Updated:** Fri Jan 02, 2026 11:15 PM UTC
**Owner:** nobody
A selection of Describe on the layout with the Describe window already open but before changing any fields seems to cause an immediate crash.
---
Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/xtrkcad-fork/bugs/605/>
To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Running under LLDB when the error happens its a bad memory access at GetTrkType+16 called from CmdDescribe + 911 called from DoCurCommand +787. Based on the instruction dump it seems to be about to compare something to T_NOTRACK but the address used is 0xc off %rax which has 0x00000000 in it. So that would seem to be an uninitialized pointer to the track.
I would note that I am using a lot of modules and some of them are frozen, so it may be possible I tried to Describe a frozen track element or something similar. Usually I get a message that I need to use "+Shift" to Describe a frozen element. But I'll see if I can pin it down a little more.
BTW - Looks like whoever did the Mac compile did not set on the Debug option which is. why I am reading machine code and not C in debug.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Seems like the most obvious thing is that something reset trk in static to NULL soon before the GetTrkType call at line 645. The simplest explanation is that DescribeTrack() did this but I don't think function calls have access to the caller's memory to reset it.
The type of track was supposed to be a Draw object in this case, BTW. A straight line in fact. I had one already in describe and I selected another one with the Describe window open. It was about the second time I did this that the error occurred.
Incidentally, why is the track_p trk variable declared as static in the CmdDescribe() function? This ensures it will not be re-initialized for every invocation and is shared between calls. That might be important as the code can be called back for one track object by GTK to close the describe window at a similar time to being called to open the window for another one. It also makes the value more vulnerable to "trampling" by neighbors. There is already a static descTrk that is used as the saved pointer to a track that has been selected.
There are now a couple of issues I have seen with Describe for Draw objects. (The other is the failure to update Text now that the "Done" button has been removed). I have also noticed that an update in the describe window also removes the rotation of the Text if it has been rotated previously. I imagine that Text draw objects in particular were overlooked when Describe updating was made "instant", so I imagine that other issues may have been introduced and not found in testing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So if I don't close the Describe window first and then open a new Describe I eventually get the bad address program failure (5 or so interations). If I do close the Describe window I get the message about the track not being the right type failure eventually (5 or so iterations).
re static trk: it is set on any mouse action (START, DOWN, MOVE UP wMove).
It is used in REDRAW and CMDMENU ( but protected by if()
I don't think that is the issue
re: rotation - looks like bug 559. Very complex
Still can't recreate it.
I'm using T317 @ (102,98) and T333 @(175,110) (both lines)
Hover on T317, Enter describe cmd (Ctrl+Shift+'?'), Click: prop window for T317 opens
Click on T333 - prop window open
Repeat on T317 - ok
Repeat at least 10 times - no problem
Repeat with closing the property window each time - no problem
Is this your test case?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am wondering if we get a race between the first track/draw Describe (which closes the window) and the second (which "re"opens it) and in the process the trk which is in static can be overwritten and cause the subsequent calls to have a NULL track.
If C_START runs (new command) or C_DOWN runs or ActionMove (if the track being hovered over) is frozen they all clear trk. But If the previous call instance was inside DescribeTrack while this happened and then ran (because, the click was fast enough to overlap the window being launched), the trk might have been cleared but the code assumes it is still in control and GetTrkType will abort.
Notably the code comment reads
// Ugly code: but Describe Notes do not continue like other objects
Last edit: Adam Richards 2026-01-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually can happen after closing describe and then selecting another line.
I tried this (V5.3.1 Ubuntu 24.04) and cannot recreate it
Can you post the .xtc and which objects you tried to Describe?
Also, the traceback
What does 'another line' refer to?
This is the GA release level. Downloaded.
Running under LLDB when the error happens its a bad memory access at GetTrkType+16 called from CmdDescribe + 911 called from DoCurCommand +787. Based on the instruction dump it seems to be about to compare something to T_NOTRACK but the address used is 0xc off %rax which has 0x00000000 in it. So that would seem to be an uninitialized pointer to the track.
I would note that I am using a lot of modules and some of them are frozen, so it may be possible I tried to Describe a frozen track element or something similar. Usually I get a message that I need to use "+Shift" to Describe a frozen element. But I'll see if I can pin it down a little more.
BTW - Looks like whoever did the Mac compile did not set on the Debug option which is. why I am reading machine code and not C in debug.
Seems like the most obvious thing is that something reset trk in static to NULL soon before the GetTrkType call at line 645. The simplest explanation is that DescribeTrack() did this but I don't think function calls have access to the caller's memory to reset it.
The type of track was supposed to be a Draw object in this case, BTW. A straight line in fact. I had one already in describe and I selected another one with the Describe window open. It was about the second time I did this that the error occurred.
Incidentally, why is the track_p trk variable declared as static in the CmdDescribe() function? This ensures it will not be re-initialized for every invocation and is shared between calls. That might be important as the code can be called back for one track object by GTK to close the describe window at a similar time to being called to open the window for another one. It also makes the value more vulnerable to "trampling" by neighbors. There is already a static descTrk that is used as the saved pointer to a track that has been selected.
There are now a couple of issues I have seen with Describe for Draw objects. (The other is the failure to update Text now that the "Done" button has been removed). I have also noticed that an update in the describe window also removes the rotation of the Text if it has been rotated previously. I imagine that Text draw objects in particular were overlooked when Describe updating was made "instant", so I imagine that other issues may have been introduced and not found in testing.
Tried Describe-Draw-Object-1 ->Close->Describe-Draw-Object-2 in a loop. Third time around on the same two objects I got
"trkType == T_NOTRACK || trk->type == trkType: /Users/kshaffer/src/xtrkcad/app/bin/track.c:458
Do you want to save your layout?"
I had not altered anything.
BackTrace
Last edit: Adam Richards 2026-01-03
So if I don't close the Describe window first and then open a new Describe I eventually get the bad address program failure (5 or so interations). If I do close the Describe window I get the message about the track not being the right type failure eventually (5 or so iterations).
Too late to do more today.
Attached is the xtc I am using.
Last edit: Adam Richards 2026-01-03
re static trk: it is set on any mouse action (START, DOWN, MOVE UP wMove).
It is used in REDRAW and CMDMENU ( but protected by if()
I don't think that is the issue
re: rotation - looks like bug 559. Very complex
Still can't recreate it.
I'm using T317 @ (102,98) and T333 @(175,110) (both lines)
Hover on T317, Enter describe cmd (Ctrl+Shift+'?'), Click: prop window for T317 opens
Click on T333 - prop window open
Repeat on T317 - ok
Repeat at least 10 times - no problem
Repeat with closing the property window each time - no problem
Is this your test case?
I am wondering if we get a race between the first track/draw Describe (which closes the window) and the second (which "re"opens it) and in the process the trk which is in static can be overwritten and cause the subsequent calls to have a NULL track.
If C_START runs (new command) or C_DOWN runs or ActionMove (if the track being hovered over) is frozen they all clear trk. But If the previous call instance was inside DescribeTrack while this happened and then ran (because, the click was fast enough to overlap the window being launched), the trk might have been cleared but the code assumes it is still in control and GetTrkType will abort.
Notably the code comment reads
Last edit: Adam Richards 2026-01-03
So I think that moving over some frozen track and clicking or rapid clicking on different objects in Describe Command may trigger this problem.