[Moin-user] xapian search: an unhandled win32 exception occured in w3wp.exe

[Mark Scheufele]

Hi Thomas,

I was now able to track down to code that triggers IIS to throw the unhandled exception.
It appears within the  _indexingRequest() method  of the MoinMoin\search\builtin.py module.

I did the following:

	- inserted a breakpoint into the code using winpdb and restarting the wiki
	- after updating a page over the web I could step through the lines of _indexingRequest() until a copy of the request object is being made. This causes the exception within IIS

   def _indexingRequest(self, request):
        """ Return a new request that can be used for index building.

        This request uses a security policy that lets the current user
        read any page. Without this policy some pages will not render,
        which will create broken pagelinks index.

        @param request: current request
        """
        import copy
        from MoinMoin.security import Permissions
        from MoinMoin.logfile import editlog

        class SecurityPolicy(Permissions):

            def read(self, *args, **kw):
                return True
        import rpdb2
        rpdb2.start_embedded_debugger("""...Removed-password-from-output...""")
        r = copy.copy(request)	<-- IIS exception is caused

As already mentioned when I try to update the Xapian index of a page using a standalone script its STDOUT also contains some information regarding an exception.

Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in <type 'exceptions.AttributeError'> ignored
Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in <type 'exceptions.AttributeError'> ignored

Yet it seems that the standalone script handles the condition more gracefully than if the code is executed as ISAPI application under the command of IIS.

There is also one more thing I cannot understand. When I run the standalone script an exception is being reported yet I am not able to catch it.
What I mean is when I run:

try:
	index.update_item(page.page_name)
except Exception ,e:
	print "CATCHED excpetion %s" % str(e)

I am not able to catch the exception. But STDOUT of the script contains the lines:

Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in <type 'exceptions.AttributeError'> ignored
Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in <type 'exceptions.AttributeError'> ignored

To me this looks kind of weird as information about an exception is reported yet I am not able to catch it. 

Currently I am suspecting that the root cause of the issue might be that the mentioned exception (that cannot be catched within python but nonetheless is still there) is propagated
to IIS and causing the webserver throwing the unhandled exception message.

Apart from this mail I will also file a bugreport at http://moinmo.in/MoinMoinBugs describing my setup and all the observations I have already made.

Regards,

mark

-----Original Message-----
From: Thomas Waldmann [mailto:tw-public at gmx.de] 
Sent: Samstag, 28. April 2012 23:53
To: Mark Scheufele
Cc: moin-user at lists.sourceforge.net
Subject: Re: [Moin-user] xapian search: an unhandled win32 exception occured in w3wp.exe


> is there anybody out there who knows details about the xapian integration into moin?

While I didn't do changes recently, I worked quite a bit on that code some time ago.

>  Yesterday I have reported that xapian index is not updated when a page is changed. Instead the webserver (IIS 7.5) reports an unhandled exception.

I can't help you with IIS specific issues, I never used it (nor would I ever use it).

>   "Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in <type 'exceptions.AttributeError'> ignored"

IIRC, i had a look at that a while ago and somehow I got the impression that it is a harmless python bug and can be ignored.

> - after trying to update a page over the web  a search for content of this page does not show any result. Even page content already searchable prior to the 
>    page change cannot the searched anymore.

Hmm, that's strange.

> - When I now run the commandline script for the page I tried to update over the web the moin.log file shows that there is more than one update queued.
>   2012-04-25 17:03:17,438 MoinMoin.search.Xapian.indexing DEBUG updated xapian index with 2 queued updates
>   The number of queued updates for a page can be increased by trying to update the page over the web several times.

Sounds like it never processes (empties) the queue.


> I am really interested in solving the issue. If someone could give me a hint how to further troubleshoot it would be highly appreciated.

Well, if you want to help debugging this / determining the circumstances, trying this comes to mind:
 * maybe use a more recent python 2.x version
 * try without IIS (try to reproduce with standalone server or apache2 +
mod-wsgi)
 * try a later / different xapian version
 * can you reproduce on moinmo.in site?

Please also file a bug report about this on the wiki (see MoinMoinBugs
page) and provide all details the template asks for (and everything else you could find out).




_______________________________________________________________________________________

Dialog Semiconductor GmbH
Neue Str. 95
D-73230 Kirchheim
Managing Directors: Dr. Jalal Bagherli, Jean-Michel Richard
Chairman of the Supervisory Board: Gregorio Reyes
Commercial register: Amtsgericht Stuttgart: HRB 231181
UST-ID-Nr. DE 811121668


Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and 
contains proprietary information, some or all of which may be legally privileged. It is 
intended solely for the use of the individual or entity to which it is addressed. Access 
to this email by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful.

Please consider the environment before printing this e-mail