Hmm. Too much time at this I guess. . .
Reviewing again I do not find any paths that are without PRINT (i.e., io_print)
use. That should mean that io.uio.uio_iov->iov_base was initialized but somehow
changed.
I still have not replicated the problem with smaller/simpler code, only with
libc/std
I have submitted a minor variation of this analysis text for the uninitialized
pointer use in in libc/stdio "string output" routine implementations as Bug
206770.
If anyone finds that I missed the initialization let me know and I'll change
the status of the bug.
===
Mark Millard
markmi at dsl-
So far I'm unable to reproduce the problem with simple code replacing the
library code.
And I expect that I have have a smoking gun for why. Care to check the below
and see if I missed something? As far as I can tell this is a FreeBSD
libc/stdio defect, not a clang 3.8.0 one.
Unfortunately th
On 2016-Jan-30, at 3:29 AM, Roman Divacky wrote:
> Can you file a bug in llvm bugzilla?
I could try for the example code. But I'd like to make the example more self
contained first, avoiding snprintf from library code and hopefully with a much
smaller, simpler implementation involved than the
Can you file a bug in llvm bugzilla?
On Sat, Jan 30, 2016 at 03:00:26AM -0800, Mark Millard wrote:
> I got around to trying some more use of the 3.8.0 clang based world on
> powerpc (32 bit) (now -r294962 based) and ran into:
>
> A) Segmentation faults during signal handlers in syslogd, nfsd, mo
I got around to trying some more use of the 3.8.0 clang based world on powerpc
(32 bit) (now -r294962 based) and ran into:
A) Segmentation faults during signal handlers in syslogd, nfsd, mountd, and
(for SIGNFO) make.
B) ls sometimes segmentation faulting
C) make -j 6 buildworld segmentation f