QNX Technical Articles
QNX® OS for Safety 2.0 (Beta): Release Notes
Date of this edition: September 27, 2017
Target OS: This product is compatible with targets that are running QNX® Neutrino® 7.0.
Host OS: In order to install this product, you must have installed the QNX Software Development Platform 7.0 on one of the following development hosts:
- Microsoft Windows 10 Professional 64-bit, Windows 8.1 Professional 64-bit, or Windows 7 Professional 64-bit
- Linux Red Hat Enterprise Linux 7 64-bit, or Ubuntu Desktop 16.04 LTS 64-bit
For more information, see Installing and Using the QNX OS for Safety.
 |
|
 |
To access the most up-to-date version of these release notes, go to the QNX Software Center, right-click on the QNX OS for Safety 2.0 package, choose Properties, and use the link provided. |
Contents...
Throughout this document, you may see reference numbers associated with particular issues, changes, etc. When corresponding with our Technical Support staff about a given issue, please quote the relevant reference number. You might also find the reference numbers useful for tracking issues as they become fixed.
What's in this product?
This product includes the QNX OS for Safety 2.0 (beta), as well as fixes for a number of issues found in libc and the kernel.
Fixed issues
The updated C library in this product includes the following fixes:
- devctl()
- If a process forks and then calls the DCMD_PROC_STATUS or DCMD_PROC_TIDSTATUS devctl() command on itself, it now gets the correct stack address. (Ref# J180339)
- exec*()
-
- The new process image now inherits any signals that were pending for the calling process, as required by POSIX. (Ref# J163197)
- These functions now correctly enforce the limit (ARG_MAX bytes) on the size of arguments for processes. (Ref# J1561281)
- The kernel now correctly handles signals that are sent to a process while it's in the process of an exec*() operation. (Ref# J1469296)
- fork()
- This function now correctly sets errno to EPERM if the priority is too high. (Ref# J1601362)
- fslog()
- Calling procmgr_daemon() after calling this function no longer closes the file descriptor for the system logger, so log messages now go to the right place (Ref# J183838)
- fstat()
- Changes to a FIFO made directly on the underlying file system (chmod(), chown(), unlink()) are now reflected in the information returned by a call to fstat() that goes directly to the pipe resource manager. An fstat() call on a pipe now correctly returns 0 in the st_nlink field. (Ref# J2230953, J2227283)
- aarch64/inout.h, gulliver.h
- We've fixed some compilation problems that occurred with these header files. (Ref# J1634908)
- malloc()
- This function now returns 16-byte-aligned pointers. (Ref# J2194461)
- mktime()
- We've corrected an overflow that occurred when you passed INT_MAX as the year. (Ref# J1692237)
- mmap()
- The virtual memory manager now correctly determines the size when you mmap() a block device. (Ref# J2162973)
- mprotect()
- If you use mprotect() on a sparsely populated lazy mapping region, the page table entries are now correct. The QNX OS for Safety 2.0 Safety Manual requires that you avoid using MAP_LAZY mappings, so as to avoid overcommitting your memory allocations. (Ref# J173571)
- MsgDeliverEvent(), MsgSendPulse()
- These functions now give an error of EINVAL for priority values of NUM_PRI or higher. (Ref# J1682707)
- posix_spawn(), posix_spawnp()
-
- These functions now return ENAMETOOLONG if an action set with posix_spawn_file_actions_addopen() has a path that's longer than PATH_MAX. (Ref# J2141833)
- These functions now correctly enforce the limit (ARG_MAX bytes) on the size of arguments for processes. (Ref# J1561281)
- procmgr_ability()
- The subrange of the PROCMGR_AID_XPROCESS_QUERY ability is now effective user IDs instead of process IDs. Your process now needs this ability enabled in order to call clock_gettime() or ClockTime() to get the time for a process or thread CPU-time clock that belongs to a different user, aside from the kernel's idle thread. (Ref# J2152952)
- pthread.h
- PTHREAD_MUTEX_DEFAULT, PTHREAD_MUTEX_ERRORCHECK, PTHREAD_MUTEX_RECURSIVE, and PTHREAD_MUTEX_NORMAL are now included when you compile for POSIX 1003.1-2001 compliance. (Ref# J2211714)
- pthread_attr_setstack()
- If you use this function to provide a stack for a thread, the kernel no longer reduces the size to take a guard page into account. (Ref# J385192)
- pthread_cond_broadcast()
- This function now returns EINVAL if you pass it an unitialized condvar. (Ref# J1691149)
- pthread_create(), ThreadCreate()
- These functions now give an error of EAGAIN if you try to create more than the maximum number of threads in a process. (Ref# J1567443)
- pthread_mutex_destroy()
- Calling this function on an already-destroyed mutex now returns EINVAL. (Ref# J1691484)
- pthread_mutex_lock(), pthread_mutex_trylock()
-
- These functions now fail with an error of EINVAL if the mutex was created with the a protocol attribute of PTHREAD_PRIO_PROTECT and the calling thread's priority is higher than the mutex's current priority ceiling. (Ref# J1691127)
- We've corrected a race condition where a fork() could cause pthread_mutex_lock() to fail with an error of EINVAL. (Ref# J1630199, J2182813)
- pthread_mutex_unlock()
- This function now returns EINVAL if you try to unlock a destroyed mutex. (Ref# J1691472)
- regcomp()
- This function no longer writes outside of the array it allocates for categories if you use a negative character in a regular expression. (Ref# J1701452)
- resmgr_msgreplyv()
- The struct iovec * argument to resmgr_msgreplyv() is now marked as const. (Ref# J2181687)
- SchedCtl()
- There's a new SCHED_CONFIGURE command that lets you fine-tune the thread scheduler. For more information, see below. (Ref# J1689586)
- sem_timedwait()
-
- This function now gives an error of EINVAL if you pass it an invalid time specification for a named semaphore. (Ref# J2141105)
- This function now indicates the correct error if it times out. (Ref# J164943)
- setvbuf()
- Input is now correctly unbuffered when you specify _IONBUF. (Ref# J2215438)
- SignalWaitinfo(), sigwaitinfo()
- These functions now initialize the si_error member of the siginfo_t structure to 0. (Ref# J183358)
- snprintf()
- As required by POSIX, this function now gives an error of EOVERFLOW if the given size of the buffer is greater than INT_MAX (Ref# J2194461)
- spawn*()
- These functions now correctly enforce the limit (ARG_MAX bytes) on the size of arguments for processes. (Ref# J1561281)
- syslog()
- This function now checks the return code from write(). If the call failed, syslog() now reopens the file descriptor for the system log and tries to write the data again. It does this up to three times; if all the attempts fail, errno is set. (Ref# J1529157)
- UNALIGNED_RET32()
- This macro now correctly gives an unsigned value. (Ref# J2163746)
- wcstombs()
- This function now returns the correct value when you pass it a NULL output pointer. (Ref# J2141741)
Other fixes include:
- We've improved the calculation of execution times for threads. One result of this is improved accuracy in round-robin scheduling. (Ref# J2179406)
- Running ls /proc/ham no longer results in an error of ENOSYS. (Ref# J2185470)
- The hogs utility produces more accurate information when you run it as a non-root user, and it no longer faults. (Ref# J2152850, J2147252)
- New processes now start with the correct locale when you specify the locale via an environment variable. (Ref# J2141710)
- The CPU load is now reported properly when you run top as a non-root user. (Ref# J1700776)
- A single signal with multiple timer sources is now generated the correct number of times when more than one timer fires during an interval when one instance of the signal has already been generated, but not yet accepted by (for example) a signal-catching function. (Ref# J167001, J164766)
- The kernel no longer crashes when you use a memory-mapped file with a size that's greater than the amount of available memory. (Ref# J1695667)
Known issues
- There's a race condition that can occur in the following scenarios
if you're running procnto with the -v option:
- A SIGKILL signal is sent to a process that's exiting.
- A fork() fails, and a SIGKILL signal is sent to the process while it's being terminated.
- An exec() fails, and a SIGKILL signal is sent to the child process while it's being terminated.
In these cases, the kernel might crash, but this is unlikely to happen in practice. (Ref# J2218077)
Workaround: Run procnto without the -v option.
- An incorrect typecast makes it impossible to use symlink() to create symbolic links that are more than 512 bytes long. (Ref# J2238382)
- If you use both the -p and -r options with qcc or q++, the -p option isn't passed to the compiler. (Ref# J2239400)
- If you use the Verify Installation command in the QNX Software Center on a Windows host, you'll get some benign errors because symbolic links in the products are replaced by copies of the destination files. (Ref# J2239390)
- In the QOS 2.0 beta release, procnto-smp-instr-safety disables kernel preemption (the -p option). After the beta, we plan to enable kernel preemption by default (-~p).
- The Safety Manual refers to the 32- and 64-Bit Architectures chapter in the QNX Neutrino Programmer's Guide. This chapter is currently in Migrating to QNX SDP 7 but will soon "migrate" to its new location. (Ref# J2235509)
- The kernel doesn't recognize orphaned process groups (process groups in which the parent of every member is either itself a member of the group or isn't a member of the group's session) as required by POSIX. (Ref# J165028)
Additional documentation
Here's some information about some new features in this release.
SCHED_CONFIGURE command for SchedCtl()
As a trade-off between latency and throughput, the scheduling algorithm makes decisions that people expecting strict priority scheduling occasionally find surprising:
- A high-priority thread T that becomes ready on CPU A doesn't always displace a lower-priority thread running on that CPU. Under some circumstances, an interprocess interrupt (IPI) is sent to CPU B to force it to perform a new scheduling decision, which is expected (but not guaranteed) to cause thread T to run on CPU B.
- If a thread T running on CPU A is displaced by a higher-priority thread, and a thread with a priority lower than T's is running on CPU B, CPU B isn't signalled to reevaluate its scheduling decision.
The end result is that only the highest-priority thread in the system is guaranteed to run on some CPU, while the other CPUs may be running threads with lower priority than those ready to run at any given point in time. The SCHED_CONFIGURE command provides some parameters that you can use to tune the scheduler.
|
Your process must have the PROCMGR_AID_SCHEDULE ability enabled (see procmgr_ability()). |
The data argument for this command must be a pointer to a struct sched_config structure. It includes the following members:
- int32_t low_latency_priority
- The priority threshold above which a thread always displaces a lower-priority thread running on the CPU on which it becomes ready. Effectively, this parameter allows for a priority class to be defined as low latency, avoiding the overhead of an IPI and a new scheduling decision by another CPU.
- int32_t migrate_priority
- The priority threshold above which a preempted thread will be rescheduled on another CPU (the one running the lowest priority thread).
Keeping both parameters at their default values (INT_MAX) maintains the scheduling behavior described above. Setting both to 0 results in a strict-priority scheduling system, where the N highest-priority threads run on the N available CPUs. Intermediate values create a system with classes of priorities that behave differently, as it's expected that low-priority threads are used for higher throughput, and high-priority threads for low latency.
Errors:
SchedCtl() and SchedCtl_r() indicate the following errors for the SCHED_CONFIGURE command (see the Returns section for details):
- EOK
- Success.
- EINVAL
- The size of the parameter block doesn't match the size of the expected structure.
- EPERM
- You don't have the PROCMGR_AID_SCHEDULE ability enabled.
Technical support
To obtain technical support for any QNX product, visit the Support area on our website (www.qnx.com). You'll find a wide range of support options, including community forums.
For questions about installing and using QNX SDP, see the Getting Started forum on our Foundry27 site, http://community.qnx.com. There are other forums for specific topics, including the QNX Neutrino RTOS, development tools, networking, Board Support Packages, and so on.