|Problems? Is your data what you think it is?|
Re^5: "Invisible" nodes (details)by tye (Sage)
|on Jan 06, 2012 at 15:39 UTC||Need Help??|
Yes, Clean smoke-test install for Inline based modules using Inline::MakeMaker results in a blank page when I'm logged in as tye and access it via that web server as well (that web server is the "new" one that has mod_perl v2). Each visit adds the following to the error log:
This doesn't happen if I view it when not logged in or even when I view it logged in as tye .
One of the factors that is often present in previous cases I've seen of this is the presense of a node by BrowserUk where he uses "<spoiler><code>", Re^5: Clean smoke-test install for Inline based modules using Inline::MakeMaker. But there have been other such nodes where this bug doesn't happen and there have been nodes that trigger this bug where that string is not used.
Since both tye and tye have the same settings for how to handle spoilers, I just now spent some time changing some of my "code wrap" settings. I can make the bug appear or disappear by changing several of those. A common element might be that settings that insert HTML tags for CODE sections trigger the bug? In any case, I can trigger the bug for that node if I turn on "auto code wrap" and set the wrap length to 10. I can also trigger the bug there if I use your "code prefix" that contains several HTML tags.
I suspect that Perl's "safe signals" would prevent me from trapping SIGILL so that I could get a stack trace of where the bug fires. "man signal" on this OS doesn't say that I can't trap SIGILL like "man signal" says on my work box does, so it might be worth trying. Makes me want to be able to pick between "safe" and "unsafe" signals in Perl on a per-signal basis. I don't think Perl supports that but I suspect the underlying mechanism Perl uses could support that.
BTW, adding ;spoil=1 to the URL doesn't prevent the bug.
So that is some more specific information than I had before. Still doesn't give me a simple troubleshooting route, unfortunately. I don't have more time to look at that right now, but I might find some time to look further fairly soon.