Skip to content

Don't crash milltask when no tool data file is specified#3791

Open
BsAtHome wants to merge 1 commit intoLinuxCNC:masterfrom
BsAtHome:fix_tooldata-save
Open

Don't crash milltask when no tool data file is specified#3791
BsAtHome wants to merge 1 commit intoLinuxCNC:masterfrom
BsAtHome:fix_tooldata-save

Conversation

@BsAtHome
Copy link
Contributor

@BsAtHome BsAtHome commented Feb 6, 2026

This PR addresses a crash in milltask that happens when the ini-file lacks an entry for [EMCIO]TOOL_TABLE and a request is made to set a tool offset. The filename argument to tooldata_save() would be NULL and was naively dereferenced.


// filename == NULL happens without ini entry [EMCIO]TOOL_TABLE
// and a Task::emcToolSetOffset is performed.
if (!filename)
Copy link
Collaborator

@smoe smoe Feb 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bit later the filename may be assigned the value of DB_SPINDLE_SAVE. Your check may be a bit too early.

I suggest to always perform the filename[0]== 0 check (empty string test) rather than having it conditional for the !DB_ACTIVE branch and to prepend your test on NULL.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, you suggest:

if (db_mode == DB_ACTIVE) {
  if (!is_random_toolchanger) {return 0;}
  filename = DB_SPINDLE_SAVE; //one entry tbl (nonran only)
} else {
  if(!filename || !filename[0]) {
    UNEXPECTED_MSG;
    return -1; // Possibility one
    filename = ""; // Possibility two
  }
}

There are two possibilities to "recover". One is to return immediately with an error and two is to continue and let the fopen() fail. Having an empty filename is a distinct difference from having a NULL filename. Option two masks the actual error, filename being NULL. I don't think that is a good idea.
The second problem is that having filename NULL is actually not unexpected because it has at least one defined cause, where missing ini entry [EMCIO]TOOL_TABLE is one of them.

That would thus suggest a fix like this:

if (db_mode == DB_ACTIVE) {
  if (!is_random_toolchanger) {return 0;}
  filename = DB_SPINDLE_SAVE; //one entry tbl (nonran only)
} else {
  if(!filename) {
    fprintf(stderr, "%s: No filename. Are you missing INI-entry [EMCIO]TOOL_TABLE?",
        __PRETTY_FUNCTION__);
    return -1;
  }
  if(filename[0] == 0) {
    UNEXPECTED_MSG;
  }
}

What do you say?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How much do you trust DB_SPINDLE_SAVE?

include/tooldata.hh:#define DB_SPINDLE_SAVE "./db_spindle.tbl"

I would prefer to always test for the filename to be != NULL, which I think make things simpler:

if (db_mode == DB_ACTIVE) {
  if (!is_random_toolchanger) {return 0;}
  filename = DB_SPINDLE_SAVE; //one entry tbl (nonran only)
} 
if(!filename) {
  fprintf(stderr, "%s: No filename. ", __PRETTY_FUNCTION__);
  if (db_mode == DB_ACTIVE) {
     fprintf(stderr,"Internal programming error.\n");
  } else {
     fprintf(stderr,"Are you missing INI-entry [EMCIO]TOOL_TABLE?\n");
  }
  return -1;
}
if(filename[0] == 0) {
  UNEXPECTED_MSG;
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants