[persistence] Strange behaviour of pcl if the application crash or ends without calling pclDeinit

Berggrund, Mats mats.berggrund at volvocars.com
Mon Apr 4 09:19:35 UTC 2016


Hello all. I have noticed some strange behaviour when an application
crashes or ends without calling pclDeinitLibrary().

1) FILES LEFT UNDER /dev/shm
This question is ablout what is left under /dev/shm ! When an
application behaves correctly and calls pclDeinitLibrary then all its
files under /dev/shm are also removed, which seems reasonable. If
however the application crashes, or doesn't call pclDeinit when it
ends, then a whole bunch of files are left under /dev/shm . If the
application then is started up and closed properly (calling pclDeinit)
the files are still there under /dev/shm !! This doesn't seem correct
and it might be connected to other problems we have seen (see below).
The only way to get rid of these files seems to be to reboot the
system.

Now over to two more concrete problems that might be connected to the
above.


2) CACHE FLUSH TO DISK AFTER CRASH
The use case is as follows:
        - Pre-condition: pcl-parameter "MyParameter" has the value "A"
        - Application A is started and it writes "B" to pcl.
        - Many seconds later application A crash (or ends without
calling pclDeinit).
        - Application A is started up again and it writes "C" to pcl.
        - Application A is shutdown by the Node State Manager or it
ends by calling pclDeinit.
        - The system is rebooted
        - When starting upp application A again the value of
"MyParameter" is still "A" !!!!!! but I would have expected "C".


3) persadmin_tool fails (when there are files under /dev/shm ??)
The use case is as follows:
        - Application A is started
        - Application A crash and leaves a bunch of files under
/dev/shm
        - Run persadmin_tool install ... -> fails
        - Remove all files under /dev/shm
        - Run pertsadmin_tool install ... -> succeeds


In particular bullet 2) above feels very serious. For bullet 3) we can
probably find a workaround (but it doesn't feel good).

I can happily create/fetch some log files for ... whatever if
requested.

Best regards,
Mats B


More information about the genivi-persistence mailing list