Re: prop_dictionary_internalize_from_file help

[matthew sporleder <msporleder%gmail.com@localhost>]

On Wed, Dec 16, 2009 at 12:19 PM, Robert Elz <kre%munnari.oz.au@localhost> 
wrote:
>    Date:        Wed, 16 Dec 2009 10:37:48 -0500
>    From:        matthew sporleder <msporleder%gmail.com@localhost>
>    Message-ID: 
>  <b0459d5c0912160737y3b3911d8u7c620b4acccbd873%mail.gmail.com@localhost>
>
>  | Yeah, I added that to try and get a hint.  Without it I don't even see
>  | the attempt to open my plist.in ktruss.
>
> That's very odd, I cannot see how adding that perror() could have caused
> anything inside the library to change - does ktruss show the open now?
>
> If it doesn't try ktrace/kdump instead (I think someone once said that
> ktruss sometimes has "issues""")
>
> If the file really isn't being opened - not even being attempted to be opened
> (does it's access time get touched when you run your program) then from how
> I read the source, the only possible failure is from malloc() - you'll get
> NULL back if malloc() fails (and "no such file or directory" is a likely
> errno value in that case, as malloc() is looking for its magic symlink
> to help it decide how it should work, and that usually doesn't exist).
>
> Most error retrns are immediately preceded by a call to free(), I'm
> not sure if free() check's malloc's magic symlink file too - but if it
> does, that could explain why you always just see "no such file or directory"
> as the errno response (you might want to try making the magic symlink,
> just make it point to "", as in
>
>        ln -s "" /etc/malloc.conf
>
> so the file does exist, and checking for it won't pollute errno.
>
>  | Is there a good example of a minimal plist?
>
> That's a question for someone else.
>
>  | The one I started using was just copied from my mac
>  | and I've been dropping stuff from it but I always get NULL.
>
> What I'd do, is copy the proplib sources from src/common/lib/libprop
> into your source directory, and compile them (and your test program)
> with -g, and single step through, find out exactly what is failing.
>
> That will work, you can override regular libc functions that way without
> problems.   Of course, if the problem is deep inside somehere, it may
> take a lot of patience to step far enough through to actually find what
> is happening - but you can at least easiy set a breakpoint on the file
> open, and see if it is ever called, and if so, whether it succeeds.
>
> kre
>
>

The problem was the use of a <real> in the plist.  I opened a PR
bin/42462 asking for a parse error in that case.