nALFS 1.2.1 SIGSEGV'ing on me

Kevin P. Fleming kpfleming at linuxfromscratch.org
Thu Mar 4 14:50:29 PST 2004


Dermot Bradley wrote:

> xmlint --noent --xinclude --postvalid --valid build-eyes.xml gives:
> 
> build-eyes.xml:3: element alfs: validity error : Element alfs content does
> not follow the DTD, expecting (configure | copy | download | execute |
> link | make | mkdir | move | ownership | package | patch | permissions |
> remove | search_replace | stage | textdump | unpack | xi:include)*, got
> (alfs alfs alfs alfs )

OK, this makes sense, because if you supply --xinclude to xmllint, then 
the xi:include elements will be gone and replaced by their content 
before the validation occurs. This is a problem in the DTD, <alfs> 
should be allowed inside <alfs>, but it's not. However, that would mean 
that <alfs> would be allowed pretty much anywhere, because any include 
file you create has to have an outer <alfs> element itself or it's not 
valid on its own. I don't think I want to do that.

> I guess that there's an issue with the way I've written by files (with
> xincludes). The thing is this profile has worked fine for ages with older
> versions of nALFS.

Nope, they are OK. Gerard's profiles are like this too, and they work 
fine. Something has changed in nALFS that has caused this problem.

> 
> My top-level xml file build-eyes.xml is:
> 
> <!DOCTYPE alfs SYSTEM="ALFS.dtd" []>
> 
> <alfs version="3.1" xmlns:xi="http://www.w3.org/2001/XInclude">
> <xi:include href="base.xml"/>
> <xi:include href="eyes.xml"/>
> <xi:include href="finish.xml"/>
> <xi:include href="initrd.xml"/>
> </alfs>

I don't think the xi:include elements are the problem; rather, something 
is being mishandled more deeply in your profile (the stack trace you 
sent had 8 or 9 instances of convert_nodes on the stack, the parser was 
that many nodes deep when the failure occurred).

There are ways to work on this problem, but it will require some 
testing. Are you comfortable adding some Nprint() statements to nALFS to 
get it to tell you where the failure is occurring? If so,

Nprint("node name: %s", node->name);

as the first code line (after the declarations) of create_element() in 
libXML-tree.c. With that in place, you will see a stream of node names 
go by as nALFS parses the profile and possibly be able to figure out 
where it's failing.



More information about the alfs-discuss mailing list