Topics

5.22 beta - Crashed on saving an XTI File #Bug #beta


Ian
 

This one is a goody! For starters, the system has been irregularly crashing immediately on startup. Nothing gets saved to the log file, it just crashes so I have to start it again. And again, 2 or sometimes even 3 times if it is in the mood.
But this time it has been working away solidly and saving and everything else I could want from it. Till now. I brought in a simple XTI file. I Ungrouped it, deleted 2 lines then re-Grouped it. All good. Then I Selected it and asked it to Export to an XTI with a slightly different file name. It crashed with a message asking if I wanted to save my file. 

Now we get to the good part. If you look at the attached JPG and read the text it points to a file located at User/Russell. There has never ever ever been a user Russel on this machine. My name is Ian and I have always been the only User so just where in the Heck did it drag that message from?

Attached are the requisite files in case you can glean some information from them. These are the files with similar timestamps but that LOG file is HUGE. There needs to be a way of paring that down and removing outdated Data. (Because that file is so big GMail has dumped all files up into the Cloud.)

--
-- Ian


Russell Shilling
 

The path is the file from my development system, telling us where the error occurred in the source code. You can edit the log file yourself to reduce the size. Simply delete the blocks of lines that are really old, for example. 
--
Russell Shilling
http://shilling-or.com


Adam Richards
 

Ian, 
Please give access to any Google files you post (helps to be able to read them). 

Really speaking we aren't intending the log to be a debug for entire runs like this. It has Waaaaayy too much info with every mouse movement from startup onwards.  It is very useful in specific instances. As a rule I would only use it if we need to and so we asked. In this case understanding what you are exporting may be enough.  What are the elements that you (re)grouped? Was "replace with new group" checked?  And what are the elements you tried to export including the group (I assume)? 

The error message is saying that one of the elements selected to be exported or referenced by the export was marked for deletion or was an invalid track. The former is more likely as a slip somehow where a deleted track was referenced somehow, but it is possible that the latter occurred if the chain of tracks became corrupted (which would go with the next paragraph).  Unfortunately this routine is a safety check that is run at a low-level and does not reveal who the caller is - which would narrow the search a lot.

I am also interested in the startup failures - this should not be happening.  As you don't get a failure message, it would most likely be an OS check because of bad memory access that crashed the program rather than a logical error in a param or a checkpoint. The randomness is typical of the use of uninitialized memory. This may be strongly related to which build level and which OS build you are running on. Can you remind us?  For these failures, the most useful thing you could do would be to run the program under gdb (lldb on Mac) so that when this occurs the debugger would start and we could at least get the reference error and the stacktrace (command bt).  That would reveal who is accessing what and so enable some actual debugging.

Adam

On Tue, Mar 9, 2021 at 5:29 AM Ian <ilox11@...> wrote:
This one is a goody! For starters, the system has been irregularly crashing immediately on startup. Nothing gets saved to the log file, it just crashes so I have to start it again. And again, 2 or sometimes even 3 times if it is in the mood.
But this time it has been working away solidly and saving and everything else I could want from it. Till now. I brought in a simple XTI file. I Ungrouped it, deleted 2 lines then re-Grouped it. All good. Then I Selected it and asked it to Export to an XTI with a slightly different file name. It crashed with a message asking if I wanted to save my file. 

Now we get to the good part. If you look at the attached JPG and read the text it points to a file located at User/Russell. There has never ever ever been a user Russel on this machine. My name is Ian and I have always been the only User so just where in the Heck did it drag that message from?

Attached are the requisite files in case you can glean some information from them. These are the files with similar timestamps but that LOG file is HUGE. There needs to be a way of paring that down and removing outdated Data. (Because that file is so big GMail has dumped all files up into the Cloud.)

--
-- Ian



--
Adam Richards


Dave Bullis
 

There are 2 issues here:

Crash on startup:
Turn on debug logging (init and command)
Delete your xtclog.txt file and startup xtrkcad.
If you get a crash, post the xtclog.txt file
If not repeat until you do.
Turn off the debug logging (init and command): these are not required beyond start up crashing.

