QNX2 parsing error output from memory exception?

So this is a situation entirely removed from the previous things I’ve been trying to sort out.

One of our operators encountered an issue with a system during normal operation.
{behavior not important}

He said restarting allows it to work again for a short period, and I tell him to show me.
He doesn’t actually restart the computer, he just stops the software tasks, then reloads them to start the test program again.

when he does this, I notice an error briefly appear in the status bar at the bottom of the screen.

/das/sys/acl_vm 1039 - Terminated at 0698:301f. MEMORY exception 0400.

How are these messages meant to be interpreted?

  • I am assuming it is telling me that the task/program encountering the error would be “acl_vm”
  • it is a memory violation, hex value 0400 as outlined in the QNX manual at 10.3.3 page 104

But what do the “1039” and the “0698:301f” values represent?
Memory addresses? or maybe identifiers? A specific line of code?
Upon reloading multiple times, the same error presented with slight variation:

/das/sys/acl_vm 1c2a - Terminated at 0690:301f. MEMORY exception 0400.
/das/sys/acl_vm 0438 - Terminated at 0600:301f. MEMORY exception 0400.
/das/sys/acl_vm 1d2b - Terminated at 0698:301f. MEMORY exception 0400.

I used diff to compare the acl_vm file with an instance of a known good backup, and the files matched, so I am assuming that hasn’t gotten corrupted.

I’m not specifically trying to figure out what caused the error at the moment, I’m just trying to understand what the error is trying to tell me. It may not get me any closer to fixing/stopping the problem, but I’d rather know what it’s trying to tell me even if it doesn’t help, rather than have that lingering doubt.

The simplest way to describe this is that your program has a bug.

You are running in protected mode. The error is telling you that the program acl_vm with task ID 1039 did a memory exception at the location 301f in the program. 0690 is a selector, which is an offset into the GDT (global ? table) which located the process memory in real memory. You can ignore it. The only way to debug it without source would be to run the debugger and put a breakpoint at 301f. This would be challenging to track down even for me.

If you have the source and/or a link map you can figure out in which routine the memory problem is occurring.