[CalendarServer-users] calendarserver 3.2 on Debian unstable throwing error "socket.error: [Errno 22] Invalid argument" out of the box?

[Fredrik Unger]

Hi,

I found the problem, it turns out it was not a 32/64 bit or alignment 
problem. Seems to be a C-Python interface problem.

On 07/20/2012 10:27 AM, Glyph wrote:

>  Maybe some 64-bit linuxes are sensitive to alignment and some
> aren't? I'm frankly somewhat baffled.

Back from vacation and I spent yesterday evening simplifying the 
testcase. Thanks to the test subdirectory (the unit testing code)
I set up a small local test environment.

I found a strange behavior of the Python code.
I know too little of the interface between Python and C to know the 
exact problem.

In sendmsg.c the auxiliary list is called for twice, first to check
the size of the data and then for the actual data.
During the first call to PyArg_ParseTuple the variables level and type 
are 1 as they should be. eg SOL_SOCKET and SCM_RIGHTS.

During the second call to PyArg_ParseTuple level stays 1 but type is 0!
This 0 is the written to the struct for the syscall causing the
Invalid Argument.

I double checked and the SCM_RIGHTS constant is 1 in Python as well
(it is imported in the sendmsg module)

I was doing the testing with the latest svn code, and once I found it 
built the debian package calendarserver (3.2+dfsg-1) with the fix.

SVN I only tested with the test environment but after the fix, the 
debian server worked, with no other changes.
(A call to localhost:8008 in the web browser returned
"Collection Listing.." )

The patch to I added was :

--- calendarserver-3.2+dfsg.orig/twext/python/sendmsg.c
+++ calendarserver-3.2+dfsg/twext/python/sendmsg.c
@@ -238,7 +238,7 @@ static PyObject *sendmsg_sendmsg(PyObjec
              }

              control_message->cmsg_level = level;
-            control_message->cmsg_type = type;
+            control_message->cmsg_type = SCM_RIGHTS;
              data_size = CMSG_LEN(data_len);

              if (data_size > SOCKLEN_MAX) {

This is of course not a real fix, but a pointer to what is wrong.

This could also be a Python 64-bit bug under Debian, and it could be 
that it should be solved elsewhere.
Maybe someone can test Redhat or SuSE ?

My standard Python version is :
$ python --version
Python 2.7.3
Python 2.6.8 is also installed.

To build the actual debian package I had to add this patch as well

--- calendarserver-3.2+dfsg.orig/setup.py
+++ calendarserver-3.2+dfsg/setup.py
@@ -32,6 +32,7 @@ def find_modules():
          excludes = [
              ".svn",
              "_trial_temp",
+            "dist-packages",
              "build",
          ]


This as the setup.py call took the content of the debian build directory 
as well. Maybe debian would work too, that is up to the debian
maintainer. But I could not build my debian package here before this fix.

/Fred