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" :)
