[Dev] Critical vconf issue causing subtle failures throughout much of the tizen middleware

Rusty Lynch rusty.lynch at intel.com
Thu Oct 10 18:29:56 GMT 2013


Looking at this just a little further, the i can clarify the second
issue:
Any attempt to set a vconf key from a post section of an rpm running at
image creation time will result in an empty key.  Since packages are
doing this with the "-i" option set to cause the key to be added to the
memory backing store, then we end up with a memory backup store full of
empty values


On Thu, 2013-10-10 at 11:23 -0700, Peters, Brad T wrote:
> The early vconf copy has long been painful, and we used to have a 
> script which copied initial values out of a static directory filled
> with 
> initial values into a live image at startup.
> 
> 
> Not sure if that script made the transition to a systemd service
> 
> 
> What you're describing sounds like 2 bugs;
>  1) a vconf bug where vconf is not properly handling an empty
> key/value, and 
>  2) an issue where initial values are not populating the vconf db. I
> would recommend 
>    targeting this issue at vconf, as well
> 
> 
> Best,
> -Brad
> 
> 
> On Thu, Oct 10, 2013 at 11:07 AM, Rusty Lynch <rusty.lynch at intel.com>
> wrote:
>         While attempting to debug a bug with the audio session manager
>         where any
>         operation would take a crazy long time to finish, I found that
>         the
>         problem was that an in-memory vconf key was set with no data.
>          Vconf
>         would then do a series of retries to re-read data from the key
>         when the
>         key is in fact just empty, where each retry is 100ms.
>         
>         Without worrying about fixing vconf (since there is a team
>         going off to
>         create a replacement for that), I wanted to understand why my
>         vconf key
>         was set with no data in the first place.  On further
>         investigation i
>         could see that the memory keys are initially populated with a
>         set of
>         defaults from /opt/var/kdb/memory and that ALL of the defaults
>         were just
>         empty files.
>         
>         Looking into this a little further i can see that each of the
>         entries
>         in /opt/var/kdb/memory were populated via the post section of
>         various
>         packages where the post section would use the vconftool
>         command to set
>         the default value.  While this technique works when installing
>         a package
>         on a running live image, it fails when running at image
>         creation time.
>         
>         I don't know why this fails at image creation time, but I see
>         a lot of
>         these empty default files and I suspect that each of these are
>         triggering some subtle, hard to debug failure condition.  In
>         the case of
>         the audio-session-manager it makes the system appear to run
>         very very
>         very slow.
>         
>         Where should I file a bug for this?  This isn't IVI specific.
>         Who would
>         own fixing this... the mic developers or the vconf developers?
>         
>             --rusty
>         
>         _______________________________________________
>         Dev mailing list
>         Dev at lists.tizen.org
>         https://lists.tizen.org/listinfo/dev
> 
> 
> 
> 
> -- 
> Best regards,
> Brad Peters
> Intel SW Engineer 
>  and Tizen Mobile Lead




More information about the Dev mailing list