Item2631: Sometimes renders blank page

I've been unable to isolate the problem. I appreciate the mod_perl approach, which is why I tried the contrib, but here's the story (I also appreciate it's not enough info to debug, but it might be useful in case others have the problem):

• Plain old CGI main site, ShortURLs configured at root of domain (Eg. domain.org/Main)
• Test wiki installation running on symlinked data/ and pub/ dirs.
• Test wiki runs identical to plain old CGI site when configured that way
• Configure with mod_perl, following ModPerlEngineContrib instructions
• Appears to work fine
• But some webs are rendering blank pages, for any topic at all in that web
• Same behaviour with all plugins (cept core) disabled
• Same behaviour with pattern/plain skins
• Accessing the topic with ?raw=on renders okay!

So what's actually happening?

Here is an apache log snippet from a web that does work.

11376,2010/01/13-12:49:123.123.123.123,-,0,+,302,582,"/bin/view/Ants/WebHome"
11376,2010/01/13-12:49:123.123.123.123,-,2,+,200,27482,"/Ants/WebHome"

Here is a snippet from one that is blank every time, unless using ?=on:

11408,2010/01/13-12:50:123.123.123.123,-,0,+,302,586,"/bin/view/HubRIS/WebHome"

As you can see, apache never sends out a 200 OK response.

But it does start doing a response. Did a wireshark trace, which shows:

On web that works

• GET domain.org/bin/view/Ants/WebHome
• (http headers) ... 302 Found ...(data)
• GET domain.org/Ants/WebHome
• (http headers) ... 200 OK ... (data)

On a web that doesn't:

• GET domain.org/bin/view/HubRIS/WebHome
• (http headers) ... 302 Found ... (data)
• GET domain.org/HubRIS/WebHome
• (http headers up to Content-Type)

a normal 302 response, and the corresponding GET from the browser

-- PaulHarvey - 13 Jan 2010

This only happens when you use symlinks? The problem persists if you restart apache? Do you make changes to symlinks while apache is running and before the error happen?

-- GilmarSantosJr - 13 Jan 2010

I have "real" /data and /pub dirs, but symlinked root webs inside. Yes, the problem persisted after restarting apache. I didn't make any changes to symlinks while apache was running.

Incidentally, ?foo=bar params result in blank pages too. Only ?raw=on works when I get one of these "blank webs". Maybe there is some interaction with the core that goes wrong? How does ?raw=on codepath differ to normal rendering?

If I get time I will try to duplicate this problem on a minimal setup (somehow!). It's a perplexing problem, probably unique to me.

-- PaulHarvey - 13 Jan 2010

I struggle with the same problem. Have tried Fsowiki 1.0.x and trunk. No matter symlinks or not, or pseudo installed. Running Ubuntu, both 8.04 LTS and 9.10.

Ctrl-F5 seem to get the page (not Ctrl-r). Using Firefox.

Please, anything I can do to do to help? Really want mod perl running.

-- LarsEik - 19 Feb 2010

LarsEik, can you confirm that on a topic which normally is blank, appending the ?raw=on option "fixes" it?

I think the key is for one of us to reliably reproduce the problem, and examine the difference in the code path ?raw=on vs without.

-- PaulHarvey - 20 Feb 2010

I finally figured out the cause - it's NativeSearchContrib. Using PurePerl search algorithm in configure solves the problem (but of course, you are left with a slower site).

LarsEik, are you able to confirm?

I am able to make the tools/nativesearch/test.pl thing segfault from the command line; will have a go at a gdb session.

-- PaulHarvey - 12 Mar 2010

I get some warnings when compiling.

sudo -u www-data make
cp FoswikiNativeSearch.pm blib/lib/FoswikiNativeSearch.pm
/usr/bin/perl /usr/share/perl/5.10/ExtUtils/xsubpp  -typemap /usr/share/perl/5.10/ExtUtils/typemap  FoswikiNativeSearch.xs > FoswikiNativeSearch.xsc && mv FoswikiNativeSearch.xsc FoswikiNativeSearch.c
Please specify prototyping behavior for FoswikiNativeSearch.xs (see perlxs manual)
cc -c   -g -g   -DVERSION=\"\" -DXS_VERSION=\"\" -fPIC "-I/usr/lib/perl/5.10/CORE"   FoswikiNativeSearch.c
FoswikiNativeSearch.c: In function ‘XS_FoswikiNativeSearch_cgrep’:
FoswikiNativeSearch.c:117: warning: assignment makes pointer from integer without a cast
cc -c   -g -g   -DVERSION=\"\" -DXS_VERSION=\"\" -fPIC "-I/usr/lib/perl/5.10/CORE"   cgrep.c
cgrep.c: In function ‘cgrep’:
cgrep.c:101: warning: format not a string literal and no format arguments
cgrep.c:114: warning: format not a string literal and no format arguments
cgrep.c:131: warning: passing argument 2 of ‘_getline’ from incompatible pointer type
Running Mkbootstrap for FoswikiNativeSearch ()
chmod 644 FoswikiNativeSearch.bs
rm -f blib/arch/auto/FoswikiNativeSearch/FoswikiNativeSearch.so
gcc  -shared -g -L/usr/local/lib FoswikiNativeSearch.o cgrep.o -lpcre  -o blib/arch/auto/FoswikiNativeSearch/FoswikiNativeSearch.so    \
      -lpcre     \
     
chmod 755 blib/arch/auto/FoswikiNativeSearch/FoswikiNativeSearch.so
cp FoswikiNativeSearch.bs blib/arch/auto/FoswikiNativeSearch/FoswikiNativeSearch.bs
chmod 644 blib/arch/auto/FoswikiNativeSearch/FoswikiNativeSearch.bs

And this is the interesting bit of the gdb session:

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
(no debugging symbols found)
(no debugging symbols found)
[New Thread 0x7fa254f1d6f0 (LWP 16663)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fa254f1d6f0 (LWP 16663)]
XS_pack_charPtrPtr (st=0x143cfe8, s=0x4c0008c0, n=<value optimized out>) at FoswikiNativeSearch.xs:73
73      for(c = s; *c; c++){
(gdb) print c
$1 = <value optimized out>
(gdb) bt
#0  XS_pack_charPtrPtr (st=0x143cfe8, s=0x4c0008c0, n=<value optimized out>) at FoswikiNativeSearch.xs:73
#1  0x00007fa253b4c063 in XS_FoswikiNativeSearch_cgrep (my_perl=<value optimized out>, cv=<value optimized out>)
    at FoswikiNativeSearch.c:119
#2  0x00007fa254a4a6d0 in Perl_pp_entersub () from /usr/lib/libperl.so.5.10
#3  0x00007fa254a48972 in Perl_runops_standard () from /usr/lib/libperl.so.5.10
#4  0x00007fa254a46d5f in perl_run () from /usr/lib/libperl.so.5.10
#5  0x0000000000400d4c in main ()

-- PaulHarvey - 12 Mar 2010

Weird. My wiki is 500ms faster with PurePerl than NativeSearchContrib search. So I am no longer using NativeSearchContrib. FastCGI + Perl 5.10

-- PaulHarvey - 15 Mar 2010

I have managed to enable mod_perl but had to change the response handler to the following:

Options +ExecCGI -FollowSymlinks
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlSendHeader On
PerlOptions +ParseHeaders

#Options +ExecCGI -FollowSymLinks
#    <IfModule mod_perl.c>
#        SetHandler perl-script
#        PerlResponseHandler Foswiki::Engine::Apache
#    </IfModule>

It worked the evening I changed to mod_perl with the contrib but the next morning the web server was not functioning. Then I (hastly) changed to the config show above instead of going plain CGI. It was not a blank page issue then. I haven't much of a clue about this stuff, using the config generator, but if/when I try so switch again I'll check the logs.

-- LarsEik - 15 Mar 2010

ModPerlEngineContrib never worked out so we use FastCGIEngineContrib, which is good.

-- LarsEik - 03 Jun 2010

I could confirm this issue on Cent OS 5.2 and NativeSearchContrib. I'll investigate.

-- GilmarSantosJr - 21 Jun 2010

I have the same problem using mod_perl. I tried another cache engine and it doesn't work better. I had to deactivate the cache in configure/Tuning to make it works. Does a fix exists for this bug ?

-- NicoS - 05 Nov 2012