Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re^4: "Invisible" nodes (core)

by roboticus (Chancellor)
on Jan 04, 2012 at 03:45 UTC ( #946187=note: print w/replies, xml ) Need Help??

in reply to Re^3: "Invisible" nodes (core)
in thread "Invisible" nodes


Update: I installed ShowIP for Firefox as suggested by je44ery and ran through the same steps. (Thankfully, it's quite consistent.)

While browsing the site, the IP showed up as for all pages, including the invisible/blank page. When I changed the extension from .org to .com in the address bar and reloaded the page, the IP remained as, and the page displayed just fine. As in the first time, the only difference is that when the page showed this time, I'm not logged in. I checked the cookies (via Tools|Page Info) and found that I have only the 'userpass' cookie on .org and no cookie for .com. Is there any information you'd like me to pull from my browser/OS/... to help? It's consistent, as I've tried the same sequence a dozen times over the last few days and always get the same result. (Note: on the work computer the "invisible" page comes up as a "network error" page as described in the OP.)

Well, I installed Wireshark, but don't really know how to sift through it efficiently, so any tips would be handy. (Or I could install another tool, if that would be better.)

In the morning, I'll restart my machine, flush out the firefox cache and capture a session. Then I'll save the session and start looking for clues.

Note: when I was able to read the content, it was by editing '' to '', which brought up the page, but I wasn't logged in. (Does that mean that an old cookie might be the problem? I used to use the .com address by default, but changed to .org when I started having some issues with .com in the time period of the previously-mentioned thread. The thing I find odd is when I bring up a new node and a minute later have the problem bringing up a different node. I would've suspected that the DNS entry would've been the same one.

If I find anything, I'll update the post and message you. If there's anything specific you'd like to see (other than what you just mentioned), let me know.



When your only tool is a hammer, all problems look like your thumb.

Replies are listed 'Best First'.
Re^5: "Invisible" nodes (details)
by tye (Sage) on Jan 06, 2012 at 15:39 UTC

    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:

    [...] [notice] child pid 45490 exit signal Illegal instruction (4)

    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&nbsp; 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.

    - tye        


      Don't hurry to fix it on my account, I just wanted to give you what you needed to reproduce it if needed. Thanks for the ";spoil=1" workaround, I'll use that when I need it.

      Thank you...


      When your only tool is a hammer, all problems look like your thumb.

Re^5: "Invisible" nodes (core)
by jffry (Hermit) on Jan 05, 2012 at 20:51 UTC

    If all tye needs is the IP address you are going to for perlmonks, then Wireshark seems like overkill. See if this Firefox plugin works: ShowIP

    I was going to say just run nslookup (works in Windows, too) and the response is probably the cached answer that Firefox is using, but I'm honestly not certain that is true. Firefox does not necessarily use the DNS resolver libs on the OS.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://946187]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (3)
As of 2018-01-22 05:35 GMT
Find Nodes?
    Voting Booth?
    How did you see in the new year?

    Results (231 votes). Check out past polls.