Assert on import/export xti file:
The .xti file is required to proceed.
You said it was 'simple'.
Are you grouping a number of tracks so all of the .xti is 1 TURNOUT object?
If so:
The intent of Group is to build structures, decorate turnouts and maybe combine a few turnouts into something complex.
Unfortunately we can't prevent users from grouping their entire layout (except for the 127 segment limit).
Consequently there will be issues.
That said, I've rewritten Group code for 5.3.0 so you might have an interesting test case.

We should make the message clear that this is an internal error, not to be understood by mere mortals ;-)

Dave


Adam Richards
 

Dave, 
But the "issues" really should not include total failures like this....  Yes, the group written out might not be perfect in all respects and your valiant efforts would aim to improve that, but this failure implies that the integrity of the layout's objects became corrupted (or we had a logical failure because we forgot something when deleting the tracks that were grouped, or we tried to include something we that shouldn't have, or something similar). 

I would like to know 

- what was grouped and (assumption) if "replace" was set on in the grouping -> because that's about deletion and did we get everything
- what was selected to be exported, and if that selection was "de novo" or was done with the selected items being added (this may depend on the selection mode in use). That's because if there's a way the old elements remained selected after being deleted....

I have just noticed that when a Group of a single track completes if "replace" is on, the system still believes there are some items selected (because Export and Rotate and Move, etc are not greyed out) but Group knows there aren't if you ask to Group again "no items selected". On my system, Exporting in that condition leads to a .xti with no tracks.  So that lack of deselecting the (presumably old, deleted, objects) is odd. I looked at the UndoDelete logic and it is marking the track as deleted, but it doesn't seem to force them to be deselected. 

Adam


Adam Richards
 

I'm getting a failure to compile ctodesign.c because DIST_INF is not defined.  It includes common-ui.h but not common.h. 

Is common supposed to be included, or is the value also supposed to be in common-ui.h? 

Adam


Dave Bullis
 

The #define DIST_INF is in the WINDOWS specific section of common.h
It should be moved to the common section

Dave


Dave Bullis
 

Pushed


Adam Richards
 

