I was wrong. My app was mishandling console input :(
>-----Original Message----- >From: Tim Hardisty <t...@hardisty.co.uk> >Sent: 09 March 2023 15:34 >To: dev@nuttx.apache.org >Subject: RE: Help me understand file open/close behaviours? > >Guess what - this behaviour is only on Master. Spent an hour or 2 getting >the test app and new driver to work under 12.0 release and I can ctrl-C >out of my test app without problem and re-run it without an apocalyptic >crash. > >I will now raise it as an issue on GitHub. > >>-----Original Message----- >>From: Tim Hardisty <t...@hardisty.co.uk> >>Sent: 08 March 2023 17:37 >>To: dev@nuttx.apache.org >>Subject: RE: Help me understand file open/close behaviours? >> >>>From: Gregory Nutt <spudan...@gmail.com> >>>Sent: 03 March 2023 19:03 >>> >>>On 3/3/2023 12:56 PM, Gregory Nutt wrote: >>>> On 3/3/2023 12:36 PM, Nathan Hartman wrote: >>>>> On Fri, Mar 3, 2023 at 1:07 PM Tim Hardisty <t...@hardisty.co.uk> >>wrote: >>>>>> - I have enabled CONFIG_SIGKILL_ACTION to allow me to ctrl-c from >>>>>> the console if the app is misbehaving or, I thought, just to exit >>it. >>>>>> >>>>>> The behaviours I see are: >>>>>> >>>>>> 1) If I ctrl-c, the open files are not closed and if I re-run the >>>>>> app, the system crashes. It is the very first printf statement of >>>>>> the app that causes the crash, at the point the printf routine >>>>>> calls lib_fflush (not looked further yet). >>>> >>>> SIGINT, SIGKILL, etc. don't do graceful shutdowns like exit() does. >>>> They should behave as though _exit() were called which does an >>>> immediate termination. However, _exit() is still required to close >>>> all open file descriptor (Per Linux man page) and, if it does not, >>>> that would be a bug. >>>> >>>> SIGKILL can't be caught (again per the Linux man page) >>>> >>>> https://man7.org/linux/man-pages/man2/exit.2.html >>>> https://man7.org/linux/man-pages/man7/signal.7.html >>>> >>>"Closing" per se is probably not a the root of the problem when the >>>file descriptors are deallocated when the task group terminates, all >>>of the descriptors are freed. However, I suspect the there may be an >>>open reference count in the drivers which is not decrements and whcih >>>could subsequently in interfere with the correct behavior or a driver. >>> >>> >> >>To divert from procedural discussion... >> >>I think I take it from the above that a CTRL-C is not a clean exit; but >>is not the root cause of the issue I'm seeing. >> >>The crash is at a printf the very first line of the app. And the same >>is true if I run another example app after a ctrl-c out of my new test >>app that uses printf. It is not to do with any interaction with file >>open/close/ioctl etc. as I first thought. >> >>I don't get why a ctrl-c out of an app causes printf to completely >>crash the board with no useful debug info to be had! The call stack >>simply shows it was due to an ARM data abort exception. >> >>I am quite sure I have made some "daft" Kconfig change (or not made a >>selection I should have done) - I welcome any suggestions before I >>shrug my shoulders and conclude this is just "one of those things" :)
