Bump PORTREVISION just in case this is needed.
From Mikhail Teterin:
> Well, for the same reason the xslt.cpp sometimes works -- in fact, it
> worked for everyone, until someone tried it on current.
>
> In essence, the code reads the whole file into a buffer. It then tries
> to turn that buffer into one of qt's string-objects (QCString). The
> class' constructor they chose assumes, it is passed a valid (aka
> \0-terminated) string and goes through the buffer looking for the first
> 0-byte. The file itself does not contain any, so it happily wonders
> behind the real end of the buffer until it either finds a stray 0-byte,
> or seg-faults, trying to read a wrong page.
>
> Apparently, more often than not, some stray 0-byte is there -- no
> surprise. But it will usually create a string that's longer than the
> file size -- unless the 0-byte happens to be right there at the end of
> the buffer. Apparently, the lamer, who wrote it, noticed something
> strange, so he/she explicitly truncates the created QCString object to
> the known size of the file after instantiation:
>
> contents.truncate(xmlFile.size())
>
> My patch modifies the code to use the correct QCString constructor --
> the one, that accepts the maximum size of the string. This does the
> right thing -- once it reaches the end of the buffer, it stops,
> allocates the private storage (I hate C++ for all this buffer copying),
> appends the 0-byte and creates the object of the expected size. No
> truncation is needed....
Thanks to Mikhail for his debugging on this problem; this patch further
removes the hazard of meinproc coredumps.
Submitted by: mi
174743bd5d