Found a similar bug while looking - Joining two tracks, CmdPull called JoinAdjustableTracks for two straights. But the new check logic blew up when cturnout addressed the extradata as though it was turnout extension (it was quickly going to abandon when it found out no it wasn't by testing tracktype but it accessed the extensions first). 

So - easy to fix this one - but the symptoms are very similar to the complaint (blown assert about track types). Question - do we intend to release like that or would that be reserved for dev build levels?  I am worried we might see a lot of stuff. 

Adam

 


Adam Richards
 

Fixed the hangover from Group selected in a replace group situation as well as Pull as above.


Dave Bullis
 

I'd prefer to keep the tests in place.
We could add an escape hatch (a preference to suppress the check) so users don't get struck

The ASSERT that started this thread has been around since the begining and is not connected to this.

Dave

PS Ian: we still need those files!


Ian
 

Hello Adam, it was very late at night, probably closer to early morning when I experienced the problem and sent off the files. I never registered that I then had to go in and allow access to them.
I am deeply sorry that I left you and everybody else stranded like that.

I have now set up two icons - 1 with the Log generation details, the other just a standard start.
So, firstly, there are no track elements in that XTI and I have no idea why it would give that kind of error message. 
(I have attached the original file so you can check that it should just a series of lines.)

On starting the program, I will have 1 or 2 times when it begins to start and immediately stops. Nothing is written to the log file so that is partly why I don't bother to run with the logging on, it doesn't record why it shuts down.

Next time it starts it will stay on and I can get hours of working out of it - until at times it will do silly things like shut down after a Save As or perhaps shut down after Saving an XTI file. Nothing is consistent other that most of the time it is when asked to Save itself or a similar task.

This is on a Windows 10 machine with 20G of RAM. 



--
-- Ian


Dave Bullis
 

I've triggered a crash on Ubuntu.
Unfortunately its in gtklib so maybe unrelated to windows.
wFilSelect() was realloc'ing a buffer for appending an extension onto the filename but wasn't alloc'ing from for the terminating \0

This bug has been around for a very long time (Oct 2016).  Hard to believe no one else has tripped on it.

Pushed for Unbuntu.

The corresponind mswlib code looks ok.  Mystery!

Meanwhile the start up crash is still outstanding.
Ian: the last entry in xtclog.txt was Mar 9 22:12:13.  No sign of a crash.
Can you do
Turn on debug logging (init and command)
Delete your xtclog.txt file and startup xtrkcad.
If you get a crash, post the xtclog.txt file
If not repeat until you do.
Turn off the debug logging (init and command): these are not required beyond start up crashing.


Rob Pearce
 

On 11/03/2021 17:07, Dave Bullis wrote:
This bug has been around for a very long time (Oct 2016).  Hard to believe no one else has tripped on it.
Well, one thing with that sort of bug is that alloc always rounds up the required size to a multiple of the largest simple data type, so 75% of the time it does allocate space for the NULL, more on a 64 bit machine.


Ian
 

Dave said:
" Turn on debug logging (init and command)
Delete your xtclog.txt file and startup xtrkcad.
If you get a crash, post the xtclog.txt file
If not repeat until you do.
Turn off the debug logging (init and command)  "

Just checking to be sure I have this right, at its time I am turning on logging with the starting icon... 
"C:\Program Files\XTrackCAD\bin\xtrkcad.exe" /d init=3 /d command=3
--
-- Ian


Dave Bullis
 

looks good but I'm not a windows guy

To check:
delete xtclog.txt
start with your icon
check that there is something in xtclog.xtc
repeat until it fails

Dave


Ian
 

LOL repeated till my mouse failed.
I will try another session in the morning.

On Sat, 13 Mar 2021, 00:39 Dave Bullis, <sillub@...> wrote:
looks good but I'm not a windows guy

To check:
delete xtclog.txt
start with your icon
check that there is something in xtclog.xtc
repeat until it fails

Dave


Ian
 

quick update... first thing this morning... deleted the log,   started it,  saw the screen show for a second... then crash and no log file written. Hmmm.

So, 3 good starts later and here is a broken log showing where the crash took place

# XTrackCAD Version: 5.2.2Beta1, Date: Sat Mar 13 10:53:44 2021

initCustom
create main window
fontInit
fileInit
set roomsize
initInfoBar
misc2Init
paramInit
initTrkTrack
createMenus
initialize
loadFileList
drawInit
paramFileInit
Reset
COMMAND CANCEL cmdDescribe
COMMAND MOUSE cmdDescribe 20 @ 0.000 0.000
COMMAND RESET cmdDescribe
the end
Initialization complete
COMMAND MOUSE cmdDescribe 20 @ 0.000 0.000
COMMAND MOUSE cmdDescribe 1 @ -0.669 -0.630
COMMAND MOUSE cmdDescribe 20 @ 0.000 0.000
COMMAND CANCEL cmdDescribe
COMMAND MOUSE cmdDescribe 20 @ 0.000 0.000
COMMAND RESET cmdDescribe

5 more good starts then 2 bad starts and logged

Altogether, out of about 15 or x number starts I have been able to get 4 log entries for crashes.

I do hope this helps. Will now return you to your regular broadcast.


Dave Bullis
 

After too much time looking at assembler code this is the issue I described here`
I was finally able to trigger this in the win64 version and used just-in-time debugging to confirm that ConvertUTF8ToSystem was on the call path.

I'll have to set up a win64 build environment and test it out but I think we can put this to bed.

Ian: why do you keep breaking things?  Keep up the good work.

Dave


Dave Bullis
 

I reproduce the startup crash with 5.2.2b1 but not with 5.2.2b2
In any case I fixed the problem noted below.

'crashing on saving an XTI file' is still open on Windows in 5.2.2b1 but not 5.2.2b2

Dave